[Tsvwg] The Addition of Explicit Congestion Notification (ECN) to IP

[Sally Floyd <[e-mail]>]

K.K. Ramakrishnan, David Black, and I have just submitted an internet-draft,
The Addition of Explicit Congestion Notification (ECN) to IP,
draft-ietf-tsvwg-ecn-00.txt, available at:
http://www.aciri.org/floyd/papers/draft-ietf-tsvwg-ecn-00.txt
http://www.aciri.org/floyd/papers/draft-ietf-tsvwg-ecn-00.ps

This draft is intended to supercede RFC 2481,
draft-ietf-tsvwg-tcp-ecn-00.txt,
draft-ietf-tsvwg-ecn-tunnels-00.txt, and
draft-ietf-ipsec-ecn-02.txt, and is being submitted to advance as
Proposed Standard. 

Discussion of this document should take place on this mailing list.

Many thanks,
- Sally

From the Summary:

   This document is intended to obsolete RFC 2481, "A Proposal to add
   Explicit Congestion Notification (ECN) to IP", which defined ECN as
   an Experimental Protocol for the Internet Community, as well as to
   obsolete three subsequent internet-drafts on ECN, "IPsec Interactions
   with ECN", "ECN Interactions with IP Tunnels", and "TCP with ECN: The
   Treatment of Retransmitted Data Packets".  This document is intended
   largely to merge the earlier documents all into a single document,
   for greater clarity, in preparation to becoming a Proposed Standard.
   The rest of this section describes the relationship between this
   document and its predecessors.

   RFC 2481 included a brief discussion of the use of ECN with encapsu-
   lated packets, and noted that for the IPsec specifications at the
   time (January 1999), flows could not safely use ECN if they were to
   traverse IPsec tunnels.  RFC 2481 also described the changes that
   could be made to IPsec tunnel specifications to made them compatible
   with ECN.  "IPsec Interactions with ECN" outlined these changes to
   IPsec tunnels in detail, and included an extensive discussion of the
   security implications of ECN (now included as Sections 18 and 19 of
   this document).  The draft of "ECN Interactions with IP Tunnels"
   extended the discussion of IPsec tunnels to include all IP tunnels.
   Because older IP tunnels are not compatible with a flow's use of ECN,
   the deployment of ECN in the Internet will create strong pressure for
   older IP tunnels to be updated to an ECN-compatible version, using
   either the limited-functionality or the full-functionality option.

   This document does not address the issue of including ECN in non-IP
   tunnels such as MPLS, GRE, L2TP, or PPTP.  An earlier preliminary
   document about adding ECN support to MPLS has since expired.

   This document expands on one area not addressed in RFC 2481, the use
   of ECN with retransmitted data packets.  That is, this document
   includes the material from "TCP with ECN: The Treatment of Retrans-
   mitted Data Packets" specifying that the ECT bit should not be set on
   retransmitted data packets.  The motivation for this additional spec-
   ification is to eliminate a possible avenue for denial-of-service
   attacks on an existing TCP connection.  Some prior deployments of
   ECN-capable TCP might not conform to the (new) requirement not to set
   the ECT bit on retransmitted packets; we do not believe this will
   cause significant problems in practice.

   This document also expands on the specification of the use of SYN
   packets for the negotiation of ECN, and specifies some optional
   behavior for this.  In particular, the document allows a TCP host to
   send a non-ECN-setup SYN packet after sending a failed ECN-setup SYN
   packet, and precisely specifies the required behavior when both ECN-
   setup SYN packets and non-ECN-setup SYN packets are sent in the same
   connection.  While some prior deployments of ECN-capable TCP might
   not conform to the requirements specified in this document, we do not
   believe that this will lead to any performance or compatibility prob-
   lems for TCP connections with a combination of TCP implementations at
   the endpoints.


_______________________________________________
tsvwg mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/tsvwg