errata logo graphic

Found 6 records.

Status: Verified (2)

RFC3168, "The Addition of Explicit Congestion Notification (ECN) to IP", September 2001

Source of RFC: tsvwg (tsv)

Errata ID: 2307

Status: Verified
Type: Editorial

Reported By: Nikolai Malykh
Date Reported: 2010-06-21
Verifier Name: Lars Eggert
Date Verified: 2010-06-29

Section 6.1 says:

   This proposal specifies two new flags in the Reserved field of the
   TCP header.  The TCP mechanism for negotiating ECN-Capability uses
   the ECN-Echo (ECE) flag in the TCP header.  Bit 9 in the Reserved
   field of the TCP header is designated as the ECN-Echo flag.  The
   location of the 6-bit Reserved field in the TCP header is shown in
   Figure 4 of RFC 793 [RFC793] (and is reproduced below for
   completeness).  This specification of the ECN Field leaves the
   Reserved field as a 4-bit field using bits 4-7.

It should say:

   This proposal specifies two new flags in the Reserved field of the
   TCP header.  The TCP mechanism for negotiating ECN-Capability uses
   the ECN-Echo (ECE) flag in the TCP header.  Bit 9 in the Reserved
   field of the TCP header is designated as the ECN-Echo flag.  The
   location of the 6-bit Reserved field in the TCP header is shown in
   Figure 3 of RFC 793 [RFC793] (and is reproduced below for
   completeness).  This specification of the ECN Field leaves the
   Reserved field as a 4-bit field using bits 4-7.

Notes:

Incorrect reference to Figure 4 of RFC 793


Errata ID: 2660

Status: Verified
Type: Editorial

Reported By: Bob Briscoe
Date Reported: 2010-12-04
Verifier Name: Lars Eggert
Date Verified: 2011-02-03

Section header block says:

Updates: 2474, 2401, 793

It should say:

Updates: 2474, 2401, 2003, 793

Notes:

RFC 3168 updates RFC 2003 but does not indicate this in its header block.

Specifically, Section 9 of RFC 3168 defines processing of the ECN field for Encapsulated Packets. This updates RFC 2003, which specified "IP Encapsulation within IP" at a time before the ECN field was defined.


Status: Reported (2)

RFC3168, "The Addition of Explicit Congestion Notification (ECN) to IP", September 2001

Source of RFC: tsvwg (tsv)

Errata ID: 3639

Status: Reported
Type: Technical

Reported By: Richard Scheffenegger
Date Reported: 2013-06-05

Section 6.1 / 6.1.3 says:

Section 6.1 says:


      * The receiver receives the packet with the CE codepoint set, and
        sets the ECN-Echo flag in its next TCP ACK sent to the sender.
[...]

      * The sender sets the CWR flag in the TCP header of the next
        packet sent to the receiver to acknowledge its receipt of and
        reaction to the ECN-Echo flag.

Section 6.1.3 says:


   When TCP receives a CE data packet at the destination end-system, the
   TCP data receiver sets the ECN-Echo flag in the TCP header of the
   subsequent ACK packet. 

   [...]
                                               The TCP receiver uses the
   CWR flag received from the TCP sender to determine when to stop
   setting the ECN-Echo flag.
   

It should say:

Section 6.1.3 should say:
 
   The TCP receiver uses the
   CWR flag received from the TCP sender to determine when to stop
   setting the ECN-Echo flag. This check has to be performed before  
   checking if the received segment is CE marked.

Notes:

The ordering of the text in the bullet points in section 6.1, and the text in section 6.1.3 can led to inappropriate implementations. At least Section 6.1.3 should be strict about the handling of CE-marked CWR-segments.


If CE is checked first, and ECE set, and thereafter CWR used to disable ECE, a CE-marked CWR segment will not result in the sending of an additional window of ECEs.


All derivatives of BSD used to

First, set ECE because of CE
Second, reset ECE because of CWR

However, the "authorative" NS2 sample code, the TBIT tool, Windows, Solaris and Linux would

First, reset ECE because of CWR
Second, set ECE because of CE

The latter approach seems to be the sensible one, and it was quickly fixed:

http://lists.freebsd.org/pipermail/freebsd-bugs/2010-April/039450.html


Errata ID: 3680

Status: Reported
Type: Technical

Reported By: Mirja K├╝hlewind
Date Reported: 2013-07-12

Section 6.1.1. says:

If the TCP connection does not
wish to use ECN notification for a particular packet, the sending TCP
sets the ECN codepoint to not-ECT, and the TCP receiver ignores the
CE codepoint in the received packet.

It should say:

If the TCP connection does not
wish to use ECN notification for a particular packet, the sending TCP
sets the ECN codepoint to not-ECT.

Notes:

The receiver should not ignore any CE codepoint.


Status: Held for Document Update (1)

RFC3168, "The Addition of Explicit Congestion Notification (ECN) to IP", September 2001

Source of RFC: tsvwg (tsv)

Errata ID: 2316

Status: Held for Document Update
Type: Editorial

Reported By: Nikolai Malykh
Date Reported: 2010-06-29
Held for Document Update by: Lars Eggert

Section 15 says:

   [RFC2408]    Maughan, D., Schertler, M., Schneider, M. and J. Turner,
                "Internet Security Association and Key Management
                Protocol (ISAKMP)", RFC 2409, November 1998.

It should say:

   [RFC2408]    Maughan, D., Schertler, M., Schneider, M. and J. Turner,
                "Internet Security Association and Key Management
                Protocol (ISAKMP)", RFC 2408, November 1998.

Notes:

Incorrect reference to RFC 2409


Status: Rejected (1)

RFC3168, "The Addition of Explicit Congestion Notification (ECN) to IP", September 2001

Source of RFC: tsvwg (tsv)

Errata ID: 3636

Status: Rejected
Type: Editorial

Reported By: Mirja K├╝hlewind
Date Reported: 2013-06-04
Rejected by: Martin Stiemerling
Date Rejected: 2013-07-11

Section 6.1.1. says:

If the TCP connection does not
   wish to use ECN notification for a particular packet, the sending TCP
   sets the ECN codepoint to not-ECT, and the TCP receiver ignores the
   CE codepoint in the received packet.

It should say:

If the TCP connection does not
   wish to use ECN notification for a particular packet, the sending TCP
   sets the ECN codepoint to not-ECT.

Notes:

CE should not be set on not-ECT capable packets. If this happens anyway, the CE codepoint would overwrite the ECT codepoint. Thus there is no way for the receiver to know it should ignore the CE codepoint; the sentence is therefore nonsensical.
--VERIFIER NOTES--
See discussions in the tsvwg (http://www.ietf.org/mail-archive/web/tsvwg/current/msg11989.html)


Report New Errata