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: swm...@swm.pp.se
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
