RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Verified (1)

RFC 2018, "TCP Selective Acknowledgment Options", October 1996

Source of RFC: tcplw (tsv)

Errata ID: 1610
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Matt Mathis
Date Reported: 2008-11-22
Verifier Name: Lars Eggert
Date Verified: 2008-12-19

Section 5.1 says:

   The use of time-outs as a fall-back mechanism for detecting dropped
   packets is unchanged by the SACK option.  Because the data receiver
   is allowed to discard SACKed data, when a retransmit timeout occurs
   the data sender MUST ignore prior SACK information in determining
   which data to retransmit.

It should say:

   The use of time-outs as a fall-back mechanism for detecting dropped
   packets is unchanged by the SACK option.  Because the data receiver
   is allowed to discard SACKed data, when a retransmit timeout occurs
   the data sender SHOULD ignore prior SACK information in determining
   which data to retransmit.

Notes:

At least one OS (Linux) violates the MUST to good effect: Even when timeout
driven, it keeps old SACK data so it can avoid retransmitting data already at
the receiver. Thus even under severe bandwidth exhaustion, 100% of the data
delivered to the receiver causes forward progress and the system is not subject
to classical congestion collapse (that is, congestion collapse from
unnecessarily-retransmitted packets).

When this draft is reopened, this text should be further refined to address a
number of additional issues. In particular:

- It has been observed that clearing the scoreboard on timeouts sometimes
causes very inefficient network utilization, with large quantities of
duplicated data delivered to the receiver.

- There is some risk of deadlock if the timeout was caused a corrupted
scoreboard or if the receiver reneges SACK blocks. It is important that the
checks for reneging and inconsistent scoreboards are robust. Furthermore,
there probably should be a mandatory fall back mechanism, such as requiring
classical fast retransmit and new reno behavior, or ultimately under repeated
timeouts with no forward progress, clearing the scoreboard.

- Making SACK more robust in the presence of timeouts may increase the risk of
congestion collapse associated with cascaded bottlenecks, because it may
enable TCP to function under unreasonably high loss rates.

Status: Reported (1)

RFC 2018, "TCP Selective Acknowledgment Options", October 1996

Source of RFC: tcplw (tsv)

Errata ID: 6602
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Christian Reusch
Date Reported: 2021-06-07

Section 5.1 says:

   This document does not attempt to specify in detail the congestion
   control algorithms for implementations of TCP with SACK.  However,
   the congestion control algorithms present in the de facto standard
   TCP implementations MUST be preserved [Stevens94].  In particular, to
   preserve robustness in the presence of packets reordered by the
   network, recovery is not triggered by a single ACK reporting out-of-
   order packets at the receiver.  Further, during recovery the data
   sender limits the number of segments sent in response to each ACK.
   Existing implementations limit the data sender to sending one segment
   during Reno-style fast recovery, or to two segments during slow-start
   [Jacobson88].  Other aspects of congestion control, such as reducing
   the congestion window in response to congestion, must similarly be
   preserved.

It should say:

   This document does not attempt to specify in detail the congestion
   control algorithms for implementations of TCP with SACK.  However,
   the congestion control algorithms present in the de facto standard
   TCP implementations MUST be preserved [Stevens94].  In particular, to
   preserve robustness in the presence of packets reordered by the
   network, recovery is not triggered by a single ACK reporting out-of-
   order packets at the receiver.  Further, during recovery the data
   sender limits the number of segments sent in response to each ACK.
   Existing implementations limit the data sender to sending one segment
   during Reno-style recovery upon a timeout , or to two segments during slow-start
   [Jacobson88].  Other aspects of congestion control, such as reducing
   the congestion window in response to congestion, must similarly be
   preserved.

Notes:

RFC 2581, Section 3.1 sets the cndw to a value of 1:
...
Furthermore, upon a timeout cwnd MUST be set to no more than the loss
window, LW, which equals 1 full-sized segment (regardless of the
value of IW). Therefore, after retransmitting the dropped segment
the TCP sender uses the slow start algorithm to increase the window
from 1 full-sized segment to the new value of ssthresh, at which
point congestion avoidance again takes over.

Whereas in the Fast Recovery section(3.2) the cwnd is set by the following formula:
...
The fast retransmit and fast recovery algorithms are usually
implemented together as follows.

1. When the third duplicate ACK is received, set ssthresh to no more
than the value given in equation 3.
2. Retransmit the lost segment and set cwnd to ssthresh plus 3*SMSS.
This artificially "inflates" the congestion window by the number
of segments (three) that have left the network and which the
receiver has buffered.

3. For each additional duplicate ACK received, increment cwnd by
SMSS. This artificially inflates the congestion window in order
to reflect the additional segment that has left the network.

4. Transmit a segment, if allowed by the new value of cwnd and the
receiver's advertised window.

5. When the next ACK arrives that acknowledges new data, set cwnd to
ssthresh (the value set in step 1). This is termed "deflating"
the window.

This ACK should be the acknowledgment elicited by the
retransmission from step 1, one RTT after the retransmission
(though it may arrive sooner in the presence of significant out-
of-order delivery of data segments at the receiver).
Additionally, this ACK should acknowledge all the intermediate
segments sent between the lost segment and the receipt of the
third duplicate ACK, if none of these were lost.

Report New Errata