idnits 2.17.1 draft-black-tsvwg-ecn-experimentation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6679, but the abstract doesn't seem to directly say this. It does mention RFC6679 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3168, updated by this document, for RFC5378 checks: 2000-11-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 25, 2016) is 2740 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Historic RFC: RFC 3540 == Outdated reference: A later version (-02) exists of draft-briscoe-tsvwg-ecn-l4s-id-01 == Outdated reference: A later version (-01) exists of draft-khademi-tcpm-alternativebackoff-ecn-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group D. Black 3 Internet-Draft Dell EMC 4 Obsoletes: 3540 (if approved) October 25, 2016 5 Updates: 3168, 6679 (if approved) 6 Intended status: Standards Track 7 Expires: April 28, 2017 9 Explicit Congestion Notification (ECN) Experimentation 10 draft-black-tsvwg-ecn-experimentation-01 12 Abstract 14 Multiple protocol experiments have been proposed that involve changes 15 to Explicit Congestion Notification (ECN) as specified in RFC 3168. 16 This memo summarizes the proposed areas of experimentation to provide 17 an overview to the Internet community and updates RFC 3168, a 18 Proposed Standard RFC, to allow the experiments to proceed without 19 requiring a standards process exception for each Experimental RFC to 20 update RFC 3168. In addition, this memo makes related updates to the 21 ECN specification for RTP in RFC 6679 for the same reason. Each 22 experiment is still required to be documented in an Experimental RFC. 23 This memo also records the conclusion of the ECN Nonce experiment in 24 RFC 3540, obsoletes RFC 3540 and reclassifies it as Historic. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 28, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. Scope of ECN Experiments . . . . . . . . . . . . . . . . . . 3 63 3. ECN Nonce and RFC 3540 . . . . . . . . . . . . . . . . . . . 3 64 4. Updates to RFC 3168 . . . . . . . . . . . . . . . . . . . . . 4 65 4.1. Alternative Backoff . . . . . . . . . . . . . . . . . . . 4 66 4.2. ECT Differences . . . . . . . . . . . . . . . . . . . . . 5 67 4.3. Generalized ECN . . . . . . . . . . . . . . . . . . . . . 5 68 4.4. Effective Congestion Control is Required . . . . . . . . 6 69 5. ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . . 6 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 75 9.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 Multiple protocol experiments have been proposed that involve changes 81 to Explicit Congestion Notification (ECN) as specified in RFC 3168 82 [RFC3168]. This memo summarizes the proposed areas of 83 experimentation to provide an overview to the Internet community and 84 updates RFC 3168 to allow the experiments to proceed without 85 requiring a standards process exception for each Experimental RFC to 86 update RFC 3168, a Proposed Standard RFC. This memo also makes 87 related updates to the ECN specification for RTP in RFC 6679 88 [RFC6679] for the same reason. Each experiment is still required to 89 be documented in one or more separate RFCs, but use of Experimental 90 RFCs for this purpose does not require a process exception to modify 91 RFC 3168 or RFC 6679 when the modification falls within the bounds 92 established by this memo. 94 One of these areas of experimentation involves use of the ECT(1) 95 codepoint that was dedicated to the ECN Nonce experiment as described 96 in RFC 3540 [RFC3540]. This memo records the conclusion of the ECN 97 Nonce experiment, obsoletes RFC 3540 and reclassifies it as Historic. 99 1.1. Requirements Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in RFC 104 2119 [RFC2119]. 106 2. Scope of ECN Experiments 108 Three areas of ECN experimentation are covered by this memo; in each 109 case, the cited Internet-Draft should be consulted for the goals and 110 rationale of the proposed experiment: 112 Alternative Backoff: For congestion indicated by ECN, use a 113 different IETF-approved TCP sender response (e.g., reduce the 114 response so that the sender backs off by a smaller amount) by 115 comparison to congestion indicated by loss, e.g., as proposed in 116 [I-D.khademi-tcpm-alternativebackoff-ecn]. This is at variance 117 with RFC 3168's requirement that a TCP sender's congestion control 118 response to ECN congestion indications be the same as to drops. 120 ECT Differences: Use ECT(1) to request ECN congestion marking 121 behavior in the network that differs from ECT(0), e.g., as 122 proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. This is at variance 123 with RFC 3168's requirement that ECT(0)-marked traffic and ECT(1)- 124 marked traffic not receive different treatment in the network. 126 Generalized ECN: Use ECN for TCP control packets (i.e., send control 127 packets such as SYN with ECT marking) and for retransmitted 128 packets, e.g., as proposed in [I-D.bagnulo-tsvwg-generalized-ecn]. 129 This is at variance with RFC 3168's prohibition of use of ECN for 130 TCP control packets and retransmitted packets 132 The scope of this memo is limited to these three areas of 133 experimentation. 135 3. ECN Nonce and RFC 3540 137 As specified in RFC 3168, ECN uses two ECN Capable Transport (ECT) 138 codepoints to indicate that a packet supports ECN, ECT(0) and ECT(1), 139 with the second codepoint used to support ECN nonce functionality to 140 discourage receivers from exploiting ECN to improve their throughput 141 at the expense of other network users, as specified in experimental 142 RFC 3540 [RFC3540]. 144 While the ECN Nonce works as specified, and has been deployed in 145 limited environments, widespread usage in the Internet has not 146 materialized. With the emergence of new experimental functionality 147 that depends on use of the ECT(1) codepoint for other purposes, 148 continuing to reserve that codepoint for the ECN Nonce experiment is 149 no longer justified. 151 Therefore, in support of ECN experimentation with the ECT(1) 152 codepoint, this memo: 154 o Declares that the ECN Nonce experiment [RFC3540] has concluded, 155 and notes the absence of widespread deployment. 157 o Obsoletes RFC 3540 in order to facilitate experimental use of the 158 ECT(1) codepoint. 160 o Reclassifies RFC 3540 as Historic to document the ECN Nonce 161 experiment and discourage further implementation of the ECN Nonce. 163 o Updates RFC 3168 [RFC3168] to remove discussion of the ECN Nonce 164 and use of ECT(1) for that Nonce. The specific text updates are 165 omitted for brevity. 167 The following guidance on ECT codepoint usage in Section 5 of RFC 168 3168 is relevant when the ECN Nonce is not implemented: 170 Protocols and senders that only require a single ECT codepoint 171 SHOULD use ECT(0). 173 4. Updates to RFC 3168 175 In support of these areas of experimentation, this memo updates RFC 176 3168 [RFC3168] to allow changes in the following areas, provided that 177 the changes are documented by an Experimental RFC. It is also 178 possible to change RFC 3168 via a standards track RFC. 180 4.1. Alternative Backoff 182 Section 5 of RFC 3168 specifies that: 184 "Upon the receipt by an ECN-Capable transport of a single CE 185 packet, the congestion control algorithms followed at the end- 186 systems MUST be essentially the same as the congestion control 187 response to a *single* dropped packet." 189 In support of Alternative Backoff experimentation, this memo updates 190 RFC 3168 to allow the congestion control response (including the TCP 191 Sender's congestion control response) to a CE-marked packet to differ 192 from the response to a dropped packet, provided that the changes from 193 RFC 3168 are documented in an Experimental RFC. The specific change 194 to RFC 3168 is to insert the words "unless otherwise specified by an 195 Experimental RFC" at the end of the sentence quoted above. 197 RFC 4774 [RFC4774] quotes the above text from RFC 3168 as background, 198 but does not impose requirements based on that text. Therefore no 199 update to RFC 4774 is required to enable this area of 200 experimentation. 202 4.2. ECT Differences 204 Section 5 of RFC 3168 specifies that: 206 "Routers treat the ECT(0) and ECT(1) codepoints as equivalent. 207 Senders are free to use either the ECT(0) or the ECT(1) codepoint 208 to indicate ECT, on a packet-by-packet basis." 210 In support of ECT Differences experimentation, this memo updates RFC 211 3168 to allow routers to treat the ECT(0) and ECT(1) codepoints 212 differently, and allow requirements to be imposed on sender usage of 213 ECT(0) and ECT(1), provided that the changes from RFC 3168 are 214 documented in an Experimental RFC. That change makes the second 215 sentence quoted above misleading, so RFC 3168 is also updated to 216 remove that sentence. The specific change to RFC 3168 is to insert 217 the words "unless otherwise specified by an Experimental RFC" at the 218 end of the first sentence, and remove the second sentence with this 219 result: 221 "Routers treat the ECT(0) and ECT(1) codepoints as equivalent 222 unless otherwise specified by an Experimental RFC." 224 As ECT(0) was the original codepoint used to signal ECN capability, 225 ECT Differences experiments SHOULD modify the network behavior for 226 ECT(1) rather than ECT(0) if network behavior for only one ECT 227 codepoint is modified. 229 In support of ECT Differences experimentation, this memo also updates 230 RFC 3168 to remove discussion of the ECN Nonce, as noted in Section 3 231 above. 233 4.3. Generalized ECN 235 RFC 3168 prohibits use of ECN for TCP control packets and 236 retransmitted packets in a number of places: 238 o "To ensure the reliable delivery of the congestion indication of 239 the CE codepoint, an ECT codepoint MUST NOT be set in a packet 240 unless the loss of that packet in the network would be detected by 241 the end nodes and interpreted as an indication of congestion." 242 (Section 5.2) 244 o "A host MUST NOT set ECT on SYN or SYN-ACK packets." 245 (Section 6.1.1) 247 o "pure acknowledgement packets (e.g., packets that do not contain 248 any accompanying data) MUST be sent with the not-ECT codepoint." 249 (Section 6.1.4) 251 o "This document specifies ECN-capable TCP implementations MUST NOT 252 set either ECT codepoint (ECT(0) or ECT(1)) in the IP header for 253 retransmitted data packets, and that the TCP data receiver SHOULD 254 ignore the ECN field on arriving data packets that are outside of 255 the receiver's current window." (Section 6.1.5) 257 In support of Generalized ECN experimentation, this memo updates RFC 258 3168 to allow the use of ECT codepoints on SYN and SYN-ACK packets, 259 pure acknowledgement packets, and retransmissions of packets that 260 were originally sent with an ECT codepoint, provided that the changes 261 from RFC 3168 are documented in an Experimental RFC. The specific 262 change to RFC 3168 is to insert the words "unless otherwise specified 263 by an Experimental RFC" at the end of each sentence quoted above. 265 4.4. Effective Congestion Control is Required 267 Congestion control remains an important aspect of the Internet 268 architecture [RFC2914]. Any Experimental RFC that takes advantage of 269 this memo's updates to RFC 3168 or RFC 6679 is required to discuss 270 the congestion control implications of the experiment(s) in order to 271 provide assurance that deployment of the experiment(s) does not pose 272 a congestion-based threat to the operation of the Internet. 274 5. ECN for RTP Updates to RFC 6679 276 RFC 6679 [RFC6679] specifies use of ECN for RTP traffic; it allows 277 use of both the ECT(0) and ECT(1) codepoints, and provides the 278 following guidance on use of these codepoints in section 7.3.1 : 280 The sender SHOULD mark packets as ECT(0) unless the receiver 281 expresses a preference for ECT(1) or for a random ECT value using 282 the "ect" parameter in the "a=ecn-capable-rtp:" attribute. 284 The ECT Differences area of experimentation increases the potential 285 consequences of using ECT(1) instead of ECT(0), and hence the above 286 guidance is updated by adding the following sentence: 288 Use of random ECT values is NOT RECOMMENDED, as that may expose 289 RTP to differences in network treatment of traffic marked with 290 ECT(1) and ECT(0) and differences in associated endpoint 291 congestion responses, e.g., as proposed in 292 [I-D.briscoe-tsvwg-ecn-l4s-id]. 294 Section 7.3.3 of RFC 6679 specifies RTP's response to receipt of CE 295 marked packets as being identical to the response to dropped packets: 297 The reception of RTP packets with ECN-CE marks in the IP header is 298 a notification that congestion is being experienced. The default 299 reaction on the reception of these ECN-CE-marked packets MUST be 300 to provide the congestion control algorithm with a congestion 301 notification that triggers the algorithm to react as if packet 302 loss had occurred. There should be no difference in congestion 303 response if ECN-CE marks or packet drops are detected. 305 In support of Alternative Backoff experimentation, this memo updates 306 this text in a fashion similar to RFC 3168 to allow the RTP 307 congestion control response to a CE-marked packet to differ from the 308 response to a dropped packet, provided that the changes from RFC 6679 309 are documented in an Experimental RFC. The specific change to RFC 310 3168 is to insert the words "Unless otherwise specified by an 311 Experimental RFC" and reformat the last two sentences to be subject 312 to that condition, i.e.: 314 The reception of RTP packets with ECN-CE marks in the IP header is 315 a notification that congestion is being experienced. Unless 316 otherwise specified by an Experimental RFC: 318 * The default reaction on the reception of these ECN-CE-marked 319 packets MUST be to provide the congestion control algorithm 320 with a congestion notification that triggers the algorithm to 321 react as if packet loss had occurred. 323 * There should be no difference in congestion response if ECN-CE 324 marks or packet drops are detected. 326 The second sentence of the immediately following paragraph in RFC 327 6679 requires a related update: 329 Other reactions to ECN-CE may be specified in the future, 330 following IETF Review. Detailed designs of such alternative 331 reactions MUST be specified in a Standards Track RFC and be 332 reviewed to ensure they are safe for deployment under any 333 restrictions specified. 335 The update is to change "Standards Track RFC" to "Standards Track RFC 336 or Experimental RFC" for consistency with the first update. 338 6. Acknowledgements 340 The content of this draft, including the specific portions of RFC 341 3168 that are updated draws heavily from 342 [I-D.khademi-tsvwg-ecn-response], whose authors are gratefully 343 acknowledged. The authors of the Internet Drafts describing the 344 experiments have motivated the production of this memo - their 345 interest in innovation is welcome and heartily acknowledged. Colin 346 Perkins suggested updating RFC 6679 and provided guidance on where to 347 make the updates. 349 The draft has been improved as a result of comments from a number of 350 reviewers, including Spencer Dawkins, Gorry Fairhurst, Ingemar 351 Johansson, Naeem Khademi, Mirja Kuehlewind and Michael Welzl. 353 7. IANA Considerations 355 This memo includes no request to IANA. 357 8. Security Considerations 359 As a process memo that makes no changes to existing protocols, there 360 are no protocol security considerations. 362 However, effective congestion control is crucial to the continued 363 operation of the Internet, and hence this memo places the 364 responsibility for not breaking Internet congestion control on the 365 experiments and the experimenters who propose them, as specified in 366 Section 4.4. 368 9. References 370 9.1. Normative References 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, 374 DOI 10.17487/RFC2119, March 1997, 375 . 377 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 378 RFC 2914, DOI 10.17487/RFC2914, September 2000, 379 . 381 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 382 of Explicit Congestion Notification (ECN) to IP", 383 RFC 3168, DOI 10.17487/RFC3168, September 2001, 384 . 386 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 387 Congestion Notification (ECN) Signaling with Nonces", 388 RFC 3540, DOI 10.17487/RFC3540, June 2003, 389 . 391 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 392 and K. Carlberg, "Explicit Congestion Notification (ECN) 393 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 394 2012, . 396 9.2. Informative References 398 [I-D.bagnulo-tsvwg-generalized-ecn] 399 Bagnulo, M. and B. Briscoe, "Adding Explicit Congestion 400 Notification (ECN) to TCP control packets", draft-bagnulo- 401 tsvwg-generalized-ecn-01 (work in progress), July 2016. 403 [I-D.briscoe-tsvwg-ecn-l4s-id] 404 Schepper, K., Briscoe, B., and I. Tsang, "Identifying 405 Modified Explicit Congestion Notification (ECN) Semantics 406 for Ultra-Low Queuing Delay", draft-briscoe-tsvwg-ecn-l4s- 407 id-01 (work in progress), March 2016. 409 [I-D.khademi-tcpm-alternativebackoff-ecn] 410 Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 411 "TCP Alternative Backoff with ECN (ABE)", draft-khademi- 412 tcpm-alternativebackoff-ecn-00 (work in progress), May 413 2016. 415 [I-D.khademi-tsvwg-ecn-response] 416 Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 417 "Updating the Explicit Congestion Notification (ECN) 418 Specification to Allow IETF Experimentation", draft- 419 khademi-tsvwg-ecn-response-01 (work in progress), July 420 2016. 422 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 423 Explicit Congestion Notification (ECN) Field", BCP 124, 424 RFC 4774, DOI 10.17487/RFC4774, November 2006, 425 . 427 Appendix A. Change History 429 [To be removed before RFC publication.] 431 Changes from draft-black-tsvwg-ecn-experimentation-00 to -01 433 o Section 4.2 - also update RFC 3168 to remove sentence indicating 434 that senders are free to use both ECT codepoints. Add a SHOULD 435 for ECT Differences experiments to use ECT(1). 437 o Section 5 - only discourage use of random ECT values, but use NOT 438 RECOMMENDED to do so. Consistent use of ECT(1) without using 439 ECT(0) is ok. Mention possible changes in endpoint response. 441 o Add more Acknowledgements and Change History 443 o Additional editorial changes. 445 Author's Address 447 David Black 448 Dell EMC 449 176 South Street 450 Hopkinton, MA 01748 451 USA 453 Email: david.black@dell.com