RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (1)

RFC 5681, "TCP Congestion Control", September 2009

Note: This RFC has been updated by RFC 9438

Source of RFC: tcpm (wit)

Errata ID: 5458
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: James McCauley
Date Reported: 2018-08-12
Verifier Name: Mirja Kühlewind
Date Verified: 2018-08-13

Section 2 says:

   DUPLICATE ACKNOWLEDGMENT: An acknowledgment is considered a
      "duplicate" in the following algorithms when (a) the receiver of
      the ACK has outstanding data, (b) the incoming acknowledgment
      carries no data, (c) the SYN and FIN bits are both off, (d) the
      acknowledgment number is equal to the greatest acknowledgment
      received on the given connection (TCP.UNA from [RFC793]) and (e)
      the advertised window in the incoming acknowledgment equals the
      advertised window in the last incoming acknowledgment.

It should say:

   DUPLICATE ACKNOWLEDGMENT: An acknowledgment is considered a
      "duplicate" in the following algorithms when (a) the receiver of
      the ACK has outstanding data, (b) the incoming acknowledgment
      carries no data, (c) the SYN and FIN bits are both off, (d) the
      acknowledgment number is equal to the greatest acknowledgment
      received on the given connection (SND.UNA from [RFC793]) and (e)
      the advertised window in the incoming acknowledgment equals the
      advertised window in the last incoming acknowledgment.

Notes:

There is no such thing as TCP.UNA in RFC793. The boundary between acknowledged and unacknowledged sent data is SND.UNA.

Status: Held for Document Update (2)

RFC 5681, "TCP Congestion Control", September 2009

Note: This RFC has been updated by RFC 9438

Source of RFC: tcpm (wit)

Errata ID: 2074
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Herbie Robinson
Date Reported: 2010-03-15
Held for Document Update by: Lars Eggert

Section 3.1 says:

   A detailed rationale and discussion of the IW setting is provided in
   [RFC3390].

It should say:

   A detailed rationale and discussion of the IW setting is provided in
   [RFC3390].  The IW value for the case when (SMSS > 1095 bytes) and (SMSS <= 
   2190 bytes) is changed from RFC3390.  The new definition will keep early 
   values of cwnd at a multiple of SMSS and avoid transmitting partial segments.

Notes:

Hopefully, I surmised the reason for the change correctly.

Errata ID: 4068
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Michael Taylor
Date Reported: 2014-08-04
Held for Document Update by: Martin Stiemerling
Date Held: 2014-11-10

Throughout the document, when it says:


Notes:

The problem is the use of the phrase "new data" in an imprecise manner to sometimes mean "previously unacknowledged data" and other times mean "never before sent data".

For example, in Section 3.1

During slow start, a TCP increments cwnd by at most SMSS bytes for
each ACK received that cumulatively acknowledges new data.

This should read

During slow start, a TCP increments cwnd by at most SMSS bytes for
each ACK received that cumulatively acknowledges previously
unacknowledged data.

I believe that throughout Section 3.1 "new data" refers to "previously unacknowledged data".

However, in Section 3.2 we have

After the fast retransmit algorithm sends what appears to be the
missing segment, the "fast recovery" algorithm governs the
transmission of new data until a non-duplicate ACK arrives.

I believe that here "new data" refers to "previously unsent data".

This is clearer in the following paragraph from Section 3.2

1. On the first and second duplicate ACKs received at a sender, a
TCP SHOULD send a segment of previously unsent data per [RFC3042]
provided that the receiver's advertised window allows, the total
FlightSize would remain less than or equal to cwnd plus 2*SMSS,
and that new data is available for transmission.

Here we can see the use of "previously unsent data" followed by "new data"
which refers to the aforementioned "previously unsent data".

While the meaning of "new data" might be clear to those with extensive experience
in TCP it is imprecise and therefore may be quite confusing to those who are learning about the protocol.

Status: Rejected (2)

RFC 5681, "TCP Congestion Control", September 2009

Note: This RFC has been updated by RFC 9438

Source of RFC: tcpm (wit)

Errata ID: 2269
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Nikolai Malykh
Date Reported: 2010-05-18
Rejected by: Lars Eggert
Date Rejected: 2010-05-20

Section 7 says:

   The description of fast retransmit and fast recovery has been
   clarified, and the use of Limited Transmit [RFC3042] is now
   recommended.

It should say:

   The description of fast retransmit and fast recovery has been
   clarified.

Notes:

Really using of Limited Transmit [RFC3042] is not recommended anywhere in RFC 5681.
--VERIFIER NOTES--
WG consensus is that this errata is incorrect.

Errata ID: 6233
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Charles Deng
Date Reported: 2020-07-20
Rejected by: Martin Duke
Date Rejected: 2020-07-21

Section 4.3 says:

Finally, after all loss in the given window of segments
has been successfully retransmitted, cwnd MUST be set to no more than
ssthresh and congestion avoidance MUST be used to further increase
cwnd.

It should say:

Finally, after all loss in the given window of segments
has been successfully retransmitted, cwnd MUST be set to no less than
ssthresh and congestion avoidance MUST be used to further increase
cwnd.

Notes:

if set cwnd no more than ssthresh, it will using slow start algorithm instead of congestion avoidance algorithm. so it should say "cwnd no less than ..." instead of "cwnd no more than ...".
--VERIFIER NOTES--
This would be a significant design change in TCP. The original text is as intended by the community.

Report New Errata



Advanced Search