[Make-wifi-fast] On the 802.11 performance anomaly and an airtime fairness scheduler to fix it
david at lang.hm
Sun Jul 3 04:03:43 EDT 2016
On Sun, 3 Jul 2016, Jonathan Morton wrote:
>> On 3 Jul, 2016, at 10:06, 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
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'?
More information about the Make-wifi-fast