<div dir="ltr">I wonder if TCP could be effectively changed to send an ACK every WindowSize/N number of packets. We'd need to be careful about how this would affect 'slow start'.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 29, 2017 at 12:09 AM, Mikael Abrahamsson <span dir="ltr"><<a href="mailto:swmike@swm.pp.se" target="_blank">swmike@swm.pp.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, 28 Nov 2017, Dave Taht wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Recently Ryan Mounce added ack filtering cabilities to the cake qdisc.<br>
<br>
The benefits were pretty impressive at a 50x1 Down/Up ratio:<br>
<br>
<a href="http://blog.cerowrt.org/post/ack_filtering/" rel="noreferrer" target="_blank">http://blog.cerowrt.org/post/a<wbr>ck_filtering/</a><br>
<br>
And quite noticeable at 16x1 ratios as well.<br>
<br>
I'd rather like to have a compelling list of reasons why not to do<br>
this! And ways to do it better, if not. The relevant code is hovering<br>
at:<br>
<br>
<a href="https://github.com/dtaht/sch_cake/blob/cobalt/sch_cake.c#L902" rel="noreferrer" target="_blank">https://github.com/dtaht/sch_c<wbr>ake/blob/cobalt/sch_cake.c#L90<wbr>2</a><br>
</blockquote>
<br></span>
Your post is already quite comprehensive when it comes to downsides.<br>
<br>
The better solution would of course be to have the TCP peeps change the way TCP works so that it sends fewer ACKs. I don't want middle boxes making "smart" decisions when the proper solution is for both end TCP speakers to do less work by sending fewer ACKs. In the TCP implementations I tcpdump regularily, it seems they send one ACK per 2 downstream packets.<br>
<br>
At 1 gigabit/s that's in the order of 35k pps of ACKs (100 megabyte/s divided by 1440 divided by 2). That's in my opinion completely ludicrous rate of ACKs for no good reason.<br>
<br>
I don't know what the formula should be, but it sounds like the ACK sending ratio should be influenced by how many in-flight ACKs there might be. Is there any reason to have more than 100 ACKs in flight at any given time? 500? 1000?<br>
<br>
My DOCSIS connection (inferred through observation) seems to run on 1ms upstream time slots, and my modem will delete contigous ACKs at 16 or 32 ACK intervals, ending up running at typically 1-2 ACKs per 1ms time slot. This cuts down the ACK rate when I do 250 megabit/s downloads from 5-8 megabit/s to 400 kilobit/s of used upstream bw.<br>
<br>
Since this ACK reduction is done on probably hundreds of millions of fixed-line subscriber lines today, what arguments do designers of TCP have to keep sending one ACK per 2 received TCP packets?<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Mikael Abrahamsson    email: <a href="mailto:swmike@swm.pp.se" target="_blank">swmike@swm.pp.se</a></font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">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>
</div></div></blockquote></div><br></div>