rfc2481.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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


   transients or in the presence of non-cooperating sources.

   We expect that routers will set the CE bit in response to incipient
   congestion as indicated by the average queue size, using the RED
   algorithms suggested in [FJ93, RFC2309].  To the best of our
   knowledge, this is the only proposal currently under discussion in
   the IETF for routers to drop packets proactively, before the buffer
   overflows.  However, this document does not attempt to specify a
   particular mechanism for active queue management, leaving that
   endeavor, if needed, to other areas of the IETF.  While ECN is
   inextricably tied up with active queue management at the router, the
   reverse does not hold; active queue management mechanisms have been
   developed and deployed independently from ECN, using packet drops as
   indications of congestion in the absence of ECN in the IP
   architecture.

6. Support from the Transport Protocol

   ECN requires support from the transport protocol, in addition to the
   functionality given by the ECN field in the IP packet header. The
   transport protocol might require negotiation between the endpoints
   during setup to determine that all of the endpoints are ECN-capable,
   so that the sender can set the ECT bit in transmitted packets.
   Second, the transport protocol must be capable of reacting
   appropriately to the receipt of CE packets.  This reaction could be
   in the form of the data receiver informing the data sender of the
   received CE packet (e.g., TCP), of the data receiver unsubscribing to
   a layered multicast group (e.g., RLM [MJV96]), or of some other
   action that ultimately reduces the arrival rate of that flow to that
   receiver.

   This document only addresses the addition of ECN Capability to TCP,
   leaving issues of ECN and other transport protocols to further
   research.  For TCP, ECN requires three new mechanisms:  negotiation
   between the endpoints during setup to determine if they are both
   ECN-capable; an ECN-Echo flag in the TCP header so that the data
   receiver can inform the data sender when a CE packet has been
   received; and a Congestion Window Reduced (CWR) flag in the TCP
   header so that the data sender can inform the data receiver that the
   congestion window has been reduced. The support required from other
   transport protocols is likely to be different, particular for
   unreliable or reliable multicast transport protocols, and will have
   to be determined as other transport protocols are brought to the IETF
   for standardization.







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


6.1. TCP

   The following sections describe in detail the proposed use of ECN in
   TCP.  This proposal is described in essentially the same form in
   [Floyd94]. We assume that the source TCP uses the standard congestion
   control algorithms of Slow-start, Fast Retransmit and Fast Recovery
   [RFC 2001].

   This proposal specifies two new flags in the Reserved field of the
   TCP header.  The TCP mechanism for negotiating ECN-Capability uses
   the ECN-Echo flag in the TCP header.  (This was called the ECN Notify
   flag in some earlier documents.)  Bit 9 in the Reserved field of the
   TCP header is designated as the ECN-Echo flag.  The location of the
   6-bit Reserved field in the TCP header is shown in Figure 3 of RFC
   793 [RFC793].

   To enable the TCP receiver to determine when to stop setting the
   ECN-Echo flag, we introduce a second new flag in the TCP header, the
   Congestion Window Reduced (CWR) flag.  The CWR flag is assigned to
   Bit 8 in the Reserved field of the TCP header.

   The use of these flags is described in the sections below.

6.1.1.  TCP Initialization

   In the TCP connection setup phase, the source and destination TCPs
   exchange information about their desire and/or capability to use ECN.
   Subsequent to the completion of this negotiation, the TCP sender sets
   the ECT bit in the IP header of data packets to indicate to the
   network that the transport is capable and willing to participate in
   ECN for this packet. This will indicate to the routers that they may
   mark this packet with the CE bit, if they would like to use that as a
   method of congestion notification. If the TCP connection does not
   wish to use ECN notification for a particular packet, the sending TCP
   sets the ECT bit equal to 0 (i.e., not set), and the TCP receiver
   ignores the CE bit in the received packet.

   When a node sends a TCP SYN packet, it may set the ECN-Echo and CWR
   flags in the TCP header.  For a SYN packet, the setting of both the
   ECN-Echo and CWR flags are defined as an indication that the sending
   TCP is ECN-Capable, rather than as an indication of congestion or of
   response to congestion. More precisely, a SYN packet with both the
   ECN-Echo and CWR flags set indicates that the TCP implementation
   transmitting the SYN packet will participate in ECN as both a sender
   and receiver.  As a receiver, it will respond to incoming data
   packets that have the CE bit set in the IP header by setting the
   ECN-Echo flag in outgoing TCP Acknowledgement (ACK) packets.  As a
   sender, it will respond to incoming packets that have the ECN-Echo



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


   flag set by reducing the congestion window when appropriate.

   When a node sends a SYN-ACK packet, it may set the ECN-Echo flag, but
   it does not set the CWR flag.  For a SYN-ACK packet, the pattern of
   the ECN-Echo flag set and the CWR flag not set in the TCP header is
   defined as an indication that the TCP transmitting the SYN-ACK packet
   is ECN-Capable.

   There is the question of why we chose to have the TCP sending the SYN
   set two ECN-related flags in the Reserved field of the TCP header for
   the SYN packet, while the responding TCP sending the SYN-ACK sets
   only one ECN-related flag in the SYN-ACK packet.  This asymmetry is
   necessary for the robust negotiation of ECN-capability with deployed
   TCP implementations.  There exists at least one TCP implementation in
   which TCP receivers set the Reserved field of the TCP header in ACK
   packets (and hence the SYN-ACK) simply to reflect the Reserved field
   of the TCP header in the received data packet.  Because the TCP SYN
   packet sets the ECN-Echo and CWR flags to indicate ECN-capability,
   while the SYN-ACK packet sets only the ECN-Echo flag, the sending TCP
   correctly interprets a receiver's reflection of its own flags in the
   Reserved field as an indication that the receiver is not ECN-capable.

6.1.2.  The TCP Sender

   For a TCP connection using ECN, data packets are transmitted with the
   ECT bit set in the IP header (set to a "1").  If the sender receives
   an ECN-Echo ACK packet (that is, an ACK packet with the ECN-Echo flag
   set in the TCP header), then the sender knows that congestion was
   encountered in the network on the path from the sender to the
   receiver.  The indication of congestion should be treated just as a
   congestion loss in non-ECN-Capable TCP. That is, the TCP source
   halves the congestion window "cwnd" and reduces the slow start
   threshold "ssthresh".  The sending TCP does NOT increase the
   congestion window in response to the receipt of an ECN-Echo ACK
   packet.

   A critical condition is that TCP does not react to congestion
   indications more than once every window of data (or more loosely,
   more than once every round-trip time). That is, the TCP sender's
   congestion window should be reduced only once in response to a series
   of dropped and/or CE packets from a single window of data, In
   addition, the TCP source should not decrease the slow-start
   threshold, ssthresh, if it has been decreased within the last round
   trip time.  However, if any retransmitted packets are dropped or have
   the CE bit set, then this is interpreted by the source TCP as a new
   instance of congestion.





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


   After the source TCP reduces its congestion window in response to a
   CE packet, incoming acknowledgements that continue to arrive can
   "clock out" outgoing packets as allowed by the reduced congestion
   window.  If the congestion window consists of only one MSS (maximum
   segment size), and the sending TCP receives an ECN-Echo ACK packet,
   then the sending TCP should in principle still reduce its congestion
   window in half. However, the value of the congestion window is
   bounded below by a value of one MSS.  If the sending TCP were to
   continue to send, using a congestion window of 1 MSS, this results in
   the transmission of one packet per round-trip time.  We believe it is
   desirable to still reduce the sending rate of the TCP sender even
   further, on receipt of an ECN-Echo packet when the congestion window
   is one.  We use the retransmit timer as a means to reduce the rate
   further in this circumstance.  Therefore, the sending TCP should also
   reset the retransmit timer on receiving the ECN-Echo packet when the
   congestion window is one.  The sending TCP will then be able to send
   a new packet when the retransmit timer expires.

   [Floyd94] discusses TCP's response to ECN in more detail.  [Floyd98]
   discusses the validation test in the ns simulator, which illustrates
   a wide range of ECN scenarios. These scenarios include the following:
   an ECN followed by another ECN, a Fast Retransmit, or a Retransmit
   Timeout; a Retransmit Timeout or a Fast Retransmit followed by an
   ECN, and a congestion window of one packet followed by an ECN.

   TCP follows existing algorithms for sending data packets in response
   to incoming ACKs, multiple duplicate acknowledgements, or retransmit
   timeouts [RFC2001].

6.1.3.  The TCP Receiver

   When TCP receives a CE data packet at the destination end-system, the
   TCP data receiver sets the ECN-Echo flag in the TCP header of the
   subsequent ACK packet.  If there is any ACK withholding implemented,
   as in current "delayed-ACK" TCP implementations where the TCP
   receiver can send an ACK for two arriving data packets, then the
   ECN-Echo flag in the ACK packet will be set to the OR of the CE bits
   of all of the data packets being acknowledged.  That is, if any of
   the received data packets are CE packets, then the returning ACK has
   the ECN-Echo flag set.

   To provide robustness against the possibility of a dropped ACK packet
   carrying an ECN-Echo flag, the TCP receiver must set the ECN-Echo
   flag in a series of ACK packets. The TCP receiver uses the CWR flag
   to determine when to stop setting the ECN-Echo flag.






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


   When an ECN-Capable TCP reduces its congestion window for any reason
   (because of a retransmit timeout, a Fast Retransmit, or in response
   to an ECN Notification), the TCP sets the CWR flag in the TCP header
   of the first data packet sent after the window reduction.  If that
   data packet is dropped in the network, then the sending TCP will have
   to reduce the congestion window again and retransmit the dropped
   packet.  Thus, the Congestion Window Reduced message is reliably
   delivered to the data receiver.

   After a TCP receiver sends an ACK packet with the ECN-Echo bit set,
   that TCP receiver continues to set the ECN-Echo flag in ACK packets
   until it receives a CWR packet (a packet with the CWR flag set).
   After the receipt of the CWR packet, acknowledgements for subsequent
   non-CE data packets do not have the ECN-Echo flag set. If another CE
   packet is received by the data receiver, the receiver would once
   again send ACK packets with the ECN-Echo flag set.  While the receipt
   of a CWR packet does not guarantee that the data sender received the
   ECN-Echo message, this does indicate that the data sender reduced its
   congestion window at some point *after* it sent the data packet for
   which the CE bit was set.

   We have already specified that a TCP sender reduces its congestion
   window at most once per window of data.  This mechanism requires some
   care to make sure that the sender reduces its congestion window at
   most once per ECN indication, and that multiple ECN messages over
   several successive windows of data are properly reported to the ECN
   sender.  This is discussed further in [Floyd98].

6.1.4. Congestion on the ACK-path

   For the current generation of TCP congestion control algorithms, pure
   acknowledgement packets (e.g., packets that do not contain any
   accompanying data) should be sent with the ECT bit off. Current TCP
   receivers have no mechanisms for reducing traffic on the ACK-path in
   response to congestion notification.  Mechanisms for responding to
   congestion on the ACK-path are areas for current and future research.
   (One simple possibility would be for the sender to reduce its
   congestion window when it receives a pure ACK packet with the CE bit
   set). For current TCP implementations, a single dropped ACK generally
   has only a very small effect on the TCP's sending rate.

7. Summary of changes required in IP and TCP

   Two bits need to be specified in the IP header, the ECN-Capable
   Transport (ECT) bit and the Congestion Experienced (CE) bit.  The ECT
   bit set to "0" indicates that the transport protocol will ignore the





Ramakrishnan & Floyd          Experimental                     [Page 10]