[Make-wifi-fast] On the 802.11 performance anomaly and an airtime fairness scheduler to fix it

[Jonathan Morton]

> On 3 Jul, 2016, at 11:03, David Lang <david at lang.hm> 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'?

Yes.  I meant that, for example, a laptop performing a download would both be the receiving station and the receiving TCP endpoint, which is where TCP acks are generated.

The fact that the *other* TCP endpoint is typically remote doesn’t matter, because that is mostly sending data, not acks.

 - Jonathan Morton