<div dir="ltr">I'm skeptical that this would improve single stream throughput by a factor of two.   The larger RTT would drive larger aggregations and it's aggregation that scales peak average throughput. <br><br>Also, the time difference between the 802.11 ack and the client network stack writing the TCP ack would probably be in the 100s of microseconds (mileage will vary.)  So it's the client's media access that will drive the increase in RTT.    It might be preferred to modify EDCA parameters to reduce media access latencies for TCP acks rather than spoof them. <br><br>Bob</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 1, 2017 at 12:39 PM, Juliusz Chroboczek <span dir="ltr"><<a href="mailto:jch@irif.fr" target="_blank">jch@irif.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>> It does increase single-flow TCP throughput by up to a factor of two,<br>
>> though... Which everyone knows is the most important benchmark number ;)<br>
<br>
> Were you always as cynical as I am?<br>
<br>
</span>(Giggle)<br>
<br>
Dave, you've always underestimated Toke ;-)<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Make-wifi-fast mailing list<br>
<a href="mailto:Make-wifi-fast@lists.bufferbloat.net">Make-wifi-fast@lists.<wbr>bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/make-wifi-fast" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/make-wifi-fast</a></div></div></blockquote></div><br></div>