rfc3168.txt

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

Network Working Group                                    K. Ramakrishnan
Request for Comments: 3168                            TeraOptic Networks
Updates: 2474, 2401, 793                                        S. Floyd
Obsoletes: 2481                                                    ACIRI
Category: Standards Track                                       D. Black
                                                                     EMC
                                                          September 2001


      The Addition of Explicit Congestion Notification (ECN) to IP

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This memo specifies the incorporation of ECN (Explicit Congestion
   Notification) to TCP and IP, including ECN's use of two bits in the
   IP header.

Table of Contents

   1.  Introduction..................................................  3
   2.  Conventions and Acronyms......................................  5
   3.  Assumptions and General Principles............................  5
   4.  Active Queue Management (AQM).................................  6
   5.  Explicit Congestion Notification in IP........................  6
   5.1.  ECN as an Indication of Persistent Congestion............... 10
   5.2.  Dropped or Corrupted Packets................................ 11
   5.3.  Fragmentation............................................... 11
   6.  Support from the Transport Protocol........................... 12
   6.1.  TCP......................................................... 13
   6.1.1  TCP Initialization......................................... 14
   6.1.1.1.  Middlebox Issues........................................ 16
   6.1.1.2.  Robust TCP Initialization with an Echoed Reserved Field. 17
   6.1.2.  The TCP Sender............................................ 18
   6.1.3.  The TCP Receiver.......................................... 19
   6.1.4.  Congestion on the ACK-path................................ 20
   6.1.5.  Retransmitted TCP packets................................. 20



Ramakrishnan, et al.        Standards Track                     [Page 1]

RFC 3168               The Addition of ECN to IP          September 2001


   6.1.6.  TCP Window Probes......................................... 22
   7.  Non-compliance by the End Nodes............................... 22
   8.  Non-compliance in the Network................................. 24
   8.1.  Complications Introduced by Split Paths..................... 25
   9.  Encapsulated Packets.......................................... 25
   9.1.  IP packets encapsulated in IP............................... 25
   9.1.1.  The Limited-functionality and Full-functionality Options.. 27
   9.1.2.  Changes to the ECN Field within an IP Tunnel.............. 28
   9.2.  IPsec Tunnels............................................... 29
   9.2.1.  Negotiation between Tunnel Endpoints...................... 31
   9.2.1.1.  ECN Tunnel Security Association Database Field.......... 32
   9.2.1.2.  ECN Tunnel Security Association Attribute............... 32
   9.2.1.3.  Changes to IPsec Tunnel Header Processing............... 33
   9.2.2.  Changes to the ECN Field within an IPsec Tunnel........... 35
   9.2.3.  Comments for IPsec Support................................ 35
   9.3.  IP packets encapsulated in non-IP Packet Headers............ 36
   10.  Issues Raised by Monitoring and Policing Devices............. 36
   11.  Evaluations of ECN........................................... 37
   11.1.  Related Work Evaluating ECN................................ 37
   11.2.  A Discussion of the ECN nonce.............................. 37
   11.2.1.  The Incremental Deployment of ECT(1) in Routers.......... 38
   12.  Summary of changes required in IP and TCP.................... 38
   13.  Conclusions.................................................. 40
   14.  Acknowledgements............................................. 41
   15.  References................................................... 41
   16.  Security Considerations...................................... 45
   17.  IPv4 Header Checksum Recalculation........................... 45
   18.  Possible Changes to the ECN Field in the Network............. 45
   18.1.  Possible Changes to the IP Header.......................... 46
   18.1.1.  Erasing the Congestion Indication........................ 46
   18.1.2.  Falsely Reporting Congestion............................. 47
   18.1.3.  Disabling ECN-Capability................................. 47
   18.1.4.  Falsely Indicating ECN-Capability........................ 47
   18.2.  Information carried in the Transport Header................ 48
   18.3.  Split Paths................................................ 49
   19.  Implications of Subverting End-to-End Congestion Control..... 50
   19.1.  Implications for the Network and for Competing Flows....... 50
   19.2.  Implications for the Subverted Flow........................ 53
   19.3.  Non-ECN-Based Methods of Subverting End-to-end Congestion
          Control.................................................... 54
   20.  The Motivation for the ECT Codepoints........................ 54
   20.1.  The Motivation for an ECT Codepoint........................ 54
   20.2.  The Motivation for two ECT Codepoints...................... 55
   21.  Why use Two Bits in the IP Header?........................... 57
   22.  Historical Definitions for the IPv4 TOS Octet................ 58
   23.  IANA Considerations.......................................... 60
   23.1.  IPv4 TOS Byte and IPv6 Traffic Class Octet................. 60
   23.2.  TCP Header Flags........................................... 61



Ramakrishnan, et al.        Standards Track                     [Page 2]

RFC 3168               The Addition of ECN to IP          September 2001


   23.3. IPSEC Security Association Attributes....................... 62
   24.  Authors' Addresses........................................... 62
   25.  Full Copyright Statement..................................... 63

1.  Introduction

   We begin by describing TCP's use of packet drops as an indication of
   congestion.  Next we explain 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 can
   instead set the Congestion Experienced (CE) codepoint in the IP
   header of packets from ECN-capable transports.  We describe when the
   CE codepoint is to be set in routers, and describe modifications
   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.  We also describe in this document the issues
   involving the use of ECN within IP tunnels, and within IPsec tunnels
   in particular.

   One of the guiding principles for this document is that, to the
   extent possible, the mechanisms specified here be incrementally
   deployable.  One challenge to the principle of incremental deployment
   has been the prior existence of some IP tunnels that were not
   compatible with the use of ECN.  As ECN becomes deployed, non-
   compatible IP tunnels will have to be upgraded to conform to this
   document.

   This document obsoletes RFC 2481, "A Proposal to add Explicit
   Congestion Notification (ECN) to IP", which defined ECN as an
   Experimental Protocol for the Internet Community.  This document also
   updates RFC 2474, "Definition of the Differentiated Services Field
   (DS Field) in the IPv4 and IPv6 Headers", in defining the ECN field
   in the IP header, RFC 2401, "Security Architecture for the Internet
   Protocol" to change the handling of IPv4 TOS Byte and IPv6 Traffic
   Class Octet in tunnel mode header construction to be compatible with
   the use of ECN, and RFC 793, "Transmission Control Protocol", in
   defining two new flags in the TCP header.

   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



Ramakrishnan, et al.        Standards Track                     [Page 3]

RFC 3168               The Addition of ECN to IP          September 2001


   loss as an indication of congestion in the network is appropriate for
   pure best-effort data carried by TCP, with 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 (especially when 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 (with
   the reliable data delivery semantics provided by 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 (e.g., tail-drop on queue
   overflow), this means that some of the packets of latency-sensitive
   flows may be dropped. In addition, such drop policies lead to
   synchronization of loss across multiple flows.

   Active queue management mechanisms detect congestion before the queue
   overflows, and provide an indication of this congestion to the end
   nodes.  Thus, active queue management can reduce unnecessary queuing
   delay for all traffic sharing that queue.  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 mechanisms for congestion control (e.g.,
   TCP) do not have to rely on buffer overflow as the only indication of
   congestion.

   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 queuing or dropping packets from the policies
   for indicating congestion. Thus, active queue management allows
   routers to use the Congestion Experienced (CE) codepoint in a packet
   header as an indication of congestion, instead of relying solely on
   packet drops. This has the potential of reducing the impact of loss
   on latency-sensitive flows.







Ramakrishnan, et al.        Standards Track                     [Page 4]

RFC 3168               The Addition of ECN to IP          September 2001


   There exist some middleboxes (firewalls, load balancers, or intrusion
   detection systems) in the Internet that either drop a TCP SYN packet
   configured to negotiate ECN, or respond with a RST.  This document
   specifies procedures that TCP implementations may use to provide
   robust connectivity even in the presence of such equipment.

2.  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 [RFC2119].

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.

      * 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.