rfc2481.txt

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


RFC 2481                       ECN to IP                    January 1999


   CE bit.  This is the default value for the ECT bit.  The ECT bit set
   to "1" indicates that the transport protocol is willing and able to
   participate in ECN.

   The default value for the CE bit is "0".  The router sets the CE bit
   to "1" to indicate congestion to the end nodes.  The CE bit in a
   packet header should never be reset by a router from "1" to "0".

   TCP requires three changes, a negotiation phase during setup to
   determine if both end nodes are ECN-capable, and two new flags in the
   TCP header, from the "reserved" flags in the TCP flags field.  The
   ECN-Echo flag is used by the data receiver to inform the data sender
   of a received CE packet.  The Congestion Window Reduced flag is used
   by the data sender to inform the data receiver that the congestion
   window has been reduced.

8. Non-relationship to ATM's EFCI indicator or Frame Relay's FECN

   Since the ATM and Frame Relay mechanisms for congestion indication
   have typically been defined without any notion of average queue size
   as the basis for determining that an intermediate node is congested,
   we believe that they provide a very noisy signal. The TCP-sender
   reaction specified in this draft for ECN is NOT the appropriate
   reaction for such a noisy signal of congestion notification. It is
   our expectation that ATM's EFCI and Frame Relay's FECN mechanisms
   would be phased out over time within the ATM network.  However, if
   the routers that interface to the ATM network have a way of
   maintaining the average queue at the interface, and use it to come to
   a reliable determination that the ATM subnet is congested, they may
   use the ECN notification that is defined here.

   We emphasize that a *single* packet with the CE bit set in an IP
   packet causes the transport layer to respond, in terms of congestion
   control, as it would to a packet drop.  As such, the CE bit is not a
   good match to a transient signal such as one based on the
   instantaneous queue size.  However, experiments in techniques at
   layer 2 (e.g., in ATM switches or Frame Relay switches) should be
   encouraged.  For example, using a scheme such as RED (where packet
   marking is based on the average queue length exceeding a threshold),
   layer 2 devices could provide a reasonably reliable indication of
   congestion.  When all the layer 2 devices in a path set that layer's
   own Congestion Experienced bit (e.g., the EFCI bit for ATM, the FECN
   bit in Frame Relay) in this reliable manner, then the interface
   router to the layer 2 network could copy the state of that layer 2
   Congestion Experienced bit into the CE bit in the IP header.  We
   recognize that this is not the current practice, nor is it in current
   standards. However, encouraging experimentation in this manner may




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


   provide the information needed to enable evolution of existing layer
   2 mechanisms to provide a more reliable means of congestion
   indication, when they use a single bit for indicating congestion.

9. Non-compliance by the End Nodes

   This section discusses concerns about the vulnerability of ECN to
   non-compliant end-nodes (i.e., end nodes that set the ECT bit in
   transmitted packets but do not respond to received CE packets).  We
   argue that the addition of ECN to the IP architecture would not
   significantly increase the current vulnerability of the architecture
   to unresponsive flows.

   Even for non-ECN environments, there are serious concerns about the
   damage that can be done by non-compliant or unresponsive flows (that
   is, flows that do not respond to congestion control indications by
   reducing their arrival rate at the congested link).  For example, an
   end-node could "turn off congestion control" by not reducing its
   congestion window in response to packet drops. This is a concern for
   the current Internet.  It has been argued that routers will have to
   deploy mechanisms to detect and differentially treat packets from
   non-compliant flows.  It has also been argued that techniques such as
   end-to-end per-flow scheduling and isolation of one flow from
   another, differentiated services, or end-to-end reservations could
   remove some of the more damaging effects of unresponsive flows.

   It has been argued that dropping packets in itself may be an adequate
   deterrent for non-compliance, and that the use of ECN removes this
   deterrent.  We would argue in response that (1) ECN-capable routers
   preserve packet-dropping behavior in times of high congestion; and
   (2) even in times of high congestion, dropping packets in itself is
   not an adequate deterrent for non-compliance.

   First, ECN-Capable routers will only mark packets (as opposed to
   dropping them) when the packet marking rate is reasonably low. During
   periods where the average queue size exceeds an upper threshold, and
   therefore the potential packet marking rate would be high, our
   recommendation is that routers drop packets rather then set the CE
   bit in packet headers.

   During the periods of low or moderate packet marking rates when ECN
   would be deployed, there would be little deterrent effect on
   unresponsive flows of dropping rather than marking those packets. For
   example, delay-insensitive flows using reliable delivery might have
   an incentive to increase rather than to decrease their sending rate
   in the presence of dropped packets.  Similarly, delay-sensitive flows
   using unreliable delivery might increase their use of FEC in response
   to an increased packet drop rate, increasing rather than decreasing



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


   their sending rate.  For the same reasons, we do not believe that
   packet dropping itself is an effective deterrent for non-compliance
   even in an environment of high packet drop rates.

   Several methods have been proposed to identify and restrict non-
   compliant or unresponsive flows. The addition of ECN to the network
   environment would not in any way increase the difficulty of designing
   and deploying such mechanisms. If anything, the addition of ECN to
   the architecture would make the job of identifying unresponsive flows
   slightly easier.  For example, in an ECN-Capable environment routers
   are not limited to information about packets that are dropped or have
   the CE bit set at that router itself; in such an environment routers
   could also take note of arriving CE packets that indicate congestion
   encountered by that packet earlier in the path.

10. Non-compliance in the Network

   The breakdown of effective congestion control could be caused not
   only by a non-compliant end-node, but also by the loss of the
   congestion indication in the network itself.  This could happen
   through a rogue or broken router that set the ECT bit in a packet
   from a non-ECN-capable transport, or "erased" the CE bit in arriving
   packets.  As one example, a rogue or broken router that "erased" the
   CE bit in arriving CE packets would prevent that indication of
   congestion from reaching downstream receivers.  This could result in
   the failure of congestion control for that flow and a resulting
   increase in congestion in the network, ultimately resulting in
   subsequent packets dropped for this flow as the average queue size
   increased at the congested gateway.

   The actions of a rogue or broken router could also result in an
   unnecessary indication of congestion to the end-nodes.  These actions
   can include a router dropping a packet or setting the CE bit in the
   absence of congestion. From a congestion control point of view,
   setting the CE bit in the absence of congestion by a non-compliant
   router would be no different than a router dropping a packet
   unecessarily. By "erasing" the ECT bit of a packet that is later
   dropped in the network, a router's actions could result in an
   unnecessary packet drop for that packet later in the network.

   Concerns regarding the loss of congestion indications from
   encapsulated, dropped, or corrupted packets are discussed below.









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


10.1. Encapsulated packets

   Some care is required to handle the CE and ECT bits appropriately
   when packets are encapsulated and de-encapsulated for tunnels.

   When a packet is encapsulated, the following rules apply regarding
   the ECT bit.  First, if the ECT bit in the encapsulated ('inside')
   header is a 0, then the ECT bit in the encapsulating ('outside')
   header MUST be a 0.  If the ECT bit in the inside header is a 1, then
   the ECT bit in the outside header SHOULD be a 1.

   When a packet is de-encapsulated, the following rules apply regarding
   the CE bit.  If the ECT bit is a 1 in both the inside and the outside
   header, then the CE bit in the outside header MUST be ORed with the
   CE bit in the inside header.  (That is, in this case a CE bit of 1 in
   the outside header must be copied to the inside header.)  If the ECT
   bit in either header is a 0, then the CE bit in the outside header is
   ignored.  This requirement for the treatment of de-encapsulated
   packets does not currently apply to IPsec tunnels.

   A specific example of the use of ECN with encapsulation occurs when a
   flow wishes to use ECN-capability to avoid the danger of an
   unnecessary packet drop for the encapsulated packet as a result of
   congestion at an intermediate node in the tunnel.  This functionality
   can be supported by copying the ECN field in the inner IP header to
   the outer IP header upon encapsulation, and using the ECN field in
   the outer IP header to set the ECN field in the inner IP header upon
   decapsulation.  This effectively allows routers along the tunnel to
   cause the CE bit to be set in the ECN field of the unencapsulated IP
   header of an ECN-capable packet when such routers experience
   congestion.

10.2.  IPsec Tunnel Considerations

   The IPsec protocol, as defined in [ESP, AH], does not include the IP
   header's ECN field in any of its cryptographic calculations (in the
   case of tunnel mode, the outer IP header's ECN field is not
   included).  Hence modification of the ECN field by a network node has
   no effect on IPsec's end-to-end security, because it cannot cause any
   IPsec integrity check to fail.  As a consequence, IPsec does not
   provide any defense against an adversary's modification of the ECN
   field (i.e., a man-in-the-middle attack), as the adversary's
   modification will also have no effect on IPsec's end-to-end security.
   In some environments, the ability to modify the ECN field without
   affecting IPsec integrity checks may constitute a covert channel; if
   it is necessary to eliminate such a channel or reduce its bandwidth,
   then the outer IP header's ECN field can be zeroed at the tunnel
   ingress and egress nodes.



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


   The IPsec protocol currently requires that the inner header's ECN
   field not be changed by IPsec decapsulation processing at a tunnel
   egress node.  This ensures that an adversary's modifications to the
   ECN field cannot be used to launch theft- or denial-of-service
   attacks across an IPsec tunnel endpoint, as any such modifications
   will be discarded at the tunnel endpoint.  This document makes no
   change to that IPsec requirement. As a consequence of the current
   specification of the IPsec protocol, we suggest that experiments with
   ECN not be carried out for flows that will undergo IPsec tunneling at
   the present time.

   If the IPsec specifications are modified in the future to permit a
   tunnel egress node to modify the ECN field in an inner IP header
   based on the ECN field value in the outer header (e.g., copying part
   or all of the outer ECN field to the inner ECN field), or to permit
   the ECN field of the outer IP header to be zeroed during
   encapsulation, then experiments with ECN may be used in combination
   with IPsec tunneling.

   This discussion of ECN and IPsec tunnel considerations draws heavily
   on related discussions and documents from the Differentiated Services
   Working Group.

10.3.  Dropped or Corrupted Packets

   An additional issue concerns a packet that has the CE bit set at one
   router and is dropped by a subsequent router.  For the proposed use
   for ECN in this paper (that is, for a transport protocol such as TCP
   for which a dropped data packet is an indication of congestion), end
   nodes detect dropped data packets, and the congestion response of the
   end nodes to a dropped data packet is at least as strong as the
   congestion response to a received CE packet.

   However, transport protocols such as TCP do not necessarily detect
   all packet drops, such as the drop of a "pure" ACK packet; for
   example, TCP does not reduce the arrival rate of subsequent ACK
   packets in response to an earlier dropped ACK packet.  Any proposal
   for extending ECN-Capability to such packets would have to address
   concerns raised by CE packets that were later dropped in the network.

   Similarly, if a CE packet is dropped later in the network due to
   corruption (bit errors), the end nodes should still invoke congestion
   control, just as TCP would today in response to a dropped data
   packet. This issue of corrupted CE packets would have to be
   considered in any proposal for the network to distinguish between
   packets dropped due to corruption, and packets dropped due to
   congestion or buffer overflow.




Ramakrishnan & Floyd          Experimental                     [Page 15]