--- 1/draft-ietf-tsvwg-ecn-alternates-00.txt 2006-07-28 22:12:45.000000000 +0200 +++ 2/draft-ietf-tsvwg-ecn-alternates-01.txt 2006-07-28 22:12:45.000000000 +0200 @@ -1,12 +1,15 @@ Internet Engineering Task Force S. Floyd INTERNET-DRAFT ICIR + +Expires: January 2007 + Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. @@ -19,38 +22,49 @@ months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on July 2006. + This Internet-Draft will expire on January 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract There have been a number of proposals for alternate semantics for - the ECN field in the IP header [ECN]. This document discusses some - of the issues in defining alternate semantics for the ECN field, and - specifies requirements for a safe co-existence in an Internet that - could include routers that do not understand the defined alternate - semantics. This document evolved as a result of discussions with - the authors of one recent proposal for such alternate semantics. + the ECN field in the IP header [RFC3168]. This document discusses + some of the issues in defining alternate semantics for the ECN + field, and specifies requirements for a safe co-existence in an + Internet that could include routers that do not understand the + defined alternate semantics. This document evolved as a result of + discussions with the authors of one recent proposal for such + alternate semantics. NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION. + Changes from draft-ietf-tsvwg-ecn-alternates-01.txt: + + * Updated references, moved a paragraph to the Introduction. + Based on feedback from the IESG. + + Changes from draft-ietf-tsvwg-ecn-alternates-00.txt: + + * Added a pointer to the SIGCOMM 2005 paper on "One More Bit + is Enough". + Changes from draft-floyd-ecn-alternates-02.txt: * Added a subsection on proposals for edge-to-edge ECN. * Changed name to draft-ietf-tsvwg-ecn-alternates-00. Changes from draft-floyd-ecn-alternates-01.txt: * Changed requirement for TCP friendliness, to a requirement of friendliness with IETF-conformant congestion control. From email @@ -75,59 +89,76 @@ * Added to the discussion of using the diffserv code point to signal alternate ECN semantics. From email from Gorry Fairhurst. * Minor editing for clarity, also from email from Gorry Fairhurst. END OF NOTE TO RFC EDITOR. Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. An Overview of the Issues . . . . . . . . . . . . . . . . . . 3 + 2. An Overview of the Issues . . . . . . . . . . . . . . . . . . 4 3. Signalling the Use of Alternate ECN Semantics . . . . . . . . 5 - 3.1. Using the Diffserv Field for Signalling. . . . . . . . . 5 + 3.1. Using the Diffserv Field for Signalling. . . . . . . . . 6 4. Issues of Incremental Deployment. . . . . . . . . . . . . . . 6 4.1. Option 1: Unsafe for Deployment in the Internet. . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Option 2: Verification that Routers Under- stand the Alternate Semantics . . . . . . . . . . . . . . . . 8 4.3. Option 3: Friendly Co-existence with Com- - peting Traffic. . . . . . . . . . . . . . . . . . . . . . . . 8 + peting Traffic. . . . . . . . . . . . . . . . . . . . . . . . 9 5. Evaluation of the Alternate-ECN Semantics . . . . . . . . . . 11 5.1. Verification of Feedback from the Router . . . . . . . . 11 - 5.2. Co-existence with Competing Traffic. . . . . . . . . . . 11 + 5.2. Co-existence with Competing Traffic. . . . . . . . . . . 12 5.3. Proposals for Alternate-ECN with Edge-to- Edge Semantics. . . . . . . . . . . . . . . . . . . . . . . . 12 5.4. A General Evaluation of the Alternate-ECN - Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 6. Who Wants to Use Alternate Semantics for the ECN - Codepoint? . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 13 - 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 10. Normative References . . . . . . . . . . . . . . . . . . . . 13 - 11. Informative References . . . . . . . . . . . . . . . . . . . 13 - IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . 14 - AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 14 + 9. Normative References. . . . . . . . . . . . . . . . . . . . . 14 + 10. Informative References . . . . . . . . . . . . . . . . . . . 14 + IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . 15 + AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 15 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction RFC 3168, a Proposed Standard document, defines the ECN field in the IP header, and specifies the semantics for the codepoints for the ECN field. However, end nodes could specify the use of alternate semantics for the ECN field, e.g., using codepoints in the diffserv - field of the IP header. This document describes some of the issues - that arise in specifying such alternate semantics for the ECN field, - and gives requirements for a safe co-existence in a world using the - default ECN semantics (or using no ECN at all). + field of the IP header. + + There have been a number of proposals in the IETF and in the + research community for alternate semantics for the ECN codepoint. + One such proposal, [BCF05], proposes an alternate-ECN semantics for + real-time inelastic traffic such as voice, video conferencing, and + multimedia streaming in DiffServ networks. In this proposal, the + alternate-ECN semantics would provide information about two levels + of congestion experienced along the path [BCF05]. Another research + proposal, [XSSK05], proposes a low-complexity protocol, Variable- + structure congestion Control Protocol (VCP), that uses the two bits + in the ECN field to indicate low-load, high-load, and overload + (congestion), where transport protocols can increase more rapidly + during the low-load regime. Some of the proposals for alternate-ECN + semantics are for ECN used in an edge-to-edge context between + gateways at the edge of a network region, e.g., for pre-congestion + notification for admissions control [BESFC06]. Other proposals for + alternate ECN semantics are listed on the ECN Web Page [ECN]. + + This document describes some of the issues that arise in specifying + alternate semantics for the ECN field, and gives requirements for a + safe co-existence in a world using the default ECN semantics (or + using no ECN at all). 2. An Overview of the Issues In this section we discuss some of the issues that arise if some of the traffic in a network consists of alternate-ECN traffic (i.e., traffic using alternate semantics for the ECN field). The issues include the following: (1) how routers know which ECN semantics to use with which packets; (2) incremental deployment in a network where some routers use only the default ECN semantics, or no ECN at all; (3) co-existence of alternate-ECN traffic with competing @@ -138,21 +169,21 @@ use with which packets in the network: How does the connection indicate to the router that its packets are using alternate-ECN semantics? Is the specification of alternate- ECN semantics robust and unambiguous? If not, is this a problem? As an example, in most of the proposals for alternate-ECN semantics, a diffserv field is used to specify the use of alternate-ECN semantics. Do all routers that understand this diffserv codepoint understand that it uses alternate-ECN semantics, or not? Diffserv - allows routers to re-mark DiffServ Code Point [DSCP] values within + allows routers to re-mark DiffServ Code Point (DSCP) values within the network; what is the effect of this on the alternate-ECN semantics? This is discussed in more detail in Section 3 below. (2) A second issue is that of incremental deployment in a network where some routers only use the default ECN semantics, and other routers might not use ECN at all. In this document we use the phrase "new routers" to refer to the routers that understand the alternate-ECN semantics, and "old routers" to refer to routers that @@ -373,29 +404,30 @@ "Upon the receipt by an ECN-Capable transport of a single CE packet, the congestion control algorithms followed at the end-systems MUST be essentially the same as the congestion control response to a *single* dropped packet. For example, for ECN-Capable TCP the source TCP is required to halve its congestion window for any window of data containing either a packet drop or an ECN indication." The only conformant congestion control mechanisms currently standardized in the IETF are TCP [RFC2581] and protocols using TCP- like congestion control (e.g., SCTP [RFC2960], DCCP with CCID-2 - [DCCP]), and TCP-Friendly Rate Control (TFRC) and protocols with - TFRC-like congestion control (e.g., DCCP using CCID-3 [DCCP]). TCP - uses Additive-Increase Multiplicative-Decrease congestion control, - and responds to the loss or ECN-marking of a single packet by - halving its congestion window. In contrast, the equation-based - congestion control mechanism in TFRC estimates the loss event rate - over some period of time, and uses a sending rate that would be - comparable, in packets per round-trip-time, to that of a TCP - connection experiencing the same loss event rate. + ([RFC4340], [RFC4341])), and TCP-Friendly Rate Control (TFRC) + [RFC3448] and protocols with TFRC-like congestion control (e.g., + DCCP using CCID-3 [RFC4342]). TCP uses Additive-Increase + Multiplicative-Decrease congestion control, and responds to the loss + or ECN-marking of a single packet by halving its congestion window. + In contrast, the equation-based congestion control mechanism in TFRC + estimates the loss event rate over some period of time, and uses a + sending rate that would be comparable, in packets per round-trip- + time, to that of a TCP connection experiencing the same loss event + rate. So what are the requirements in order for alternate-ECN traffic to compete appropriately with other traffic on a path through an old router that doesn't understand the alternate ECN semantics (and therefore might be using the default ECN semantics)? The first and second requirements below concern compatibility between traffic using alternate ECN semantics and routers using default ECN semantics. The first requirement for compatibility with routers using default @@ -515,120 +547,124 @@ this should be addressed in the specification of the diffserv codepoint itself. 5.3. Proposals for Alternate-ECN with Edge-to-Edge Semantics RFC 3168 specifies the use of the default ECN semantics by an end- to-end transport protocol, with the requirement that "upon the receipt by an ECN-Capable transport of a single CE packet, the congestion control algorithms followed at the end-systems MUST be essentially the same as the congestion control response to a - *single* dropped packet" [RFC3168, Section 5]. In contrast, some of - the proposals for alternate-ECN semantics are for ECN used in an + *single* dropped packet" ([RFC3168], Section 5). In contrast, some + of the proposals for alternate-ECN semantics are for ECN used in an edge-to-edge context between gateways at the edge of a network - region, e.g., for pre-congestion notification for admissions control - [BESFC05]. + region, e.g., [BESFC06]. When alternate-ECN is defined with edge-to-edge semantics, this definition needs to ensure that the edge-to-edge semantics do not conflict with a connection using other ECN semantics end-to-end. One way to avoid conflict would be for the edge-to-edge ECN proposal to include some mechanism to ensure that the edge-to-edge ECN is not used for connections that are using other ECN semantics (standard or otherwise) end-to-end. Alternately, the edge-to-edge semantics could be defined so that they do not conflict with a connection using other ECN semantics end-to-end. 5.4. A General Evaluation of the Alternate-ECN Semantics A third general issue concerns the evaluation of the general merits of the proposed alternate-ECN semantics. Again, it would be beyond the scope of this document to specify requirements for the general evaluation of alternate-ECN semantics. -6. Who Wants to Use Alternate Semantics for the ECN Codepoint? - - There have been a number of proposals in the IETF and in the - research community for alternate semantics for the ECN codepoint - [ECN]. One such proposal, [BCF05], proposes an alternate-ECN - semantics for real-time inelastic traffic such as voice, video - conferencing, and multimedia streaming in DiffServ networks. In - this proposal, the alternate-ECN semantics would provide information - about two levels of congestion experienced along the path [BCF05]. - Some of the other proposals for alternate ECN semantics are listed - on the ECN Web Page [ECN]. - -7. Security Considerations +6. Security Considerations This document doesn't propose any new mechanisms for the Internet protocol, and therefore doesn't introduce any new security considerations. +7. Conclusions + + This document has discussed some of the issues to be considered in + the specification of alternate semantics for the ECN field in the IP + header. + 8. Acknowledgements This document is based in part on conversations with Jozef Babiarz, Kwok Ho Chan, and Victor Firoiu on their proposal for an alternate use of the ECN field in DiffServ environments. Many thanks to Francois Le Faucheur for feedback recommending that the document include a section at the beginning discussing the potential issues that need to be addressed. Thanks also to Mark Allman, Fred Baker, David Black, Gorry Fairhurst, and to members of the TSVWG working group for feedback on these issues. -9. Conclusions - - This document has discussed some of the issues to be considered in - the specification of alternate semantics for the ECN field in the IP - header. +9. Normative References -10. Normative References + [RFC3168] Ramakrishnan, K.K., Floyd, S., and Black, D., The Addition + of Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed + Standard, September 2001. -11. Informative References +10. Informative References [BCF05] J. Babiarz, K. Chan, and V. Firoiu, Congestion Notification - Process for Real-Time Traffic, internet-draft draft-babiarz-tsvwg- - rtecn-04, work in progress, July 2005. + Process for Real-Time Traffic, expired internet-draft draft-babiarz- + tsvwg-rtecn-04, work in progress, July 2005. - [BESFC05] B. Briscoe, P. Eardley, D. Songhurst, F. Le Faucheur, A. + [BESFC06] B. Briscoe, P. Eardley, D. Songhurst, F. Le Faucheur, A. Charny, J. Barbiaz, K. Chan, A Framework for Admission Control over DiffServ using Pre-Congestion Notification, internet-draft draft- - briscoe-tsvwg-cl-architecture-01.txt, work in progress, October - 2005. - - [DCCP] DCCP Web Page, URL "http://www.icir.org/kohler/dccp/". + briscoe-tsvwg-cl-architecture-03.txt, work in progress, June 2006. [ECN] ECN Web Page, URL "www.icir.org/floyd/ecn.html". - [QuickStart] Quick-Start Web Page, URL - "http://www.icir.org/floyd/quickstart.html". + [QuickStart] S. Floyd, M. Allman, A. Jain, and P. Sarolahti, Quick- + Start for TCP and IP, Internet-draft draft-ietf-tsvwg- + quickstart-05.txt, work in progress, July 2006. [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion Control, RFC 2581, Proposed Standard, April 1999. [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, Best Current Practice, September 2000. [RFC2960] R. Stewart et al, Stream Control Transmission Protocol, RFC 2960, October 2000. - [RFC3168] Ramakrishnan, K.K., Floyd, S., and Black, D., The Addition - of Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed - Standard, September 2001. + [RFC3448] Handley, M., Floyd, S., Pahdye, J., and Widmer, J. TCP + Friendly Rate Control (TFRC): Protocol Specification. RFC 3448, + Proposed Standard, January 2003. [RFC3540] N. Spring, D. Wetherall, and D. Ely, Robust Explicit Congestion Notification (ECN) Signaling with Nonces, RFC 3540, Experimental, June 2003. [RFC3714] S. Floyd and J. Kempf, Editors, IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet, RFC 3714, Informational, March 2004. + [RFC4340] E. Kohler, M. Handley, and S. Floyd, Datagram Congestion + Control Protocol (DCCP), RFC 4340, Proposed Standard, March 2006. + + [RFC4341] S. Floyd and E. Kohler, Profile for Datagram Congestion + Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion + Control, RFC 4341, Proposed Standard, March 2006. + + [RFC4342] S. Floyd, E. Kohler, and J. Padhye, Profile for Datagram + Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP- + Friendly Rate Control (TFRC), RFC 4342, Proposed Standard, March + 2006. + + [XSSK05] Y. Xia, L. Subramanian, I. Stoica, and S. Kalyanaraman, + One More Bit Is Enough, SIGCOMM 2005, September 2005. + IANA Considerations There are no IANA considerations in this document. AUTHORS' ADDRESSES Sally Floyd Phone: +1 (510) 666-2989 ICIR (ICSI Center for Internet Research) Email: floyd@icir.org