RFC 2481 (rfc2481) - Page 3 of 25

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

RFC 2481                       ECN to IP                    January 1999


   routers to use the Congestion Experienced (CE) bit in a packet header
   as an indication of congestion, instead of relying solely on packet
   drops.

3. Assumptions and General Principles

   In this section, we describe some of the important design principles
   and assumptions that guided the design choices in this proposal.

   (1) Congestion may persist over different time-scales. The time
       scales that we are concerned with are congestion events that may
       last longer than a round-trip time.
   (2) The number of packets in an individual flow (e.g., TCP connection
       or an exchange using UDP) may range from a small number of
       packets to quite a large number. We are interested in managing
       the congestion caused by flows that send enough packets so that
       they are still active when network feedback reaches them.
   (3) New mechanisms for congestion control and avoidance need to co-
       exist and cooperate with existing mechanisms for congestion
       control.  In particular, new mechanisms have to co-exist with
       TCP's current methods of adapting to congestion and with routers'
       current practice of dropping packets in periods of congestion.
   (4) Because ECN is likely to be adopted gradually, accommodating
       migration is essential. Some routers may still only drop packets
       to indicate congestion, and some end-systems may not be ECN-
       capable. The most viable strategy is one that accommodates
       incremental deployment without having to resort to "islands" of
       ECN-capable and non-ECN-capable environments.
   (5) Asymmetric routing is likely to be a normal occurrence in the
       Internet. The path (sequence of links and routers) followed by
       data packets may be different from the path followed by the
       acknowledgment packets in the reverse direction.
   (6) Many routers process the "regular" headers in IP packets more
       efficiently than they process the header information in IP
       options.  This suggests keeping congestion experienced
       information in the regular headers of an IP packet.
   (7) It must be recognized that not all end-systems will cooperate in
       mechanisms for congestion control. However, new mechanisms
       shouldn't make it easier for TCP applications to disable TCP
       congestion control.  The benefit of lying about participating in
       new mechanisms such as ECN-capability should be small.

4. Random Early Detection (RED)

   Random Early Detection (RED) is a mechanism for active queue
   management that has been proposed to detect incipient congestion
   [FJ93], and is currently being deployed in the Internet backbone
   [RFC 2309].  Although RED is meant to be a general mechanism using one



Ramakrishnan & Floyd          Experimental