Is there any reason of choosing "3" only for retransmission. why not 2 or 4 or any other number?

2 Answers 2


You're referring to 'Fast Retransmit' in the TCP Reno implementation. It is basically an assumption.

RFC 2001, TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms covers this:

Since TCP does not know whether a duplicate ACK is caused by a lost segment or just a reordering of segments, it waits for a small number of duplicate ACKs to be received.

It is assumed that if there is just a reordering of the segments, there will be only one or two duplicate ACKs before the reordered segment is processed, which will then generate a new ACK. If three or more duplicate ACKs are received in a row, it is a strong indication that a segment has been lost.

The key here is that Reno wants to avoid slow-start it makes the assumption that 3 dup-acks received without any intervening packets is the receiver indicating that it wants that single segment resent(fast re-transmit). If a timeout occurs that is when Reno will trigger slow start.

RFC 2001, TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms, Section 4, Fast Recovery:

After fast retransmit sends what appears to be the missing segment, congestion avoidance, but not slow start is performed. This is the fast recovery algorithm. It is an improvement that allows high throughput under moderate congestion, especially for large windows.

The reason for not performing slow start in this case is that the receipt of the duplicate ACKs tells TCP more than just a packet has been lost. Since 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. That is, there is still data flowing between the two ends, and TCP does not want to reduce the flow abruptly by going into slow start.

The fast retransmit and fast recovery algorithms are usually implemented together as follows.

  1. When the third duplicate ACK in a row is received, set ssthresh to one-half the current congestion window, cwnd, but no less than two segments. Retransmit the missing segment. Set cwnd to ssthresh plus 3 times the segment size. This inflates the congestion window by the number of segments that have left the network and which the other end has cached (3).

  2. Each time another duplicate ACK arrives, increment cwnd by the segment size. This inflates the congestion window for the additional segment that has left the network. Transmit a packet, if allowed by the new value of cwnd.

  3. When the next ACK arrives that acknowledges new data, set cwnd to ssthresh (the value set in step 1). This ACK should be the acknowledgment of the retransmission from step 1, one round-trip time after the retransmission. Additionally, this ACK should acknowledge all the intermediate segments sent between the lost packet and the receipt of the first duplicate ACK. This step is congestion avoidance, since TCP is down to one-half the rate it was at when the packet was lost.

The fast retransmit algorithm first appeared in the 4.3BSD Tahoe release, and it was followed by slow start. The fast recovery algorithm appeared in the 4.3BSD Reno release.


I created two GIFs to illustrate the 2 cases.

  • Either DUP ACK just means out-of-order segment (there will be no loss and the sending TCP doesn't need to retransmit anything). It's just the sending TCP sent 1, 2, 3, but the receiver receives 1, 3, 2. So there is temporarily a "hole" in the reassembly process, that will be filled quickly later as the delayed segment eventually arrives.

  • Or it means there is a segment that will never arrive (loss) and the sender will eventually need to retransmit it. There will be a permanent "hole" in the reassembly process on receiver side, so receiver will keep repeating "thank you for the new segments, but I still need that previous missing one before we can slide the window further".

We can't know it at first, so, 3 DUP ACKs is considered a "sweet spot" (probability of having 3 out-of-order segments in a row is very low).

DUP ACK for out-of-order segment (no loss)

DUP ACK for out-of-order segment (no loss)

DUP ACK for lost segment (retransmission needed)

DUP ACK for lost segment (retransmission needed)

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.