Re: [Bloat] benefits of ack filtering

[David Lang <david@lang.hm>]

On Tue, 12 Dec 2017, Benjamin Cronce wrote:

> I do not feel that thinning ACKs gains much for any healthy ratio of
> down:up. The overhead of those "wasteful" ACKs are on par with the overhead
> of IP+TCP headers.

assuming that there was no traffic going the other way to compete with the acks.

> Anything that can disturb the health of the Internet
> should make strong measures to prevent the end user from configuring the
> shaper in a knowingly destructive way. Like possibly letting the end user
> configure the amount of bandwidth ACKs get. I see many saying 35k pps is
> ridiculous, but that's pittance. If someone's network can't handle that,
> maybe they need a special TCP proxy. Thinning ACKs to help with bufferbloat
> is one thing, thinning ACKs because we feel TCP is too aggressive, is a can
> of worms. Research on the topic is still appreciated, but we should be
> careful about how much functionality Cake will have.

Yes, research is needed, but we need to recognize that what was appropriate when 
1Mb was a very fast link may not be appropriate when you are orders of magnatude 
faster, and where there can be significant amounts of traffic in the other 
direction.

I think that TCP is pretty wasteful of bandwidth (and txops on wifi) under most 
conditions.

Just chopping the number from 1/2 to 1/200 or something like that is obviously 
wrong, but I have a real hard time figuring out how collapsing acks that are 
sitting in a queue together into one ack will hurt. The acks that you are 
deleting are not going to get to the recipient any faster than the ack that you 
keep (at least if done correctly), so how can it make things better to delay 
acking data that you have received in order to send out many additional acks of 
parts of that data?

David Lang