From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (lang.hm [66.167.227.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 0D8113B25D for ; Sun, 3 Jul 2016 04:03:46 -0400 (EDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id u6383hMO016123; Sun, 3 Jul 2016 01:03:43 -0700 Date: Sun, 3 Jul 2016 01:03:43 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Jonathan Morton cc: Luca Muscariello , "make-wifi-fast@lists.bufferbloat.net" In-Reply-To: Message-ID: References: <87ziq2o07z.fsf@toke.dk> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="680960-1171891092-1467533023=:18304" Subject: Re: [Make-wifi-fast] On the 802.11 performance anomaly and an airtime fairness scheduler to fix it 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: Sun, 03 Jul 2016 08:03:47 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --680960-1171891092-1467533023=:18304 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 3 Jul 2016, Jonathan Morton wrote: >> On 3 Jul, 2016, at 10:06, David Lang wrote: >> >> do they delay the L2 Ack until the L4 ack comes back? If so, how does that >> work on long-latency connections where it takes a long time for the L4 ack to >> show up? > > I’m pretty sure it’s only meant to work when the TCP endpoint is local to the > receiving station, assuring low turnaround latency. This is the typical case, > so it’s a win. how is it the typical case that a wifi connection it to a local system not to something over the Internet? Even in business settings, Internet bound traffic can be the majority (cloud based e-mail, google docs, etc) > With that said, there’s no fundamental reason why the piggybacked L4 ack need > be the one corresponding to the L2 ack. It just needs to be a small packet > that won’t unduly extend the airtime occupied by the ack anyway, and which > won’t mind being lost if the L2 ack gets squashed. A scheme allowing a > certain amount of slop in this way would accommodate remote TCP endpoints as > well as local ones. Given the normal overhead of any txop, being able to piggy back a small amount of real data at high speed with the L2 ack would be a significant win in many cases. For the common case of downloading from the Internet, the endpoint system should be able to return a real L4 ack fast enough to piggy back it on the L2 ack. If that what is meant by the 'typical case'? David Lang --680960-1171891092-1467533023=:18304--