rfc2481.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,373 行 · 第 1/5 页

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
   for indicating congestion. Thus, active queue management allows





Ramakrishnan & Floyd          Experimental                      [Page 2]

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
   [RFC2309].  Although RED is meant to be a general mechanism using one



Ramakrishnan & Floyd          Experimental                      [Page 3]

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 [RFC791] 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                      [Page 4]

RFC 2481                       ECN to IP                    January 1999


   containing either a packet drop or an ECN indication.  However, we
   would like to point out some notable exceptions in the reaction of
   the source TCP, related to following the shorter-time-scale details
   of particular implementations of TCP.  For TCP's response to an ECN
   indication, we do not recommend such behavior as the slow-start of
   Tahoe TCP in response to a packet drop, or Reno TCP's wait of roughly
   half a round-trip time during Fast Recovery.

   One reason for requiring that the congestion-control response to the
   CE packet be essentially the same as the response to a dropped packet
   is to accommodate the incremental deployment of ECN in both end-
   systems and in routers.  Some routers may drop ECN-Capable packets
   (e.g., using the same RED policies for congestion detection) while
   other routers set the CE bit, for equivalent levels of congestion.
   Similarly, a router might drop a non-ECN-Capable packet but set the
   CE bit in an ECN-Capable packet, for equivalent levels of congestion.
   Different congestion control responses to a CE bit indication and to
   a packet drop could result in unfair treatment for different flows.

   An additional requirement is that the end-systems should react to
   congestion at most once per window of data (i.e., at most once per
   roundtrip time), to avoid reacting multiple times to multiple
   indications of congestion within a roundtrip time.

   For a router, the CE bit 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 the router's buffer
   is not yet full and the router is prepared to drop a packet to inform
   end nodes of incipient congestion, the router should first check to
   see if the ECT bit is set in that packet's IP header.  If so, then
   instead of dropping the packet, the router MAY instead set the CE bit
   in the IP header.

   An environment where all end nodes were ECN-Capable could allow new
   criteria to be developed for setting the CE bit, and new congestion
   control mechanisms for end-node reaction to CE packets.  However,
   this is a research issue, and as such is not addressed in this
   document.

   When a CE packet is received by a router, the CE bit is left
   unchanged, and the packet transmitted as usual. When severe
   congestion has occurred and the router's queue is full, then the
   router has no choice but to drop some packet when a new packet
   arrives.  We anticipate that such packet losses will become
   relatively infrequent when a majority of end-systems become ECN-