I'm having a hard time understanding this conceptually.

Why does TCP Reno cut its congestion window in half when it detects triple duplicate ACKs and cuts its window to 1 segment when it times out?

I understand that Reno does this, but I'm not understanding exactly why. Any help?


The short answer

  • It makes your pipe full and improve your throughput.

The long answer

  • Compare to TCP Tahoe, which has only two state Slow Start and Congestion Avoidance, TCP Reno has another state called Fast Recovery.

  • On a triple duplicate Ack,TCP Reno transitions to Fast Recovery.

  • In the Fast Recovery state, it transitions back to Congestion Avoidance when it receives a new Ack, resetting the congestion window to be half of the congestion window size when it transitioned to the Fast Recovery state.

  • On a timeout, it returns to Slow Start just as in Congestion Avoidance.

  • On receiving a duplicate Ack, it increments the congestion window by 1. (Congestion Window Inflation)

The reason not entering Slow Start state (meaning reduce the congestion window to 1) because receiving duplicate Ack tells TCP more than just a packet has been lost. The receiver can only generate the duplicate Ack when another segment is received, that segment has left the network and is in the receiver's buffer.

So still having data flowing between the two ends, and TCP Reno doesn't want to reduce the flow suddenly.

By halving the congestion window, staying in the Congestion Avoidance state, TCP Reno improves network performance.

You can see a simple test about perfomance of TCP Reno and TCP Tahoe in this link.

| improve this answer | |

The arrival of duplicate ACKs indicate that something has left the pipe, and is an indication of "not so serious congestion" and there are packet buffered, and possibly in flight so we want to keep the flow going so to speak. Reducing the congestion window to half reduces the time the pipe is empty (and there are congestion control flavors that does not reduce by that much).

A timeout is a sign of something more serious, so a more appropriate response would be to reduce the window a lot more.

| improve this answer | |

If you are looking for a justification for the multiplicative decrease factor of 0.5 (as opposed to, for example, an additive decrease, or a larger multiplicative constant like 0.9), there is one in appendix D of this paper by Van Jacobson, one of the designers of the original TCP congestion control algorithms.

| improve this answer | |
  • See Appendix D: Window adjustment policy – RussellStewart Oct 29 '15 at 21:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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