The NewReno Modification to TCP's Fast Recovery Algorithm
obsoletes
- rfc-3782 — The NewReno Modification to TCP's Fast Recovery Algorithm
Extracted elements (21)
A timestamp-based heuristic uses the fact that a hole in sequence space causes duplicate ACKs to echo the timestamp of the last data packet that advanced the cumulative ACK. If the echoed timestamp equals the stored timestamp of the last acknowledged segment, this indicates a lost segment; otherwise it indicates unnecessary retransmission.
An ACK-based heuristic can distinguish spurious duplicate ACKs from those indicating real loss: if cwnd > SMSS and the difference between highest_ack and prev_highest_ack is at most 4*SMSS, duplicate ACKs indicate a lost segment; otherwise they likely result from unnecessary retransmissions. The cwnd check prevents fast retransmit immediately after a timeout.
NewReno was developed to address two problems with Reno TCP when multiple packet losses occur in a single window: Reno often takes a retransmit timeout, and even when avoided, multiple fast retransmits and window reductions occur. In the absence of SACK, NewReno uses partial acknowledgments to infer additional losses without requiring a timeout.
RFC 6582 changes the full-ACK cwnd formula from RFC 3782 to ensure a minimum of max(FlightSize, SMSS) + SMSS. The RFC 3782 formula could yield 1 SMSS when FlightSize is zero, causing a one-segment transmission that triggers delayed ACK at the receiver and unnecessary delays. The fix ensures at least two segments can be sent.
The congestion window is deflated after a partial acknowledgment because the window was likely considerably inflated during fast recovery. Without deflation, the sender might transmit nearly a full window of data back-to-back, causing a burst. Partial window deflation attempts to ensure approximately ssthresh data remains outstanding when fast recovery ends.
The 'recover' variable is needed to prevent multiple congestion window reductions from a single loss event. Without it, after a retransmit timeout the sender could incorrectly enter fast retransmit on duplicate ACKs that result from unnecessary retransmissions rather than new packet losses.
After a retransmit timeout, if three duplicate ACKs arrive that do not cover more than 'recover', this may indicate either unnecessary retransmissions (no action needed) or a dropped retransmitted packet (fast retransmit would help). The retransmit timer serves as the backup mechanism for packet loss detection in this ambiguous case.
NewReno applies to TCP connections unable to use the SACK option, either because SACK is not locally supported or the TCP peer did not indicate willingness to use it. When SACK is available, it provides superior information for retransmission decisions during fast recovery.
After a retransmit timeout, record the highest sequence number transmitted in the variable 'recover' and exit the fast recovery procedure if applicable. This prevents the fast retransmit mechanism from being re-entered spuriously when duplicate ACKs arrive from unnecessary retransmissions.
After cwnd is set based on the fast recovery exit procedure (step 3 of Section 3.2), cwnd must not be updated until a further event occurs (e.g., arrival of an ACK or timeout). Some implementations erroneously enter slow start or congestion avoidance immediately after the cwnd assignment.
An implementation should use a separate flag to record whether it is currently in fast recovery. Relying on the duplicate ACK counter for this purpose is unreliable because the counter can be reset upon window updates and out-of-order acknowledgments.
For the first partial ACK that arrives during fast recovery, reset the retransmit timer. This prevents the retransmit timer from expiring unnecessarily while more losses are being recovered.
On receiving a full acknowledgment (ACK covering up to and including 'recover'), set cwnd to either min(ssthresh, max(FlightSize, SMSS) + SMSS) or ssthresh, then exit fast recovery. If the first option is used, the minimum result is 2*SMSS to avoid sending only one segment when FlightSize is zero.
On receiving a partial acknowledgment during fast recovery, retransmit the first unacknowledged segment, deflate the congestion window by the amount of new data acknowledged, and add back SMSS bytes if at least one SMSS of new data was acknowledged. Do not exit fast recovery.
The data receiver should send an immediate acknowledgment for an out-of-order segment, even when that segment fills a hole in the buffer. Delaying this ACK until the delayed-ACK timer expires severely limits NewReno's benefit by postponing partial acknowledgment delivery to the sender.
The state variable 'recover' may need to be updated when the cumulative ACK field is updated outside of fast recovery, to handle sequence number wraparound that could affect ordering between the cumulative ACK field and 'recover'. Fast recovery entry is only possible when the cumulative ACK covers more than 'recover'.
When leaving fast recovery, implementations should take measures to avoid a burst of data, such as limiting the number of packets sent per ACK (maxburst). This is necessary because ACK losses or window updates during fast recovery can cause the sender to underestimate retransmissions already in flight.
When the third duplicate ACK is received, the sender checks if the cumulative ACK covers more than 'recover'. If so, 'recover' is incremented to the highest sequence number transmitted so far and the sender enters fast retransmit. If not, the sender does not enter fast retransmit and does not reset ssthresh.
The 'recover' variable is a sender-side TCP state variable that records the send sequence number that must be acknowledged before the fast recovery procedure is declared over. It is initialized to the initial send sequence number when the TCP protocol control block is initialized.
RFC 5681 discusses general security considerations for TCP congestion control. NewReno conforms to RFC 5681's congestion control requirements, so those considerations apply. There are no known additional security concerns specific to the NewReno algorithm.
NewReno fast recovery is entered when three duplicate ACKs are received and the cumulative ACK covers more than 'recover'. Fast recovery ends either when a retransmit timeout occurs or when an ACK arrives that acknowledges all data up to and including 'recover' (a full acknowledgment). Partial ACKs keep the sender in fast recovery.