RFC 3168, "The Addition of Explicit Congestion Notification (ECN) to IP", September 2001Source of RFC: tsvwg (tsv)
See Also: RFC 3168 w/ inline errata
Errata ID: 3639
Publication Format(s) : TEXT
Reported By: Richard Scheffenegger
Date Reported: 2013-06-05
Verifier Name: Martin Stiemerling
Date Verified: 2015-04-17
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.
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: