[Bloat] benefits of ack filtering

Benjamin Cronce bcronce at gmail.com
Mon Dec 11 15:15:51 EST 2017

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'.

On Wed, Nov 29, 2017 at 12:09 AM, Mikael Abrahamsson <swmike at swm.pp.se>

> 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
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20171211/3338b3ab/attachment-0002.html>

More information about the Bloat mailing list