<div dir="ltr">802.11 acks are packet or ampdu driven while tcp, being a byte protocol, acks bytes.  Aligning these may not be straightforward.  We test with different read() rates on the wifi clients as TCP is supposed to flow control the source's writes() as well.  Wifi clients are starting to align their sleep cycles with "natural" periodicity in traffic so having larger aggregates can help both peak average throughput as well as power consumption.  It's not obvious with Wifi that a faster RTT is always better.  (Reminds me of the early days of NASA where many designed to reduce weight without keeping in account structural integrity, shave a few grams and lose a rocket.)<br><br>Bob</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 1, 2017 at 9:42 AM, Dave Taht <span dir="ltr"><<a href="mailto:dave@taht.net" target="_blank">dave@taht.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Toke Høiland-Jørgensen <<a href="mailto:toke@toke.dk">toke@toke.dk</a>> writes:<br>
<br>
> Luca Muscariello <<a href="mailto:luca.muscariello@gmail.com">luca.muscariello@gmail.com</a>> writes:<br>
><br>
>> If I understand the text right, FastACK runs in the AP and generates an ACK<br>
>> on behalf (or despite) of the TCP client end.<br>
>> Then, it decimates dupACKs.<br>
>><br>
>> This means that there is a stateful connection tracker in the AP. Not so<br>
>> simple.<br>
>> It's almost, not entirely though, a TCP proxy doing Split TCP.<br>
><br>
> Yeah, it's very much stateful, and tied closely to both TCP and the MAC<br>
> layer. So it has all the usual middlebox issues as far as that is<br>
> concerned... Also, APs need to transfer state between each other when<br>
> the client roams.<br>
><br>
> 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>
</span>Were you always as cynical as I am?<br>
<br>
I'd like to compare (eventually) what we are trying with cake's new ack<br>
filter here, which at least doesn't lie to the endpoint.<br>
<br>
my guess, however, would be that the media access negotiation will<br>
dominate the cost, and savings from (say) reducing 10 acks to 1 would<br>
only be somewhere in the 5-20% range, for simple benchmarks.<br>
<br>
I think we might get a better rrul result, however, as we'd be able to<br>
pack more big flows into a given aggregate, with less acks there.<br>
<span class="im HOEnZb"><br>
><br>
> -Toke<br>
> ______________________________<wbr>_________________<br>
> Bloat mailing list<br>
> <a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/bloat</a><br>
</span><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>