<a href="https://www.usenix.org/system/files/conference/atc14/atc14-paper-salameh.pdf">https://www.usenix.org/system/files/conference/atc14/atc14-paper-salameh.pdf</a><div><br></div><div>The paper I mentioned.</div><div>Usenix ATC'14 not NSDI.</div><div><br></div><div><br></div><div><span></span><br><br>On Sunday, 3 July 2016, Jonathan Morton <<a href="mailto:chromatix99@gmail.com">chromatix99@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On 3 Jul, 2016, at 10:06, David Lang <<a href="javascript:;" onclick="_e(event, 'cvml', 'david@lang.hm')">david@lang.hm</a>> wrote:<br>
><br>
> 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?<br>
<br>
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.<br>
<br>
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.<br>
<br>
 - Jonathan Morton<br>
<br>
</blockquote></div>