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 ?

  • 2
    It 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

1 Answer 1


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.