[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Protocol Action: The Addition of Explicit Congestion Notification (ECN) to IP to Proposed Standard





The IESG has approved the Internet-Draft 'The Addition of Explicit
Congestion Notification (ECN) to IP' <draft-ietf-tsvwg-ecn-04.txt> as a
Proposed Standard.  This document is the product of the Transport Area
Working Group Working Group.  The IESG contact persons are Allison
Mankin and Scott Bradner.


Technical Summary
 
   This protocol specifies the incorporation of ECN (Explicit Congestion
   Notification) into TCP and IP, including ECN's use of two bits in the
   IP header.  It describes TCP's standard use (RFC 2581) of packet
   drops as the indication of congestion.  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 the only 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.  Among other
   transports than TCP, the SCTP Proposed Standard (RFC 2960) has
   reserved bits for future support of ECN, and support of ECN in
   other transports (unreliable unicast or multicast, reliable multicast)
   is under consideration, as congestion control is developed for them.

   The protocol also describes how to use ECN within IP tunnels,
   and within IPSec tunnels in particular.  The use of ECN in the
   outer header of an IPSec tunnel might raise security concerns,
   because an adversary could tamper with the outer header congestion
   information and degrade performance.  The approach determined on is
   to make support for ECN an option for any IP tunnel, and recommend
   tradeoff analysis between limited-functionality ECN, which is
   compatible with IPSec tunnels but results in congestion signaled
   only when packets are lost, or full-functionality ECN with IPSec.

   One of the guiding principles for this document is that all the
   mechanisms specified here are incrementally deployable, both on
   the transport side and in router installations.

Working Group Summary

  The working group strongly favored moving ECN from Experimental
  (RFC 2481) to Proposed Standard.  Among the developments between
  the Experimental publication and this one were:

     The protocol support for use of ECN in IPSec packets was developed
     and the draft was approved for Informational by the IPSec WG and
     the IESG.  Rather than publish the IPSec draft standalone, it was
     incorporated (Section 9.2).

     The Transport Area WG reviewed additional enhancements, including
     clarification of the interaction of TCP retransmissions and ECN.

     Linux community members identified firewalls and IDS devices that
     drop or reset TCP SYN packets with bits set for ECN capability.
     The evaluation of the community was that these are broken devices,
     and vendors of each of the identified devices issued fixes.

  Further information (including experiment results and pointers to
  implementations) is available at http://www.aciri.org/floyd/ecn.html.

Protocol Quality

  There are numerous implementations of ECN.  The authors and Area
  Directors received communications from two of the major router
  vendors expressing the goal to ship implementations of ECN as
  specified in this new draft in the near future.

  The protocol was reviewed for the IESG by Allison Mankin.

  During Last Call on draft-ietf-tsvwg-ecn-02.txt, an effective
  design, using nonces, for preventing receiver cheating with ECN
  was brought to the TSVWG.  This work was adopted into the TSVWG
  charter by strong WG consensus and the WG had consensus to adjust
  the definition of ECN codepoints so that they would be compatible
  with eventual standardization of nonce protection.  A new Last Call
  was issued.  No negative comments were received during either Last
  Call.