5. Explicit Congestion Notification in IP
5. Explicit Congestion Notification in IP
This document specifies that the Internet provide a congestion indication for incipient congestion (as in RED and earlier work [RJ90]) where the notification can sometimes be through marking packets rather than dropping them. This uses the ECN field in the IP header, which contains two bits, forming four ECN codepoints, '00' to '11'. The ECN-Capable Transport (ECT) codepoints '10' and '01' are set by the data sender to indicate that the transport protocol endpoints are ECN-capable; we call them ECT(0) and ECT(1) respectively. The phrase "the ECT codepoint" in this document refers to either of the two ECT codepoints. Routers treat the ECT(0) and ECT(1) codepoints as equivalent. Senders are free to use either the ECT(0) or the ECT(1) codepoint to indicate ECT, on a packet-by-packet basis.
The primary motivation for the use of both the two ECT codepoints, ECT(0) and ECT(1), is to enable the data sender to verify that network elements are not erasing the CE codepoint, and that data receiver is reporting to the sender that the CE codepoint was set in received packets, as required by the transport protocol. Guidance on how senders and receivers use the distinction between the ECT(0) and ECT(1) codepoints will be provided in separate documents for each transport protocol. In particular, this document does not address mechanisms for TCP end-nodes to make use of the distinction between the ECT(0) and ECT(1) codepoints. Protocols and senders that only require a single ECT codepoint SHOULD use ECT(0).
The not-ECT codepoint '00' indicates a packet that is not using ECN. The CE codepoint '11' is set by a router to indicate congestion to the end nodes. Packets arriving at a full queue are dropped, as they would be in the absence of ECN.
+-----+-----+
| ECN FIELD |
+-----+-----+
ECT CE [Obsolete] RFC 2481 names for the ECN bits.
0 0 Not-ECT
0 1 ECT(1)
1 0 ECT(0)
1 1 CE
Figure 1: The ECN Field in IP
The use of two ECT codepoints essentially provides a one-bit ECN nonce in the packet header, and routers necessarily "clear" the nonce when they set the CE codepoint [SCWA99]. For example, a router that clears the CE codepoint would have additional difficulty in reconstructing the original nonce, so that repeated clearing of the CE codepoint is more likely to be detected by the end nodes. The ECN nonce also addresses possible cheating by the transport receiver in reporting to the transport sender whether or not the CE codepoint was set in received packets. The motivation for the use of two ECT codepoints is discussed in more detail in Section 20, along with some of the alternative possibilities for the fourth ECT codepoint (i.e., codepoint '01'). Backwards-compatibility with earlier ECN implementations that do not understand the ECT(1) codepoint is discussed in Section 11.
In RFC 2481 [RFC2481], the ECN field was divided into an ECN-Capable Transport (ECT) bit and a CE bit. The ECN field in RFC 2481 with only the ECN-Capable Transport (ECT) bit set corresponds to the ECT(0) codepoint in this document, and the ECN field in RFC 2481 with both the ECT and CE bits set corresponds to the CE codepoint in this document. The codepoint '01' was undefined in RFC 2481, which is why ECT(0) is recommended when only a single ECT codepoint is needed.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DS FIELD, DSCP | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+
DSCP: differentiated services codepoint
ECN: Explicit Congestion Notification
Figure 2: The Differentiated Services and ECN Fields in IP
Bits 6 and 7 in the IPv4 TOS byte are designated as the ECN field. The IPv4 TOS byte corresponds to the Traffic Class byte in IPv6, and the definition of the ECN field is the same in both cases. The definition of the IPv4 TOS byte [RFC791] and the IPv6 Traffic Class byte has been superseded by the six-bit DS (Differentiated Services) field [RFC2474, RFC2780]. Bits 6 and 7 are listed as Currently Unused in [RFC2474], and are specified in RFC 2780 for experimental use with ECN. Section 22 gives a brief history of the TOS byte.
Because of the unstable history of the TOS byte, the use of the ECN field as specified in this document cannot be guaranteed to be backwards-compatible with past uses of these two bits. The dangers of this lack of backwards-compatibility are discussed in Section 22.
The congestion control algorithms followed by end-systems must be essentially the same for ECN-capable transport as for the current congestion control response to a single dropped packet, after a transport receiver using ECN receives a CE packet. For example, for an ECN-capable TCP, the source TCP must halve its congestion window for any data window containing either packet loss or an ECN indication.
One reason for requiring the congestion control response to a CE packet to be essentially the same as the response to a dropped packet is to accommodate incremental deployment of ECN in end-systems and routers. Some routers might drop ECN-capable packets (using the same AQM policy for congestion detection, for example) while other routers set the CE codepoint at equivalent congestion levels. Similarly, a router might drop packets that are not ECN-capable but set the CE codepoint on ECN-capable packets at equivalent congestion levels. This could result in unfair treatment of different flows if the congestion control response to a CE codepoint differed from the response to a packet drop.
Another goal is that end-systems should respond to congestion at most once per data window (or more loosely, per round-trip time), to avoid multiple responses to multiple congestion indications in a single data window.
For routers, the CE codepoint of an ECN-capable packet SHOULD only be set if the router would otherwise have dropped the packet as an indication of congestion to the end nodes. When a router's buffers are not yet full and the router is prepared to drop a packet to notify end nodes of incipient congestion, the router should first check to see if the ECT codepoint is set in that packet's IP header. If it is, then the router MAY set the CE codepoint in the IP header instead of dropping the packet.
An environment where all end-nodes are ECN-capable might allow the development of new criteria for setting the CE codepoint, and new congestion control mechanisms for end-nodes to respond to CE packets. However, this is a research issue, and is not addressed further in this document.
When a router receives a CE packet (i.e., a packet with the CE codepoint set), the CE codepoint remains set and the packet is transmitted normally. When congestion is severe and a router's queue is full, the router has no choice but to drop some packets as new packets arrive. We expect that in ECN-capable environments where most of the end-systems are ECN-capable and participating in TCP or compatible congestion control mechanisms, packet dropping will become relatively uncommon. In well-provisioned ECN-capable environments, packet dropping should occur primarily during transient periods or in the presence of uncooperative sources.
The discussion above concerning when the CE may be set instead of dropping a packet applies by default to all Differentiated Services Per-Hop Behaviors (PHBs) [RFC 2475]. A PHB's specification MAY provide more detail about how compatible implementations choose between setting the CE and dropping a packet, but this is not required. A router MUST NOT set the CE instead of dropping a packet when the drop is for reasons other than congestion or it is desired to signal incipient congestion to the end nodes (e.g., a diffserv edge node might be configured to unconditionally drop certain classes of traffic in order to prevent them from entering its diffserv domain).
We anticipate that routers will set the CE codepoint based on the indication of incipient congestion as indicated by the average queue size, using the RED algorithm as proposed in [FJ93, RFC2309]. To the best of our knowledge, this is the only proposal currently being discussed in the IETF for routers to drop packets proactively before the buffers overflow. However, this document does not attempt to specify a particular active queue management mechanism, such as RED, leaving that work, if needed, to other areas of the IETF. While ECN is closely tied with the need for a reasonable active queue management mechanism at the router, the reverse is not true; active queue management mechanisms are being developed and deployed independently of ECN, using packet drops as the congestion indication in the IP architecture without ECN.