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 ?
Network Engineering Stack Exchange is a question and answer site for network engineers. It only takes a minute to sign up.Sign up to join this community
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