Why is the standard TCP sender response to packet-loss (congestion), to drop 50% of the sending rate and then start working back up ?
If packet-loss was 20%, why not just drop 20% or maybe 25% to be safe ?
1
-
2It is not the sending rate, it is the window size. It will still send at the same rate within the window, but it is just a half-size window.– Ron Maupin ♦Commented Sep 23, 2022 at 12:17
Add a comment
|
1 Answer
TCP adapts the receive window size when it detects congestion, ie. when packet loss occurs. There are several congestion algorithms, starting with the original Tahoe. An overview: https://en.wikipedia.org/wiki/TCP_congestion_control.
What you're referring to is called the additive-increase/multiplicative-decrease (AIMD) algorithm. This basic model has been derived through simulations and has proven itself in the real world.
Basically, unless you quickly reduce traffic to a level below that which is causing congestion, the latter will dominate and suffocate the link.
The basic assumption is that I was using the channel by myself before, and now there's another stream competing for bandwidth, so I'll reduce mine by 50%. Since the sender has no way of knowing whether that is true or when the competing stream has ended, it tries to slowly increase its window/bandwidth again until congestion is detected again.
To date, this rather defensive way of treating shared bandwidth is the best way to handle the problem that's been found.
Here's a rather old paper but it's a good starter: https://www.icir.org/floyd/papers/sacks.pdf
-
I don't think this is really an answer just to say that a 50% reduction works best. Could you at least point to some paper which tested this compared to the approach I suggested? I suggest that dropping the packet rate by a little more than the current achieved packet rate should be enough to eliminate congestion. Commented Oct 23, 2022 at 20:59
-
@GroovyDotCom Check the updated answer for a starter link.– Zac67 ♦Commented Oct 23, 2022 at 21:13