--- 1/draft-ietf-tsvwg-ecn-experimentation-07.txt 2017-11-13 20:13:14.087873601 -0800 +++ 2/draft-ietf-tsvwg-ecn-experimentation-08.txt 2017-11-13 20:13:14.135874750 -0800 @@ -1,21 +1,21 @@ Transport Area Working Group D. Black Internet-Draft Dell EMC -Updates: 3168, 4341, 4342, 5622, 6679 October 20, 2017 +Updates: 3168, 4341, 4342, 5622, 6679 November 13, 2017 (if approved) Intended status: Standards Track -Expires: April 23, 2018 +Expires: May 17, 2018 Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation - draft-ietf-tsvwg-ecn-experimentation-07 + draft-ietf-tsvwg-ecn-experimentation-08 Abstract This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as an alternative to packet drops for indicating network congestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC in the IETF document stream is required to take @@ -35,21 +35,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six 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." - This Internet-Draft will expire on April 23, 2018. + This Internet-Draft will expire on May 17, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -71,31 +71,31 @@ it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. ECN Terminology . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. ECN Experimentation: Overview . . . . . . . . . . . . . . . . 4 2.1. Effective Congestion Control is Required . . . . . . . . 5 - 2.2. Considerations for Other Protocols . . . . . . . . . . . 5 + 2.2. Network Considerations for ECN Experimentation . . . . . 5 2.3. Operational and Management Considerations . . . . . . . . 6 3. ECN Nonce and RFC 3540 . . . . . . . . . . . . . . . . . . . 7 4. Updates to RFC 3168 . . . . . . . . . . . . . . . . . . . . . 8 4.1. Congestion Response Differences . . . . . . . . . . . . . 8 4.2. Congestion Marking Differences . . . . . . . . . . . . . 9 4.3. TCP Control Packets and Retransmissions . . . . . . . . . 12 5. ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . . 13 - 6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 . . . . . . 14 + 6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction This memo updates RFC 3168 [RFC3168] which specifies Explicit Congestion Notification (ECN) as an alternative to packet drops for @@ -154,56 +154,55 @@ "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. ECN Experimentation: Overview Three areas of ECN experimentation are covered by this memo; the cited Internet-Drafts should be consulted for the detailed goals and rationale of each proposed experiment: Congestion Response Differences: An ECN congestion indication - communicates a higher likelihood that a shorter queue exists at - the network bottleneck node by comparison to a longer queue that - is more likely when a packet drop occurs that indicates congestion + communicates a higher likelihood than a dropped packet that a + short queue exists at the network bottleneck node [I-D.ietf-tcpm-alternativebackoff-ecn]. This difference suggests that for congestion indicated by ECN, a different sender congestion response (e.g., sender backs off by a smaller amount) may be appropriate by comparison to the sender response to congestion indicated by loss. Two examples of proposed sender congestion response changes are described in [I-D.ietf-tcpm-alternativebackoff-ecn] and [I-D.ietf-tsvwg-ecn-l4s-id] - the proposal in the latter draft couples the sender congestion response change to Congestion - Marking Differences changes (see next paragraph). This is at - variance with RFC 3168's requirement that a sender's congestion - control response to ECN congestion indications be the same as to - drops. IETF approval, e.g., via an Experimental RFC in the IETF - document stream, is required for any sender congestion response - used in this area of experimentation. See Section 4.1 for further - discussion. + Marking Differences functionality (see next paragraph). These + changes are at variance with RFC 3168's requirement that a + sender's congestion control response to ECN congestion indications + be the same as to drops. IETF approval, e.g., via an Experimental + RFC in the IETF document stream, is required for any sender + congestion response used in this area of experimentation. See + Section 4.1 for further discussion. Congestion Marking Differences: Congestion marking at network nodes can be configured to maintain very shallow queues in conjunction with a different sender response to congestion indications (CE marks), e.g., as proposed in [I-D.ietf-tsvwg-ecn-l4s-id]. The traffic involved needs to be identified by the senders to the network nodes in order to avoid damage to other network traffic whose senders do not expect the more frequent congestion marking used to maintain very shallow queues. Use of different ECN codepoints, specifically ECT(0) and ECT(1), is a promising means of traffic identification for this purpose, but that technique is at variance with RFC 3168's requirement that ECT(0)-marked traffic and ECT(1)-marked traffic not receive different treatment in the network. IETF approval, e.g., via an Experimental RFC in the IETF - document stream, is required for any sender congestion response - used in this area of experimentation. See Section 4.2 for further - discussion. + document stream, is required for any differences in congestion + marking or sender congestion response used in this area of + experimentation. See Section 4.2 for further discussion. TCP Control Packets and Retransmissions: RFC 3168 limits the use of ECN with TCP to data packets, excluding retransmissions. With the successful deployment of ECN in large portions of the Internet, there is interest in extending the benefits of ECN to TCP control packets (e.g., SYNs) and retransmitted packets, e.g., as proposed in [I-D.bagnulo-tcpm-generalized-ecn]. This is at variance with RFC 3168's prohibition of use of ECN for TCP control packets and retransmitted packets. See Section 4.3 for further discussion. @@ -220,86 +219,93 @@ 2.1. Effective Congestion Control is Required Congestion control remains an important aspect of the Internet architecture [RFC2914]. Any Experimental RFC in the IETF document stream that takes advantage of this memo's updates to any RFC is required to discuss the congestion control implications of the experiment(s) in order to provide assurance that deployment of the experiment(s) does not pose a congestion-based threat to the operation of the Internet. -2.2. Considerations for Other Protocols +2.2. Network Considerations for ECN Experimentation - ECN is widely deployed in the Internet and is being designed into - additional protocols such as TRILL [I-D.ietf-trill-ecn-support]. - While the responsibility for coexistence with other protocols and - transition from current ECN functionality falls primary upon the - designers of experimental changes to ECN, this subsection provides - some general guidelines for designers and users of other protocols - that minimize the likelihood of interaction with the areas of ECN - experimentation enabled by this memo. + ECN functionality [RFC3168] is becoming widely deployed in the + Internet and is being designed into additional protocols such as + TRILL [I-D.ietf-trill-ecn-support]. ECN experiments are expected to + coexist with deployed ECN functionality, with the responsibility for + that coexistence falling primarily upon designers of experimental + changes to ECN. In addition, protocol designers and implementers, as + well as network operators, may desire to anticipate and/or support + ECN experiments. The following guidelines will help avoid conflicts + with the areas of ECN experimentation enabled by this memo: 1. RFC 3168's forwarding behavior remains the preferred approach for routers that are not involved in ECN experiments, in particular continuing to treat the ECT(0) and ECT(1) codepoints as equivalent, as specified in Section 4.2 below. - 2. The ECN CE codepoint SHOULD NOT be assumed to indicate that the - packet would have been dropped if ECN were not in use, as that is - not the case for either Congestion Response Differences - experiments (see Section 4.1 below) or Congestion Marking - Differences experiments (see Section 4.2 below). This is already - the case when the ECN field is used for Pre-Congestion - Notification (PCN) [RFC6660]. + 2. Network nodes that forward packets SHOULD NOT assume that the ECN + CE codepoint indicates that the packet would have been dropped if + ECN were not in use. This is because Congestion Response + Differences experiments employ different congestion responses to + dropped packets by comparison to receipt of CE-marked packets + (see Section 4.1 below), so CE-marked packets SHOULD NOT be + arbitrarily dropped. A corresponding difference in congestion + responses already occurs when the ECN field is used for Pre- + Congestion Notification (PCN) [RFC6660]. - 3. Traffic marked with ECT(1) MUST NOT be originated, as specified - in Section 4.2 below. + 3. A network node MUST NOT originate traffic marked with ECT(1) + unless the network node is participating in a Congestion Marking + Differences experiment that uses ECT(1), as specified in + Section 4.2 below. - 4. ECN may now be used on packets where it has not been used - previously, specifically TCP control packets and retransmissions, - see Section 4.3 below, and in particular its new requirements for - middlebox behavior. In general, any system or protocol that - inspects or monitors network traffic SHOULD be prepared to - encounter ECN usage on packets and traffic that currently do not - use ECN. + Some ECN experiments use ECN with packets where it has not been used + previously, specifically TCP control packets and retransmissions, see + Section 4.3 below, and in particular its new requirements for + middlebox behavior. In general, any system or protocol that inspects + or monitors network traffic SHOULD be prepared to encounter ECN usage + on packets and traffic that currently do not use ECN. - 5. Requirements for handling of the ECN field by tunnel - encapsulation and decapsulation are specified in [RFC6040]. - Additional related guidance can be found in - [I-D.ietf-tsvwg-ecn-encap-guidelines] and - [I-D.ietf-tsvwg-rfc6040update-shim]. + ECN field handling requirements for tunnel encapsulation and + decapsulation are specified in [RFC6040] which is in the process of + being updated by [I-D.ietf-tsvwg-rfc6040update-shim]. Related + guidance for encapsulations whose outer headers are not IP headers + can be found in [I-D.ietf-tsvwg-ecn-encap-guidelines]. These + requirements and guidance apply to all traffic, including traffic + that is part of any ECN experiment. 2.3. Operational and Management Considerations Changes in network traffic behavior that result from ECN experimentation are likely to impact network operations and management. Designers of ECN experiments are expected to anticipate possible impacts and consider how they may be dealt with. Specific topics to consider include possible network management changes or extensions, monitoring of the experimental deployment, collection of data for evaluation of the experiment and possible interactions with other protocols, particularly protocols that encapsulate network traffic. - For further discussion, see [RFC5706]; the questions in Appendix A - provide a concise survey of some important aspects to consider. + For further discussion, see [RFC5706]; the questions in Appendix A of + RFC 5706 provide a concise survey of some important aspects to + consider. 3. ECN Nonce and RFC 3540 As specified in RFC 3168, ECN uses two ECN Capable Transport (ECT) codepoints to indicate that a packet supports ECN, ECT(0) and ECT(1). - The second codepoint, ECT(1), is used to support ECN nonce + RFC 3168 assigned the second codepoint, ECT(1), to support ECN nonce functionality that discourages receivers from exploiting ECN to - improve their throughput at the expense of other network users, as - specified in Experimental RFC 3540 [RFC3540]. This section explains - why RFC 3540 is being reclassified as Historic and makes associated - updates to RFC 3168. + improve their throughput at the expense of other network users. That + ECN nonce functionality is fully specified in Experimental RFC 3540 + [RFC3540]. This section explains why RFC 3540 is being reclassified + as Historic and makes associated updates to RFC 3168. While the ECN nonce works as specified, and has been deployed in limited environments, widespread usage in the Internet has not materialized. A study of the ECN behaviour of the top one million web servers using 2014 data [Trammell15] found that after ECN was negotiated, none of the 581,711 IPv4 servers tested were using both ECT codepoints, which would have been a possible sign of ECN nonce usage. Of the 17,028 IPv6 servers tested, 4 set both ECT(0) and ECT(1) on data packets. This might have been evidence of use of the ECN nonce by these 4 servers, but might equally have been due to @@ -327,21 +333,21 @@ motivation for two ECT codepoints. 2. Remove Section 11.2 "A Discussion of the ECN nonce." in its entirety. 3. Remove the last paragraph of Section 12, which states that ECT(1) may be used as part of the implementation of the ECN nonce. 4. Remove the first two paragraphs of Section 20.2, which discuss the ECN nonce and alternatives. No changes are made to the rest - of Section 20.2, which discusses alternate uses for the fourth + of Section 20.2, which discusses alternative uses for the fourth ECN codepoint. In addition, other less substantive RFC 3168 changes are required to remove all other mentions of the ECN nonce and to remove implications that ECT(1) is intended for use by the ECN nonce; these specific text updates are omitted for brevity. 4. Updates to RFC 3168 The following subsections specify updates to RFC 3168 to enable the @@ -353,27 +359,27 @@ and ECN congestion indications. ECN congestion indications are predominately originated by Active Queue Management (AQM) mechanisms in intermediate buffers. AQM mechanisms are usually configured to maintain shorter queue lengths than non-AQM based mechanisms, particularly non-AQM drop-based mechanisms such as tail-drop, as AQM mechanisms indicate congestion before the queue overflows. While the occurrence of loss does not easily enable the receiver to determine if AQM is used, the receipt of an ECN Congestion Experienced (CE) mark conveys a strong likelihood that AQM was used to manage the bottleneck queue. Hence an ECN congestion indication communicates a - higher likelihood that a shorter queue exists at the network - bottleneck node by comparison to a packet drop that indicates - congestion [I-D.ietf-tcpm-alternativebackoff-ecn]. This difference - suggests that for congestion indicated by ECN, a different sender - congestion response (e.g., sender backs off by a smaller amount) may - be appropriate by comparison to the sender response to congestion - indicated by loss. However, section 5 of RFC 3168 specifies that: + higher likelihood than a dropped packet that a short queue exists at + the network bottleneck node [I-D.ietf-tcpm-alternativebackoff-ecn]. + This difference suggests that for congestion indicated by ECN, a + different sender congestion response (e.g., sender backs off by a + smaller amount) may be appropriate by comparison to the sender + response to congestion indicated by loss. However, section 5 of RFC + 3168 specifies 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. This memo updates this RFC 3168 text to allow the congestion control response (including the TCP Sender's congestion control response) to a CE-marked packet to differ from the response to a dropped packet, provided that the changes from RFC 3168 are documented in an @@ -415,23 +421,24 @@ are needed to make effective use of such very shallow queues; Datacenter TCP (DCTCP) [I-D.ietf-tcpm-dctcp] provides an example. In this case, separate network node treatments are essential, both to prevent the aggressive low latency traffic from starving conventional traffic (if present) and to prevent any conventional traffic disruption to any lower latency service that uses the very shallow queues. Use of different ECN codepoints is a promising means of identifying these two classes of traffic to network nodes, and hence this area of experimentation is based on the use of the ECT(1) codepoint to request ECN congestion marking behavior in the network - that differs from ECT(0) counterbalanced by use of a different IETF- - approved congestion response to CE marks at the sender, e.g., as - proposed in [I-D.ietf-tsvwg-ecn-l4s-id]. + that differs from ECT(0). It is essential that any such change in + ECN congestion marking behavior be counterbalanced by use of a + different IETF-approved congestion response to CE marks at the + sender, e.g., as proposed in [I-D.ietf-tsvwg-ecn-l4s-id]. Section 5 of RFC 3168 specifies that: Routers treat the ECT(0) and ECT(1) codepoints as equivalent. This memo updates RFC 3168 to allow routers to treat the ECT(0) and ECT(1) codepoints differently, provided that the changes from RFC 3168 are documented in an Experimental RFC in the IETF document stream. The specific change to RFC 3168 is to insert the words "unless otherwise specified by an Experimental RFC in the IETF @@ -692,21 +699,21 @@ experiments have motivated the production of this memo - their interest in innovation is welcome and heartily acknowledged. Colin Perkins suggested updating RFC 6679 on RTP and provided guidance on where to make the updates. The draft has been improved as a result of comments from a number of reviewers, including Ben Campbell, Brian Carpenter, Benoit Claise, Spencer Dawkins, Gorry Fairhurst, Sue Hares, Ingemar Johansson, Naeem Khademi, Mirja Kuehlewind, Karen Nielsen, Hilarie Orman, Eric Rescorla, Adam Roach and Michael Welzl. Bob Briscoe's thorough - review of an early version of this memo resulted in numerous + reviews of multiple versions of this memo resulted in numerous improvements including addition of the updates to the DCCP RFCs. 8. IANA Considerations To reflect the reclassification of RFC 3540 as Historic, IANA is requested to update the Transmission Control Protocol (TCP) Header Flags registry (https://www.iana.org/assignments/tcp-header-flags/ tcp-header-flags.xhtml#tcp-header-flags-1) to remove the registration of bit 7 as the NS (Nonce Sum) bit and add an annotation to the registry to state that bit 7 was used by Historic RFC 3540 as the NS @@ -783,21 +790,22 @@ [I-D.bagnulo-tcpm-generalized-ecn] Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets", draft-bagnulo-tcpm-generalized-ecn-04 (work in progress), May 2017. [I-D.ietf-tcpm-alternativebackoff-ecn] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, "TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm- - alternativebackoff-ecn-01 (work in progress), May 2017. + alternativebackoff-ecn-03 (work in progress), October + 2017. [I-D.ietf-tcpm-dctcp] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters", draft-ietf-tcpm-dctcp-10 (work in progress), August 2017. [I-D.ietf-trill-ecn-support] Eastlake, D. and B. Briscoe, "TRILL: ECN (Explicit Congestion Notification) Support", draft-ietf-trill-ecn- @@ -805,27 +813,28 @@ [I-D.ietf-tsvwg-ecn-encap-guidelines] Briscoe, B., Kaippallimalil, J., and P. Thaler, "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- encap-guidelines-09 (work in progress), July 2017. [I-D.ietf-tsvwg-ecn-l4s-id] Schepper, K. and B. Briscoe, "Identifying Modified Explicit Congestion Notification (ECN) Semantics for - Ultra-Low Queuing Delay", draft-ietf-tsvwg-ecn-l4s-id-00 - (work in progress), May 2017. + Ultra-Low Queuing Delay", draft-ietf-tsvwg-ecn-l4s-id-01 + (work in progress), October 2017. [I-D.ietf-tsvwg-rfc6040update-shim] Briscoe, B., "Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim", draft-ietf- - tsvwg-rfc6040update-shim-04 (work in progress), July 2017. + tsvwg-rfc6040update-shim-05 (work in progress), November + 2017. [I-D.khademi-tsvwg-ecn-response] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, "Updating the Explicit Congestion Notification (ECN) Specification to Allow IETF Experimentation", draft- khademi-tsvwg-ecn-response-01 (work in progress), July 2016. [RFC4774] Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, @@ -945,19 +954,25 @@ o Improve explanation of attack response exception to not dropping packets "solely because the ECN field in the IP header does not contain Not-ECT" in Section 4.3 o Fix L4S draft reference for discussion of ECN Nonce alternatives - it's Appendix C.1, not B.1. o Numerous additional editorial changes from IESG Evaluation + Changes from draft-ietf-tsvwg-ecn-experimentation-07 to -08: + + o Edits from another careful review by Bob Briscoe. The primary + change is an editorial rewrite of Section 2.2 including changing + its name to better reflect its content. + Author's Address David Black Dell EMC 176 South Street Hopkinton, MA 01748 USA Email: david.black@dell.com