On Sun, 3 Jul 2016, Jonathan Morton wrote:

>> On 3 Jul, 2016, at 10:06, David Lang <david@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'?

David Lang