idnits 2.17.00 (12 Aug 2021) /tmp/idnits35328/draft-ietf-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 RFC4341, but the abstract doesn't seem to directly say this. It does mention RFC4341 though, so this could be OK. -- The draft header indicates that this document updates RFC4342, but the abstract doesn't seem to directly say this. It does mention RFC4342 though, so this could be OK. -- The draft header indicates that this document updates RFC5622, but the abstract doesn't seem to directly say this. It does mention RFC5622 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 15, 2016) is 1982 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 ** Downref: Normative reference to an Experimental RFC: RFC 5622 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 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) December 15, 2016 5 Updates: 3168, 4341, 4342, 5622, 6679 6 (if approved) 7 Intended status: Standards Track 8 Expires: June 18, 2017 10 Explicit Congestion Notification (ECN) Experimentation 11 draft-ietf-tsvwg-ecn-experimentation-00 13 Abstract 15 Multiple protocol experiments have been proposed that involve changes 16 to Explicit Congestion Notification (ECN) as specified in RFC 3168. 17 This memo summarizes the proposed areas of experimentation to provide 18 an overview to the Internet community and updates RFC 3168, a 19 Proposed Standard RFC, to allow the experiments to proceed without 20 requiring a standards process exception for each Experimental RFC to 21 update RFC 3168. Each experiment is still required to be documented 22 in an Experimental RFC. In addition, this memo makes related updates 23 to the ECN specifications for RTP in RFC 6679 and to the ECN 24 specifications for DCCP in RFC 4341, RFC 4342 and RFC 5622. This 25 memo also records the conclusion of the ECN Nonce experiment in RFC 26 3540, obsoletes RFC 3540 and reclassifies it as Historic to enable 27 new experimental use of the ECT(1) codepoint. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on June 18, 2017. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 77 2. Scope of ECN Experiments . . . . . . . . . . . . . . . . . . 3 78 3. ECN Nonce and RFC 3540 . . . . . . . . . . . . . . . . . . . 4 79 4. Updates to RFC 3168 . . . . . . . . . . . . . . . . . . . . . 5 80 4.1. Congestion Response Differences . . . . . . . . . . . . . 5 81 4.2. ECT Differences . . . . . . . . . . . . . . . . . . . . . 6 82 4.3. Generalized ECN . . . . . . . . . . . . . . . . . . . . . 7 83 4.4. Effective Congestion Control is Required . . . . . . . . 8 84 5. ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . . 9 85 6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 . . . . . . 10 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 90 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 91 10.2. Informative References . . . . . . . . . . . . . . . . . 12 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 94 1. Introduction 96 Multiple protocol experiments have been proposed that involve changes 97 to Explicit Congestion Notification (ECN) as specified in RFC 3168 98 [RFC3168]. This memo summarizes the proposed areas of 99 experimentation to provide an overview to the Internet community and 100 updates RFC 3168 to allow the experiments to proceed without 101 requiring a standards process exception for each Experimental RFC to 102 update RFC 3168, a Proposed Standard RFC. This memo also makes 103 related updates to the ECN specification for RTP in RFC 6679 104 [RFC6679] for the same reason. Each experiment is still required to 105 be documented in one or more separate RFCs, but use of Experimental 106 RFCs for this purpose does not require a process exception to modify 107 RFC 3168 or RFC 6679 when the modification falls within the bounds 108 established by this memo. 110 One of these areas of experimentation involves use of the ECT(1) 111 codepoint that was dedicated to the ECN Nonce experiment as described 112 in RFC 3540 [RFC3540]. This memo records the conclusion of the ECN 113 Nonce experiment, obsoletes RFC 3540 and reclassifies it as Historic. 115 1.1. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in RFC 120 2119 [RFC2119]. 122 2. Scope of ECN Experiments 124 Three areas of ECN experimentation are covered by this memo; the 125 cited Internet-Drafts should be consulted for the goals and rationale 126 of each proposed experiment: 128 Congestion Response Differences: For congestion indicated by ECN, 129 use a different IETF-approved sender congestion response (e.g., 130 reduce the response so that the sender backs off by a smaller 131 amount) by comparison to congestion indicated by loss, e.g., as 132 proposed in [I-D.khademi-tcpm-alternativebackoff-ecn] and 133 [I-D.briscoe-tsvwg-ecn-l4s-id] - the experiment in the latter 134 draft couples the backoff change to ECT Differences functionality 135 (next bullet). This is at variance with RFC 3168's requirement 136 that a sender's congestion control response to ECN congestion 137 indications be the same as to drops. 139 ECT Differences: Use ECT(1) to request ECN congestion marking 140 behavior in the network that differs from ECT(0) counterbalanced 141 by use of a different IETF-approved congestion response to CE 142 marks at the sender, e.g., as proposed in 143 [I-D.briscoe-tsvwg-ecn-l4s-id]. This is at variance with RFC 144 3168's requirement that ECT(0)-marked traffic and ECT(1)-marked 145 traffic not receive different treatment in the network. 147 Generalized ECN: Use ECN for TCP control packets (i.e., send control 148 packets such as SYN with ECT marking) and for retransmitted 149 packets, e.g., as proposed in [I-D.bagnulo-tsvwg-generalized-ecn]. 150 This is at variance with RFC 3168's prohibition of use of ECN for 151 TCP control packets and retransmitted packets 153 The scope of this memo is limited to these three areas of 154 experimentation. This memo neither prejudges the outcomes of the 155 proposed experiments nor specifies the experiments in detail. The 156 purpose of this memo is to remove constraints in standards track RFCs 157 that serve to prohibit these areas of experimentation. 159 3. ECN Nonce and RFC 3540 161 As specified in RFC 3168, ECN uses two ECN Capable Transport (ECT) 162 codepoints to indicate that a packet supports ECN, ECT(0) and ECT(1), 163 with the second codepoint used to support ECN nonce functionality to 164 discourage receivers from exploiting ECN to improve their throughput 165 at the expense of other network users, as specified in experimental 166 RFC 3540 [RFC3540]. 168 While the ECN Nonce works as specified, and has been deployed in 169 limited environments, widespread usage in the Internet has not 170 materialized. A study of the ECN behaviour of the Alexa top 1M web 171 servers using 2014 data [Trammell15] found that after ECN was 172 negotiated, none of the 581,711 IPv4 servers tested were using both 173 ECT codepoints, which would have been a possible sign of ECN Nonce 174 usage. Of the 17,028 IPv6 servers tested, 4 set both ECT(0) and 175 ECT(1) on data packets. This might have been evidence of use of the 176 ECN Nonce by these 4 servers, but equally it might have been due to 177 re-marking of the ECN field by an erroneous middlebox or router. 179 With the emergence of new experimental functionality that depends on 180 use of the ECT(1) codepoint for other purposes, continuing to reserve 181 that codepoint for the ECN Nonce experiment is no longer justified. 182 In addition, other approaches to discouraging receivers from 183 exploiting ECN have emerged, see Appendix B.1 of 184 [I-D.briscoe-tsvwg-ecn-l4s-id]. Therefore, in support of ECN 185 experimentation with the ECT(1) codepoint, this memo: 187 o Declares that the ECN Nonce experiment [RFC3540] has concluded, 188 and notes the absence of widespread deployment. 190 o Obsoletes RFC 3540 in order to facilitate experimental use of the 191 ECT(1) codepoint. 193 o Reclassifies RFC 3540 as Historic to document the ECN Nonce 194 experiment and discourage further implementation of the ECN Nonce. 196 o Updates RFC 3168 [RFC3168] to remove discussion of the ECN Nonce 197 and use of ECT(1) for that Nonce. The specific text updates are 198 omitted for brevity. 200 The following guidance on ECT codepoint usage in the ECN field of IP 201 headers from Section 5 of RFC 3168 is relevant when the ECN Nonce is 202 not implemented: 204 Protocols and senders that only require a single ECT codepoint 205 SHOULD use ECT(0). 207 OPEN ISSUE: Change the above requirement in RFC 3168 from SHOULD to 208 MUST towards reserving ECT(1) for experimentation? 210 4. Updates to RFC 3168 212 RFC 3168 is a Proposed Standard RFC, so updating RFC 3168 requires 213 publishing a standards track RFC unless a standards process exception 214 is approved by the IESG, e.g., to allow an Experimental RFC to update 215 RFC 3168. In support of the above areas of experimentation, and 216 specifically to avoid multiple uncoordinated requests to the IESG for 217 standards process exceptions, this memo updates RFC 3168 [RFC3168] 218 ito allow changes in the following areas, provided that the changes 219 are documented by an Experimental RFC. It is also possible to change 220 RFC 3168 via publication of another standards track RFC. 222 4.1. Congestion Response Differences 224 Section 5 of RFC 3168 specifies that: 226 Upon the receipt by an ECN-Capable transport of a single CE 227 packet, the congestion control algorithms followed at the end- 228 systems MUST be essentially the same as the congestion control 229 response to a *single* dropped packet. 231 In support of Congestion Response Differences experimentation, this 232 memo updates RFC 3168 to allow the congestion control response 233 (including the TCP Sender's congestion control response) to a CE- 234 marked packet to differ from the response to a dropped packet, 235 provided that the changes from RFC 3168 are documented in an 236 Experimental RFC. The specific change to RFC 3168 is to insert the 237 words "unless otherwise specified by an Experimental RFC" at the end 238 of the sentence quoted above. 240 RFC 4774 [RFC4774] quotes the above text from RFC 3168 as background, 241 but does not impose requirements based on that text. Therefore no 242 update to RFC 4774 is required to enable this area of 243 experimentation. 245 4.2. ECT Differences 247 Section 5 of RFC 3168 specifies that: 249 Routers treat the ECT(0) and ECT(1) codepoints as equivalent. 251 In support of ECT Differences experimentation, this memo updates RFC 252 3168 to allow routers to treat the ECT(0) and ECT(1) codepoints 253 differently, provided that the changes from RFC 3168 are documented 254 in an Experimental RFC. The specific change to RFC 3168 is to insert 255 the words "unless otherwise specified by an Experimental RFC" at the 256 end of the above sentence. 258 In support of ECT Differences experimentation, this memo updates RFC 259 3168 to enable effective endpoint use of ECT(1) for large scale 260 experimentation. The proposed L4S experiment 261 [I-D.briscoe-tsvwg-ecn-l4s-id] significantly increases the CE marking 262 probability for ECT(1)-marked traffic in a fashion that interacts 263 badly with existing sender congestion response functionality because 264 that functionality assumes that a CE-marked packet would have been 265 dropped by the network. If network traffic that uses such a sender 266 congestion response encounters L4S's increased marking probability 267 (and hence rate) at a network bottleneck queue, the resulting traffic 268 throughput is likely to be much less than intended for the level of 269 congestion at the bottleneck queue. To avoid that interaction, this 270 memo reserves ECT(1) for experimentation, initially L4S. The 271 specific update to Section 5 of RFC 3168 is to remove the following 272 text: 274 Senders are free to use either the ECT(0) or the ECT(1) codepoint 275 to indicate ECT, on a packet-by-packet basis. 277 The use of both the two codepoints for ECT, ECT(0) and ECT(1), is 278 motivated primarily by the desire to allow mechanisms for the data 279 sender to verify that network elements are not erasing the CE 280 codepoint, and that data receivers are properly reporting to the 281 sender the receipt of packets with the CE codepoint set, as 282 required by the transport protocol. Guidelines for the senders 283 and receivers to differentiate between the ECT(0) and ECT(1) 284 codepoints will be addressed in separate documents, for each 285 transport protocol. In particular, this document does not address 286 mechanisms for TCP end- nodes to differentiate between the ECT(0) 287 and ECT(1) codepoints. Protocols and senders that only require a 288 single ECT codepoint SHOULD use ECT(0). 290 and replace it with: 292 Unless otherwise modified by an Experimental RFC, senders MUST use 293 the ECT(0) codepoint to indicate ECT and MUST NOT use the ECT(1) 294 codepoint to indicate ECT. 296 ECT Differences experiments SHOULD modify the network behavior for 297 ECT(1)-marked traffic rather than ECT(0)-marked traffic if network 298 behavior for only one ECT codepoint is modified. ECT Differences 299 experiments MUST NOT modify the network behavior for ECT(0)-marked 300 traffic in a fashion that requires changes to sender congestion 301 response to obtain desired network behavior. If an ECT Differences 302 experiment modifies the network behavior for ECT(1)-marked traffic, 303 e.g., CE-marking behavior, in a fashion that requires changes to 304 sender congestion response to obtain desired network behavior, then 305 the Experimental RFC for that experiment MUST specify: 307 o The sender congestion response to CE marking in the network, and 309 o Router behavior changes, or the absence thereof, in fowarding CE- 310 marked packets that are part of the experiment. 312 In addition, until the conclusion of the L4S experiment, use of 313 ECT(1) in IETF RFCs is not appropriate, as the IETF may decide to 314 allocate ECT(1) exclusively for L4S usage if the L4S experiment is 315 successful. 317 In support of ECT Differences experimentation, this memo also updates 318 RFC 3168 to remove discussion of the ECN Nonce, as noted in Section 3 319 above. 321 4.3. Generalized ECN 323 RFC 3168 prohibits use of ECN for TCP control packets and 324 retransmitted packets in a number of places: 326 o "To ensure the reliable delivery of the congestion indication of 327 the CE codepoint, an ECT codepoint MUST NOT be set in a packet 328 unless the loss of that packet in the network would be detected by 329 the end nodes and interpreted as an indication of congestion." 330 (Section 5.2) 332 o "A host MUST NOT set ECT on SYN or SYN-ACK packets." 333 (Section 6.1.1) 335 o "pure acknowledgement packets (e.g., packets that do not contain 336 any accompanying data) MUST be sent with the not-ECT codepoint." 337 (Section 6.1.4) 339 o "This document specifies ECN-capable TCP implementations MUST NOT 340 set either ECT codepoint (ECT(0) or ECT(1)) in the IP header for 341 retransmitted data packets, and that the TCP data receiver SHOULD 342 ignore the ECN field on arriving data packets that are outside of 343 the receiver's current window." (Section 6.1.5) 345 o "the TCP data sender MUST NOT set either an ECT codepoint or the 346 CWR bit on window probe packets." (Section 6.1.6) 348 In support of Generalized ECN experimentation, this memo updates RFC 349 3168 to allow the use of ECT codepoints on SYN and SYN-ACK packets, 350 pure acknowledgement packets, window probe packets and 351 retransmissions of packets that were originally sent with an ECT 352 codepoint, provided that the changes from RFC 3168 are documented in 353 an Experimental RFC. The specific change to RFC 3168 is to insert 354 the words "unless otherwise specified by an Experimental RFC" at the 355 end of each sentence quoted above. 357 In addition, beyond requiring TCP senders not to set ECT on TCP 358 control packets and retransmitted packets, RFC 3168 is silent on 359 whether it is appropriate for a network element, e.g. a firewall, to 360 discard such a packet as invalid. For Generalized ECN 361 experimentation to be useful, middleboxes ought not to do that, 362 therefore RFC 3168 is updated by adding the following text to the end 363 of Section 6.1.1.1 on Middlebox Issues: 365 Unless otherwise specified by an Experimental RFC, middleboxes 366 SHOULD NOT discard TCP control packets and retransmitted TCP 367 packets solely because the ECN field in the IP header does not 368 contain Not-ECT. 370 4.4. Effective Congestion Control is Required 372 Congestion control remains an important aspect of the Internet 373 architecture [RFC2914]. Any Experimental RFC that takes advantage of 374 this memo's updates to RFC 3168 or RFC 6679 is required to discuss 375 the congestion control implications of the experiment(s) in order to 376 provide assurance that deployment of the experiment(s) does not pose 377 a congestion-based threat to the operation of the Internet. 379 5. ECN for RTP Updates to RFC 6679 381 RFC 6679 [RFC6679] specifies use of ECN for RTP traffic; it allows 382 use of both the ECT(0) and ECT(1) codepoints, and provides the 383 following guidance on use of these codepoints in section 7.3.1 : 385 The sender SHOULD mark packets as ECT(0) unless the receiver 386 expresses a preference for ECT(1) or for a random ECT value using 387 the "ect" parameter in the "a=ecn-capable-rtp:" attribute. 389 The ECT Differences area of experimentation increases the potential 390 consequences of using ECT(1) instead of ECT(0), and hence the above 391 guidance is updated by adding the following two sentences: 393 Random ECT values MUST NOT be used, as that may expose RTP to 394 differences in network treatment of traffic marked with ECT(1) and 395 ECT(0) and differences in associated endpoint congestion 396 responses, e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. 397 In addition, ECT(0) MUST be used unless otherwise specified in an 398 Experimental RFC. 400 Section 7.3.3 of RFC 6679 specifies RTP's response to receipt of CE 401 marked packets as being identical to the response to dropped packets: 403 The reception of RTP packets with ECN-CE marks in the IP header is 404 a notification that congestion is being experienced. The default 405 reaction on the reception of these ECN-CE-marked packets MUST be 406 to provide the congestion control algorithm with a congestion 407 notification that triggers the algorithm to react as if packet 408 loss had occurred. There should be no difference in congestion 409 response if ECN-CE marks or packet drops are detected. 411 In support of Congestion Response Differences experimentation, this 412 memo updates this text in a fashion similar to RFC 3168 to allow the 413 RTP congestion control response to a CE-marked packet to differ from 414 the response to a dropped packet, provided that the changes from RFC 415 6679 are documented in an Experimental RFC. The specific change to 416 RFC 6679 is to insert the words "Unless otherwise specified by an 417 Experimental RFC" and reformat the last two sentences to be subject 418 to that condition, i.e.: 420 The reception of RTP packets with ECN-CE marks in the IP header is 421 a notification that congestion is being experienced. Unless 422 otherwise specified by an Experimental RFC: 424 * The default reaction on the reception of these ECN-CE-marked 425 packets MUST be to provide the congestion control algorithm 426 with a congestion notification that triggers the algorithm to 427 react as if packet loss had occurred. 429 * There should be no difference in congestion response if ECN-CE 430 marks or packet drops are detected. 432 The second sentence of the immediately following paragraph in RFC 433 6679 requires a related update: 435 Other reactions to ECN-CE may be specified in the future, 436 following IETF Review. Detailed designs of such additional 437 reactions MUST be specified in a Standards Track RFC and be 438 reviewed to ensure they are safe for deployment under any 439 restrictions specified. 441 The update is to change "Standards Track RFC" to "Standards Track RFC 442 or Experimental RFC" for consistency with the first update. 444 6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 446 The specifications of the three DCCP Congestion Control IDs (CCIDs) 2 447 [RFC4341], 3 [RFC4342] and 4 [RFC5622] contain broadly the same 448 wording as follows: 450 each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable with 451 either the ECT(0) or the ECT(1) codepoint set. 453 This memo updates these sentences in each of the three RFCs as 454 follows: 456 each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable. 457 Unless otherwise specified by an Experimental RFC, such DCCP 458 senders SHOULD set the ECT(0) codepoint. 460 In support of ECT Differences experimentation (as noted in 461 Section 3), this memo also updates all three of these RFCs to remove 462 discussion of the ECN Nonce. The specific text updates are omitted 463 for brevity. 465 7. Acknowledgements 467 The content of this draft, including the specific portions of RFC 468 3168 that are updated draws heavily from 469 [I-D.khademi-tsvwg-ecn-response], whose authors are gratefully 470 acknowledged. The authors of the Internet Drafts describing the 471 experiments have motivated the production of this memo - their 472 interest in innovation is welcome and heartily acknowledged. Colin 473 Perkins suggested updating RFC 6679 on RTP and provided guidance on 474 where to make the updates. 476 The draft has been improved as a result of comments from a number of 477 reviewers, including Spencer Dawkins, Gorry Fairhurst, Ingemar 478 Johansson, Naeem Khademi, Mirja Kuehlewind and Michael Welzl. Bob 479 Briscoe's thorough review of an early version of this draft resulted 480 in numerous improvments including addition of the updates to the DCCP 481 RFCs. 483 8. IANA Considerations 485 This memo includes no request to IANA. 487 9. Security Considerations 489 As a process memo that makes no changes to existing protocols, there 490 are no protocol security considerations. 492 However, effective congestion control is crucial to the continued 493 operation of the Internet, and hence this memo places the 494 responsibility for not breaking Internet congestion control on the 495 experiments and the experimenters who propose them, as specified in 496 Section 4.4. 498 Security considerations for the proposed experiments are dicussed in 499 the Internet-Drafts that propose them. 501 See Appendix B.1 of [I-D.briscoe-tsvwg-ecn-l4s-id] for discussion of 502 alteratives to the ECN Nonce. 504 10. References 506 10.1. Normative References 508 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 509 Requirement Levels", BCP 14, RFC 2119, 510 DOI 10.17487/RFC2119, March 1997, 511 . 513 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 514 RFC 2914, DOI 10.17487/RFC2914, September 2000, 515 . 517 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 518 of Explicit Congestion Notification (ECN) to IP", 519 RFC 3168, DOI 10.17487/RFC3168, September 2001, 520 . 522 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 523 Congestion Notification (ECN) Signaling with Nonces", 524 RFC 3540, DOI 10.17487/RFC3540, June 2003, 525 . 527 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 528 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 529 Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 530 2006, . 532 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 533 Datagram Congestion Control Protocol (DCCP) Congestion 534 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 535 DOI 10.17487/RFC4342, March 2006, 536 . 538 [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 539 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate 540 Control for Small Packets (TFRC-SP)", RFC 5622, 541 DOI 10.17487/RFC5622, August 2009, 542 . 544 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 545 and K. Carlberg, "Explicit Congestion Notification (ECN) 546 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 547 2012, . 549 10.2. Informative References 551 [I-D.bagnulo-tsvwg-generalized-ecn] 552 Bagnulo, M. and B. Briscoe, "Adding Explicit Congestion 553 Notification (ECN) to TCP control packets", draft-bagnulo- 554 tsvwg-generalized-ecn-01 (work in progress), July 2016. 556 [I-D.briscoe-tsvwg-ecn-l4s-id] 557 Schepper, K., Briscoe, B., and I. Tsang, "Identifying 558 Modified Explicit Congestion Notification (ECN) Semantics 559 for Ultra-Low Queuing Delay", draft-briscoe-tsvwg-ecn-l4s- 560 id-02 (work in progress), October 2016. 562 [I-D.khademi-tcpm-alternativebackoff-ecn] 563 Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 564 "TCP Alternative Backoff with ECN (ABE)", draft-khademi- 565 tcpm-alternativebackoff-ecn-01 (work in progress), October 566 2016. 568 [I-D.khademi-tsvwg-ecn-response] 569 Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 570 "Updating the Explicit Congestion Notification (ECN) 571 Specification to Allow IETF Experimentation", draft- 572 khademi-tsvwg-ecn-response-01 (work in progress), July 573 2016. 575 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 576 Explicit Congestion Notification (ECN) Field", BCP 124, 577 RFC 4774, DOI 10.17487/RFC4774, November 2006, 578 . 580 [Trammell15] 581 Trammell, B., Kuehlewind, M., Boppart, D., Learmonth, I., 582 Fairhurst, G., and R. Scheffenegger, "Enabling Internet- 583 Wide Deployment of Explicit Congestion Notification". 585 In Proc Passive & Active Measurement (PAM'15) Conference 586 (2015) 588 Appendix A. Change History 590 [To be removed before RFC publication.] 592 Changes from draft-black-tsvwg-ecn-experimentation-00 to -01: 594 o Section 4.2 - also update RFC 3168 to remove sentence indicating 595 that senders are free to use both ECT codepoints. Add a SHOULD 596 for ECT Differences experiments to use ECT(1). 598 o Section 5 - only discourage use of random ECT values, but use NOT 599 RECOMMENDED to do so. Consistent use of ECT(1) without using 600 ECT(0) is ok. Mention possible changes in endpoint response. 602 o Add more Acknowledgements and Change History 604 o Additional editorial changes. 606 Changes from draft-black-tsvwg-ecn-experimentation-01 to -02: 608 o Add DCCP RFC updates and one missing RFC 3168 update (probe 609 packets). 611 o Discourage RTP usage of ECT(1). 613 o Strengthen text on lack of ECN Nonce deployment. 615 o Cross-reference the L4S draft appendix that discusses ECN Nonce 616 alternatives. 618 o Additional editorial changes. 620 Changes from draft-black-tsvwg-ecn-experimentation-02 to -03: 622 o Clarify that "SHOULD use ECT(0)" guidance from RFC 3168 is about 623 IP headers. 625 o Add a "SHOULD NOT" requirement that middleboxes not discard TCP 626 control packets, etc. solely because they use ECN. 628 o Switch to pre-5378 boilerplate, due to vintage of RFCs being 629 updated. 631 o Additional editorial changes. 633 Changes from draft-black-tsvwg-ecn-experimentation-03 to -04: 635 o Use "Congestion Response Differences" as name of experimentation 636 area instead of "Alternative Backoff" to avoid confusion with 637 specific experiment. 639 o Change ECT(1) requirement to "MUST NOT use unless otherwise 640 specified by an Experimental RFC" This resulted in extensive 641 changes to Section 4.2. 643 o Clean up and tighten language requiring all congestion responses 644 to be IETF-approved 646 o Additional editorial changes. 648 Initial WG draft, draft-ietf-tsvwg-ecn-experimentation-00, has same 649 contents as draft-black-tsvwg-ecn-experimentation-04. 651 Author's Address 653 David Black 654 Dell EMC 655 176 South Street 656 Hopkinton, MA 01748 657 USA 659 Email: david.black@dell.com