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

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

Network Working Group                                    K. Ramakrishnan
Request for Comments: 2481                            AT&T Labs Research
Category: Experimental                                          S. Floyd
                                                                    LBNL
                                                            January 1999

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

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This note describes a proposed addition of ECN (Explicit Congestion
   Notification) to IP.  TCP is currently the dominant transport
   protocol used in the Internet. We begin by describing TCP's use of
   packet drops as an indication of congestion.  Next we argue that with
   the addition of active queue management (e.g., RED) to the Internet
   infrastructure, where routers detect congestion before the queue
   overflows, routers are no longer limited to packet drops as an
   indication of congestion.  Routers could instead set a Congestion
   Experienced (CE) bit in the packet header of packets from ECN-capable
   transport protocols.  We describe when the CE bit would be set in the
   routers, and describe what modifications would be needed to TCP to
   make it ECN-capable.  Modifications to other transport protocols
   (e.g., unreliable unicast or multicast, reliable multicast, other
   reliable unicast transport protocols) could be considered as those
   protocols are developed and advance through the standards process.

1.  Conventions and Acronyms

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [B97].

Ramakrishnan & Floyd          Experimental                      [Page 1]
RFC 2481                       ECN to IP                    January 1999

2. Introduction

   TCP's congestion control and avoidance algorithms are based on the
   notion that the network is a black-box [Jacobson88, Jacobson90].  The
   network's state of congestion or otherwise is determined by end-
   systems probing for the network state, by gradually increasing the
   load on the network (by increasing the window of packets that are
   outstanding in the network) until the network becomes congested and a
   packet is lost.  Treating the network as a "black-box" and treating
   loss as an indication of congestion in the network is appropriate for
   pure best-effort data carried by TCP which has little or no
   sensitivity to delay or loss of individual packets.  In addition,
   TCP's congestion management algorithms have techniques built-in (such
   as Fast Retransmit and Fast Recovery) to minimize the impact of
   losses from a throughput perspective.

   However, these mechanisms are not intended to help applications that
   are in fact sensitive to the delay or loss of one or more individual
   packets.  Interactive traffic such as telnet, web-browsing, and
   transfer of audio and video data can be sensitive to packet losses
   (using an unreliable data delivery transport such as UDP) or to the
   increased latency of the packet caused by the need to retransmit the
   packet after a loss (for reliable data delivery such as TCP).

   Since TCP determines the appropriate congestion window to use by
   gradually increasing the window size until it experiences a dropped
   packet, this causes the queues at the bottleneck router to build up.
   With most packet drop policies at the router that are not sensitive
   to the load placed by each individual flow, this means that some of
   the packets of latency-sensitive flows are going to be dropped.
   Active queue management mechanisms detect congestion before the queue
   overflows, and provide an indication of this congestion to the end
   nodes.  The advantages of active queue management are discussed in
   RFC 2309 [RFC2309].  Active queue management avoids some of the bad
   properties of dropping on queue overflow, including the undesirable
   synchronization of loss across multiple flows.  More importantly,
   active queue management means that transport protocols with
   congestion control (e.g., TCP) do not have to rely on buffer overflow
   as the only indication of congestion.  This can reduce unnecessary
   queueing delay for all traffic sharing that queue.

   Active queue management mechanisms may use one of several methods for
   indicating congestion to end-nodes. One is to use packet drops, as is
   currently done. However, active queue management allows the router to
   separate policies of queueing or dropping packets from the policies