idnits 2.17.1 draft-black-tsvwg-ecn-experimentation-00.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 (September 30, 2016) is 2765 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) September 30, 2016 5 Updates: 3168, 6679 (if approved) 6 Intended status: Standards Track 7 Expires: April 3, 2017 9 Explicit Congestion Notification (ECN) Experimentation 10 draft-black-tsvwg-ecn-experimentation-00 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. This memo also makes related updates to the ECN 21 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 3, 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 . . . . . . . . . . . . . . . . . . . . . . . . 9 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", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 2. Scope of ECN Experiments 107 Three areas of ECN experimentation are covered by this memo; in each 108 case, the cited Internet-Draft should be consulted for the goals and 109 rationale of the proposed experiment: 111 Alternative Backoff: For congestion indicated by ECN, use a 112 different TCP sender response (e.g., backoff by a smaller amount) 113 by comparison to congestion indicated by loss, e.g., as specified 114 in [I-D.khademi-tcpm-alternativebackoff-ecn]. This is at variance 115 with RFC 3168's requirement that a TCP sender's congestion control 116 response to ECN congestion indications be the same as to drops. 118 ECT Differences: Use ECT(1) to request ECN congestion marking 119 behavior in the network that differs from ECT(0), e.g., as 120 specified in [I-D.briscoe-tsvwg-ecn-l4s-id]. This is at variance 121 with RFC 3168's requirement that ECT(0)-marked traffic and ECT(1)- 122 marked traffic not receive different treatment in the network. 124 Generalized ECN: Use ECN for TCP control packets (i.e., send control 125 packets such as SYN with ECT marking) and for retransmitted 126 packets, e.g., as specified in 127 [I-D.bagnulo-tsvwg-generalized-ecn]. This is at variance with RFC 128 3168's prohibition of use of ECN for TCP control packets and 129 retransmitted packets 131 The scope of this memo is limited to these three areas of 132 experimentation. 134 3. ECN Nonce and RFC 3540 136 As specified in RFC 3168, ECN uses two ECN Capable Transport (ECT) 137 codepoints to indicate that a packet supports ECN, ECT(0) and ECT(1), 138 with the second codepoint used to support ECN nonce functionality to 139 discourage receivers from exploiting ECN to improve their throughput 140 at the expense of other network users, as specified in experimental 141 RFC 3540 [RFC3540]. 143 While the ECN Nonce works as specified, and has been deployed in 144 limited environments, widespread usage in the Internet has not 145 materialized, as the potential for this sort of receiver ECN 146 exploitation has not turned out to be a significant concern in 147 practice. With the emergence of new experimental functionality that 148 depends on use of the ECT(1) codepoint for other purposes, continuing 149 to reserve that codepoint for the ECN Nonce is 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. The specific change to RFC 3168 215 is to insert the words "Unless otherwise specified by an Experimental 216 RFC" and combine the two sentences into a single sentence with this 217 result: 219 "Unless otherwise specified by an Experimental RFC, routers treat 220 the ECT(0) and ECT(1) codepoints as equivalent, and senders are 221 free to use either the ECT(0) or the ECT(1) codepoint to indicate 222 ECT, on a packet-by-packet basis." 224 As ECT(0) was the original codepoint used to signal ECN capability, 225 it is preferable for ECT Differences experiments to modify the 226 behavior of ECT(1) rather than ECT(0) if behavior of 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 ECT(1) and random ECT values is discouraged, as that may 289 expose RTP to differences in network treatment of ECT(1) and 290 ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. 292 Section 7.3.3 of RFC 6679 specifies RTP's response to receipt of CE 293 marked packets as being identical to the response to dropped packets: 295 The reception of RTP packets with ECN-CE marks in the IP header is 296 a notification that congestion is being experienced. The default 297 reaction on the reception of these ECN-CE-marked packets MUST be 298 to provide the congestion control algorithm with a congestion 299 notification that triggers the algorithm to react as if packet 300 loss had occurred. There should be no difference in congestion 301 response if ECN-CE marks or packet drops are detected. 303 In support of Alternative Backoff experimentation, this memo updates 304 this text in a fashion similar to RFC 3168 to allow the RTP 305 congestion control response to a CE-marked packet to differ from the 306 response to a dropped packet, provided that the changes from RFC 6679 307 are documented in an Experimental RFC. The specific change to RFC 308 3168 is to insert the words "Unless otherwise specified by an 309 Experimental RFC" and reformat the last two sentences to be subject 310 to that condition, i.e.: 312 The reception of RTP packets with ECN-CE marks in the IP header is 313 a notification that congestion is being experienced. Unless 314 otherwise specified by an Experimental RFC: 316 * The default reaction on the reception of these ECN-CE-marked 317 packets MUST be to provide the congestion control algorithm 318 with a congestion notification that triggers the algorithm to 319 react as if packet loss had occurred. 321 * There should be no difference in congestion response if ECN-CE 322 marks or packet drops are detected. 324 The second sentence of the immediately following paragraph in RFC 325 6679 requires a related update: 327 Other reactions to ECN-CE may be specified in the future, 328 following IETF Review. Detailed designs of such alternative 329 reactions MUST be specified in a Standards Track RFC and be 330 reviewed to ensure they are safe for deployment under any 331 restrictions specified. 333 The update is to change "Standards Track RFC" to "Standards Track RFC 334 or Experimental RFC" for consistency with the first update. 336 6. Acknowledgements 338 The content of this draft, including the specific portions of RFC 339 3168 that are updated draws heavily from 340 [I-D.khademi-tsvwg-ecn-response], whose authors are gratefully 341 acknowledged. The authors of the Internet Drafts describing the 342 experiments have motivated the production of this memo - their 343 interest in innovation is welcome and heartily acknowledged. Colin 344 Perkins suggested updating RFC 6679 and provided guidance on where to 345 make the updates. 347 7. IANA Considerations 349 This memo includes no request to IANA. 351 8. Security Considerations 353 As a process memo that makes no changes to existing protocols, there 354 are no protocol security considerations. 356 However, effective congestion control is crucial to the continued 357 operation of the Internet, and hence this memo places the 358 responsibility for not breaking Internet congestion control on the 359 experiments and the experimenters who propose them, as specified in 360 Section 4.4. 362 9. References 364 9.1. Normative References 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, 368 DOI 10.17487/RFC2119, March 1997, 369 . 371 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 372 RFC 2914, DOI 10.17487/RFC2914, September 2000, 373 . 375 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 376 of Explicit Congestion Notification (ECN) to IP", 377 RFC 3168, DOI 10.17487/RFC3168, September 2001, 378 . 380 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 381 Congestion Notification (ECN) Signaling with Nonces", 382 RFC 3540, DOI 10.17487/RFC3540, June 2003, 383 . 385 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 386 and K. Carlberg, "Explicit Congestion Notification (ECN) 387 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 388 2012, . 390 9.2. Informative References 392 [I-D.bagnulo-tsvwg-generalized-ecn] 393 Bagnulo, M. and B. Briscoe, "Adding Explicit Congestion 394 Notification (ECN) to TCP control packets", draft-bagnulo- 395 tsvwg-generalized-ecn-01 (work in progress), July 2016. 397 [I-D.briscoe-tsvwg-ecn-l4s-id] 398 Schepper, K., Briscoe, B., and I. Tsang, "Identifying 399 Modified Explicit Congestion Notification (ECN) Semantics 400 for Ultra-Low Queuing Delay", draft-briscoe-tsvwg-ecn-l4s- 401 id-01 (work in progress), March 2016. 403 [I-D.khademi-tcpm-alternativebackoff-ecn] 404 Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 405 "TCP Alternative Backoff with ECN (ABE)", draft-khademi- 406 tcpm-alternativebackoff-ecn-00 (work in progress), May 407 2016. 409 [I-D.khademi-tsvwg-ecn-response] 410 Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 411 "Updating the Explicit Congestion Notification (ECN) 412 Specification to Allow IETF Experimentation", draft- 413 khademi-tsvwg-ecn-response-01 (work in progress), July 414 2016. 416 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 417 Explicit Congestion Notification (ECN) Field", BCP 124, 418 RFC 4774, DOI 10.17487/RFC4774, November 2006, 419 . 421 Author's Address 422 David Black 423 Dell EMC 424 176 South Street 425 Hopkinton, MA 01748 426 USA 428 Email: david.black@dell.com