From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f180.google.com (mail-pf0-f180.google.com [209.85.192.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 543CC3B2A4 for ; Thu, 30 Nov 2017 17:35:36 -0500 (EST) Received: by mail-pf0-f180.google.com with SMTP id a90so3756940pfk.1 for ; Thu, 30 Nov 2017 14:35:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ap6RixtzFP31W+0Lp0B2GWftKVVd0HnbyGPvll5YtfY=; b=Ldkxwm//OvgD+5KbwLfvGq2lYIhn1emnCFgxBuHfy6NKVnIMY6kUOxdr8f3WL/5dVQ FzRsobwdUF9KVFIQOXvRFTei6kOFMCu+ghF/90HTFClOnczT2mzO456R5EugB0+3fq8Q QMrPiDdP7RXhScnMZj1ei8N10XfvzQNwDs8zXAGkmlyGVHP5YGHWwtNZ0peuoMTe2tsB /BCJS4a9ngx2rZzGylhWXPkO6ce0VoEtlbl/sTTwptmjn5kgE+Xl9JLd+Z0wkXHgePwf x5hRFFUht7zlRJhjRrpa+xxDyEPi5KWayNmnUvRGhraCXiz15/t/NgJeAq4fEm709Axh OGDA== X-Gm-Message-State: AJaThX4DpbQ3iXf/8lw/BTtUDGB6q4HWv83T8RQkOwIEJ6SrGNC/6oZp IWz9fHxOXZAUg7i7NpLPkW4= X-Google-Smtp-Source: AGs4zMYf4AhQLDXKSQSNXvs1vHks8WKRBJoglY8j3SFshRnhO/hPhhFfD8e3L6f28+7xo4FvkOCbZA== X-Received: by 10.98.213.71 with SMTP id d68mr7906416pfg.171.1512081335350; Thu, 30 Nov 2017 14:35:35 -0800 (PST) Received: from [10.3.15.144] (184-23-135-132.dedicated.static.sonic.net. [184.23.135.132]) by smtp.gmail.com with ESMTPSA id n65sm9142965pfa.83.2017.11.30.14.35.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Nov 2017 14:35:34 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Simon Barber In-Reply-To: <87po80407u.fsf@toke.dk> Date: Thu, 30 Nov 2017 14:35:33 -0800 Cc: Jonathan Morton , Dave Taht , make-wifi-fast@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <87lgionrl5.fsf@toke.dk> <87po80407u.fsf@toke.dk> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3445.4.7) Subject: Re: [Make-wifi-fast] Fwd: Re: [iccrg] TCP behavior across WiFi pointers ? X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 22:35:36 -0000 This was our assumption (client =3D endpoint, 802.11 ACK =3D TCP = delivery), but we discovered that this is not always the case, even = where the client is the endpoint. FastACK keeps the data around and = retransmits it in this case. Simon > On Nov 30, 2017, at 12:52 AM, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > Jonathan Morton writes: >=20 >> A hint, but not a guarantee. If you generate a fake ack, you'd = better be >> prepared to retransmit the packet if, in fact, it gets lost deeper in = the >> network. >=20 > I think their use case here is an AP that (they presume) is talking > directly to the client. In which case it's probably a fair = assumption... > Most operating systems don't drop packets between the WiFi card and = the > TCP stack :) >=20 > Of course, a client may be forwarding the packet somewhere, in which > case this would probably break in interesting ways... >=20 > -Toke > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast