RFC 2481 (rfc2481) - Page 4 of 25

A Proposal to add Explicit Congestion Notification (ECN) to IP

RFC 2481                       ECN to IP                    January 1999


   of several alternatives for congestion indication, in the current
   environment of the Internet RED is restricted to using packet drops
   as a mechanism for congestion indication.  RED drops packets based on
   the average queue length exceeding a threshold, rather than only when
   the queue overflows.  However, when RED drops packets before the
   queue actually overflows, RED is not forced by memory limitations to
   discard the packet.

   RED could set a Congestion Experienced (CE) bit in the packet header
   instead of dropping the packet, if such a bit was provided in the IP
   header and understood by the transport protocol.  The use of the CE
   bit would allow the receiver(s) to receive the packet, avoiding the
   potential for excessive delays due to retransmissions after packet
   losses.  We use the term 'CE packet' to denote a packet that has the
   CE bit set.

5. Explicit Congestion Notification in IP

   We propose 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 would require an ECN field in the IP header with
   two bits.  The ECN-Capable Transport (ECT) bit would be set by the
   data sender to indicate that the end-points of the transport protocol
   are ECN-capable.  The CE bit would be set by the router to indicate
   congestion to the end nodes.  Routers that have a packet arriving at
   a full queue would drop the packet, just as they do now.

   Bits 6 and 7 in the IPv4 TOS octet are designated as the ECN field.
   Bit 6 is designated as the ECT bit, and bit 7 is designated as the CE
   bit.  The IPv4 TOS octet corresponds to the Traffic Class octet in
   IPv6.  The definitions for the IPv4 TOS octet [RFC 791] and the IPv6
   Traffic Class octet are intended to be superseded by the DS
   (Differentiated Services) Field [DIFFSERV].  Bits 6 and 7 are listed
   in [DIFFSERV] as Currently Unused.  Section 19 gives a brief history
   of the TOS octet.

   Because of the unstable history of the TOS octet, the use of the ECN
   field as specified in this document cannot be guaranteed to be
   backwards compatible with all past uses of these two bits.  The
   potential dangers of this lack of backwards compatibility are
   discussed in Section 19.

   Upon the receipt by an ECN-Capable transport of a single CE packet,
   the congestion control algorithms followed at the end-systems MUST be
   essentially the same as the congestion control response to a *single*
   dropped packet.  For example, for ECN-Capable TCP the source TCP is
   required to halve its congestion window for any window of data



Ramakrishnan & Floyd          Experimental