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
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.
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.
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.
