[Bloat] benefits of ack filtering

[Mikael Abrahamsson]

On Tue, 28 Nov 2017, Dave Taht wrote:

> Recently Ryan Mounce added ack filtering cabilities to the cake qdisc.
>
> The benefits were pretty impressive at a 50x1 Down/Up ratio:
>
> http://blog.cerowrt.org/post/ack_filtering/
>
> And quite noticeable at 16x1 ratios as well.
>
> I'd rather like to have a compelling list of reasons why not to do
> this! And ways to do it better, if not. The relevant code is hovering
> at:
>
> https://github.com/dtaht/sch_cake/blob/cobalt/sch_cake.c#L902

Your post is already quite comprehensive when it comes to downsides.

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.

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.

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?

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.

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?

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se