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