idnits 2.17.1 draft-ietf-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 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 (March 8, 2017) is 2604 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 == Outdated reference: A later version (-10) exists of draft-ietf-tcpm-dctcp-04 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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) March 8, 2017 5 Updates: 3168, 4341, 4342, 5622, 6679 6 (if approved) 7 Intended status: Standards Track 8 Expires: September 9, 2017 10 Explicit Congestion Notification (ECN) Experimentation 11 draft-ietf-tsvwg-ecn-experimentation-01 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 September 9, 2017. 46 Copyright Notice 48 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 15 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. 156 Additional experiments in these areas are possible, e.g., on use of 157 ECN to support deployment of Datacenter TCP (DCTCP) 158 [I-D.ietf-tcpm-dctcp] beyond its current applicablity limitation to 159 data center environments. The purpose of this memo is to remove 160 constraints in standards track RFCs that serve to prohibit these 161 areas of experimentation. 163 3. ECN Nonce and RFC 3540 165 As specified in RFC 3168, ECN uses two ECN Capable Transport (ECT) 166 codepoints to indicate that a packet supports ECN, ECT(0) and ECT(1), 167 with the second codepoint used to support ECN nonce functionality to 168 discourage receivers from exploiting ECN to improve their throughput 169 at the expense of other network users, as specified in experimental 170 RFC 3540 [RFC3540]. 172 While the ECN Nonce works as specified, and has been deployed in 173 limited environments, widespread usage in the Internet has not 174 materialized. A study of the ECN behaviour of the Alexa top 1M web 175 servers using 2014 data [Trammell15] found that after ECN was 176 negotiated, none of the 581,711 IPv4 servers tested were using both 177 ECT codepoints, which would have been a possible sign of ECN Nonce 178 usage. Of the 17,028 IPv6 servers tested, 4 set both ECT(0) and 179 ECT(1) on data packets. This might have been evidence of use of the 180 ECN Nonce by these 4 servers, but equally it might have been due to 181 re-marking of the ECN field by an erroneous middlebox or router. 183 With the emergence of new experimental functionality that depends on 184 use of the ECT(1) codepoint for other purposes, continuing to reserve 185 that codepoint for the ECN Nonce experiment is no longer justified. 186 In addition, other approaches to discouraging receivers from 187 exploiting ECN have emerged, see Appendix B.1 of 188 [I-D.briscoe-tsvwg-ecn-l4s-id]. Therefore, in support of ECN 189 experimentation with the ECT(1) codepoint, this memo: 191 o Declares that the ECN Nonce experiment [RFC3540] has concluded, 192 and notes the absence of widespread deployment. 194 o Obsoletes RFC 3540 in order to facilitate experimental use of the 195 ECT(1) codepoint. 197 o Reclassifies RFC 3540 as Historic to document the ECN Nonce 198 experiment and discourage further implementation of the ECN Nonce. 200 o Updates RFC 3168 [RFC3168] to remove discussion of the ECN Nonce 201 and use of ECT(1) for that Nonce. The specific text updates are 202 omitted for brevity. 204 The following guidance on ECT codepoint usage in the ECN field of IP 205 headers from Section 5 of RFC 3168 is relevant when the ECN Nonce is 206 not implemented: 208 Protocols and senders that only require a single ECT codepoint 209 SHOULD use ECT(0). 211 OPEN ISSUE: Change the above requirement in RFC 3168 from SHOULD to 212 MUST towards reserving ECT(1) for experimentation? 214 4. Updates to RFC 3168 216 RFC 3168 is a Proposed Standard RFC, so updating RFC 3168 requires 217 publishing a standards track RFC unless a standards process exception 218 is approved by the IESG, e.g., to allow an Experimental RFC to update 219 RFC 3168. In support of the above areas of experimentation, and 220 specifically to avoid multiple uncoordinated requests to the IESG for 221 standards process exceptions, this memo updates RFC 3168 [RFC3168] 222 ito allow changes in the following areas, provided that the changes 223 are documented by an Experimental RFC. It is also possible to change 224 RFC 3168 via publication of another standards track RFC. 226 4.1. Congestion Response Differences 228 Section 5 of RFC 3168 specifies that: 230 Upon the receipt by an ECN-Capable transport of a single CE 231 packet, the congestion control algorithms followed at the end- 232 systems MUST be essentially the same as the congestion control 233 response to a *single* dropped packet. 235 In support of Congestion Response Differences experimentation, this 236 memo updates RFC 3168 to allow the congestion control response 237 (including the TCP Sender's congestion control response) to a CE- 238 marked packet to differ from the response to a dropped packet, 239 provided that the changes from RFC 3168 are documented in an 240 Experimental RFC. The specific change to RFC 3168 is to insert the 241 words "unless otherwise specified by an Experimental RFC" at the end 242 of the sentence quoted above. 244 RFC 4774 [RFC4774] quotes the above text from RFC 3168 as background, 245 but does not impose requirements based on that text. Therefore no 246 update to RFC 4774 is required to enable this area of 247 experimentation. 249 4.2. ECT Differences 251 Section 5 of RFC 3168 specifies that: 253 Routers treat the ECT(0) and ECT(1) codepoints as equivalent. 255 In support of ECT Differences experimentation, this memo updates RFC 256 3168 to allow routers to treat the ECT(0) and ECT(1) codepoints 257 differently, provided that the changes from RFC 3168 are documented 258 in an Experimental RFC. The specific change to RFC 3168 is to insert 259 the words "unless otherwise specified by an Experimental RFC" at the 260 end of the above sentence. 262 In support of ECT Differences experimentation, this memo updates RFC 263 3168 to enable effective endpoint use of ECT(1) for large scale 264 experimentation. The proposed L4S experiment 265 [I-D.briscoe-tsvwg-ecn-l4s-id] significantly increases the CE marking 266 probability for ECT(1)-marked traffic in a fashion that interacts 267 badly with existing sender congestion response functionality because 268 that functionality assumes that a CE-marked packet would have been 269 dropped by the network. If network traffic that uses such a sender 270 congestion response encounters L4S's increased marking probability 271 (and hence rate) at a network bottleneck queue, the resulting traffic 272 throughput is likely to be much less than intended for the level of 273 congestion at the bottleneck queue. To avoid that interaction, this 274 memo reserves ECT(1) for experimentation, initially L4S. The 275 specific update to Section 5 of RFC 3168 is to remove the following 276 text: 278 Senders are free to use either the ECT(0) or the ECT(1) codepoint 279 to indicate ECT, on a packet-by-packet basis. 281 The use of both the two codepoints for ECT, ECT(0) and ECT(1), is 282 motivated primarily by the desire to allow mechanisms for the data 283 sender to verify that network elements are not erasing the CE 284 codepoint, and that data receivers are properly reporting to the 285 sender the receipt of packets with the CE codepoint set, as 286 required by the transport protocol. Guidelines for the senders 287 and receivers to differentiate between the ECT(0) and ECT(1) 288 codepoints will be addressed in separate documents, for each 289 transport protocol. In particular, this document does not address 290 mechanisms for TCP end- nodes to differentiate between the ECT(0) 291 and ECT(1) codepoints. Protocols and senders that only require a 292 single ECT codepoint SHOULD use ECT(0). 294 and replace it with: 296 Unless otherwise modified by an Experimental RFC, senders MUST use 297 the ECT(0) codepoint to indicate ECT and MUST NOT use the ECT(1) 298 codepoint to indicate ECT. 300 ECT Differences experiments SHOULD modify the network behavior for 301 ECT(1)-marked traffic rather than ECT(0)-marked traffic if network 302 behavior for only one ECT codepoint is modified. ECT Differences 303 experiments MUST NOT modify the network behavior for ECT(0)-marked 304 traffic in a fashion that requires changes to sender congestion 305 response to obtain desired network behavior. If an ECT Differences 306 experiment modifies the network behavior for ECT(1)-marked traffic, 307 e.g., CE-marking behavior, in a fashion that requires changes to 308 sender congestion response to obtain desired network behavior, then 309 the Experimental RFC for that experiment MUST specify: 311 o The sender congestion response to CE marking in the network, and 313 o Router behavior changes, or the absence thereof, in fowarding CE- 314 marked packets that are part of the experiment. 316 In addition, until the conclusion of the L4S experiment, use of 317 ECT(1) in IETF RFCs is not appropriate, as the IETF may decide to 318 allocate ECT(1) exclusively for L4S usage if the L4S experiment is 319 successful. 321 In support of ECT Differences experimentation, this memo also updates 322 RFC 3168 to remove discussion of the ECN Nonce, as noted in Section 3 323 above. 325 4.3. Generalized ECN 327 RFC 3168 prohibits use of ECN for TCP control packets and 328 retransmitted packets in a number of places: 330 o "To ensure the reliable delivery of the congestion indication of 331 the CE codepoint, an ECT codepoint MUST NOT be set in a packet 332 unless the loss of that packet in the network would be detected by 333 the end nodes and interpreted as an indication of congestion." 334 (Section 5.2) 336 o "A host MUST NOT set ECT on SYN or SYN-ACK packets." 337 (Section 6.1.1) 339 o "pure acknowledgement packets (e.g., packets that do not contain 340 any accompanying data) MUST be sent with the not-ECT codepoint." 341 (Section 6.1.4) 343 o "This document specifies ECN-capable TCP implementations MUST NOT 344 set either ECT codepoint (ECT(0) or ECT(1)) in the IP header for 345 retransmitted data packets, and that the TCP data receiver SHOULD 346 ignore the ECN field on arriving data packets that are outside of 347 the receiver's current window." (Section 6.1.5) 349 o "the TCP data sender MUST NOT set either an ECT codepoint or the 350 CWR bit on window probe packets." (Section 6.1.6) 352 In support of Generalized ECN experimentation, this memo updates RFC 353 3168 to allow the use of ECT codepoints on SYN and SYN-ACK packets, 354 pure acknowledgement packets, window probe packets and 355 retransmissions of packets that were originally sent with an ECT 356 codepoint, provided that the changes from RFC 3168 are documented in 357 an Experimental RFC. The specific change to RFC 3168 is to insert 358 the words "unless otherwise specified by an Experimental RFC" at the 359 end of each sentence quoted above. 361 In addition, beyond requiring TCP senders not to set ECT on TCP 362 control packets and retransmitted packets, RFC 3168 is silent on 363 whether it is appropriate for a network element, e.g. a firewall, to 364 discard such a packet as invalid. For Generalized ECN 365 experimentation to be useful, middleboxes ought not to do that, 366 therefore RFC 3168 is updated by adding the following text to the end 367 of Section 6.1.1.1 on Middlebox Issues: 369 Unless otherwise specified by an Experimental RFC, middleboxes 370 SHOULD NOT discard TCP control packets and retransmitted TCP 371 packets solely because the ECN field in the IP header does not 372 contain Not-ECT. 374 4.4. Effective Congestion Control is Required 376 Congestion control remains an important aspect of the Internet 377 architecture [RFC2914]. Any Experimental RFC that takes advantage of 378 this memo's updates to RFC 3168 or RFC 6679 is required to discuss 379 the congestion control implications of the experiment(s) in order to 380 provide assurance that deployment of the experiment(s) does not pose 381 a congestion-based threat to the operation of the Internet. 383 5. ECN for RTP Updates to RFC 6679 385 RFC 6679 [RFC6679] specifies use of ECN for RTP traffic; it allows 386 use of both the ECT(0) and ECT(1) codepoints, and provides the 387 following guidance on use of these codepoints in section 7.3.1 : 389 The sender SHOULD mark packets as ECT(0) unless the receiver 390 expresses a preference for ECT(1) or for a random ECT value using 391 the "ect" parameter in the "a=ecn-capable-rtp:" attribute. 393 The ECT Differences area of experimentation increases the potential 394 consequences of using ECT(1) instead of ECT(0), and hence the above 395 guidance is updated by adding the following two sentences: 397 Random ECT values MUST NOT be used, as that may expose RTP to 398 differences in network treatment of traffic marked with ECT(1) and 399 ECT(0) and differences in associated endpoint congestion 400 responses, e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. 401 In addition, ECT(0) MUST be used unless otherwise specified in an 402 Experimental RFC. 404 Section 7.3.3 of RFC 6679 specifies RTP's response to receipt of CE 405 marked packets as being identical to the response to dropped packets: 407 The reception of RTP packets with ECN-CE marks in the IP header is 408 a notification that congestion is being experienced. The default 409 reaction on the reception of these ECN-CE-marked packets MUST be 410 to provide the congestion control algorithm with a congestion 411 notification that triggers the algorithm to react as if packet 412 loss had occurred. There should be no difference in congestion 413 response if ECN-CE marks or packet drops are detected. 415 In support of Congestion Response Differences experimentation, this 416 memo updates this text in a fashion similar to RFC 3168 to allow the 417 RTP congestion control response to a CE-marked packet to differ from 418 the response to a dropped packet, provided that the changes from RFC 419 6679 are documented in an Experimental RFC. The specific change to 420 RFC 6679 is to insert the words "Unless otherwise specified by an 421 Experimental RFC" and reformat the last two sentences to be subject 422 to that condition, i.e.: 424 The reception of RTP packets with ECN-CE marks in the IP header is 425 a notification that congestion is being experienced. Unless 426 otherwise specified by an Experimental RFC: 428 * The default reaction on the reception of these ECN-CE-marked 429 packets MUST be to provide the congestion control algorithm 430 with a congestion notification that triggers the algorithm to 431 react as if packet loss had occurred. 433 * There should be no difference in congestion response if ECN-CE 434 marks or packet drops are detected. 436 The second sentence of the immediately following paragraph in RFC 437 6679 requires a related update: 439 Other reactions to ECN-CE may be specified in the future, 440 following IETF Review. Detailed designs of such additional 441 reactions MUST be specified in a Standards Track RFC and be 442 reviewed to ensure they are safe for deployment under any 443 restrictions specified. 445 The update is to change "Standards Track RFC" to "Standards Track RFC 446 or Experimental RFC" for consistency with the first update. 448 6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 450 The specifications of the three DCCP Congestion Control IDs (CCIDs) 2 451 [RFC4341], 3 [RFC4342] and 4 [RFC5622] contain broadly the same 452 wording as follows: 454 each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable with 455 either the ECT(0) or the ECT(1) codepoint set. 457 This memo updates these sentences in each of the three RFCs as 458 follows: 460 each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable. 461 Unless otherwise specified by an Experimental RFC, such DCCP 462 senders SHOULD set the ECT(0) codepoint. 464 In support of ECT Differences experimentation (as noted in 465 Section 3), this memo also updates all three of these RFCs to remove 466 discussion of the ECN Nonce. The specific text updates are omitted 467 for brevity. 469 7. Acknowledgements 471 The content of this draft, including the specific portions of RFC 472 3168 that are updated draws heavily from 473 [I-D.khademi-tsvwg-ecn-response], whose authors are gratefully 474 acknowledged. The authors of the Internet Drafts describing the 475 experiments have motivated the production of this memo - their 476 interest in innovation is welcome and heartily acknowledged. Colin 477 Perkins suggested updating RFC 6679 on RTP and provided guidance on 478 where to make the updates. 480 The draft has been improved as a result of comments from a number of 481 reviewers, including Spencer Dawkins, Gorry Fairhurst, Ingemar 482 Johansson, Naeem Khademi, Mirja Kuehlewind, Karen Nielsen and Michael 483 Welzl. Bob Briscoe's thorough review of an early version of this 484 draft resulted in numerous improvments including addition of the 485 updates to the DCCP RFCs. 487 8. IANA Considerations 489 This memo includes no request to IANA. 491 9. Security Considerations 493 As a process memo that makes no changes to existing protocols, there 494 are no protocol security considerations. 496 However, effective congestion control is crucial to the continued 497 operation of the Internet, and hence this memo places the 498 responsibility for not breaking Internet congestion control on the 499 experiments and the experimenters who propose them, as specified in 500 Section 4.4. 502 Security considerations for the proposed experiments are dicussed in 503 the Internet-Drafts that propose them. 505 See Appendix B.1 of [I-D.briscoe-tsvwg-ecn-l4s-id] for discussion of 506 alteratives to the ECN Nonce. 508 10. References 510 10.1. Normative References 512 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 513 Requirement Levels", BCP 14, RFC 2119, 514 DOI 10.17487/RFC2119, March 1997, 515 . 517 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 518 RFC 2914, DOI 10.17487/RFC2914, September 2000, 519 . 521 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 522 of Explicit Congestion Notification (ECN) to IP", 523 RFC 3168, DOI 10.17487/RFC3168, September 2001, 524 . 526 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 527 Congestion Notification (ECN) Signaling with Nonces", 528 RFC 3540, DOI 10.17487/RFC3540, June 2003, 529 . 531 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 532 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 533 Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 534 2006, . 536 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 537 Datagram Congestion Control Protocol (DCCP) Congestion 538 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 539 DOI 10.17487/RFC4342, March 2006, 540 . 542 [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 543 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate 544 Control for Small Packets (TFRC-SP)", RFC 5622, 545 DOI 10.17487/RFC5622, August 2009, 546 . 548 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 549 and K. Carlberg, "Explicit Congestion Notification (ECN) 550 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 551 2012, . 553 10.2. Informative References 555 [I-D.bagnulo-tsvwg-generalized-ecn] 556 Bagnulo, M. and B. Briscoe, "Adding Explicit Congestion 557 Notification (ECN) to TCP control packets", draft-bagnulo- 558 tsvwg-generalized-ecn-01 (work in progress), July 2016. 560 [I-D.briscoe-tsvwg-ecn-l4s-id] 561 Schepper, K., Briscoe, B., and I. Tsang, "Identifying 562 Modified Explicit Congestion Notification (ECN) Semantics 563 for Ultra-Low Queuing Delay", draft-briscoe-tsvwg-ecn-l4s- 564 id-02 (work in progress), October 2016. 566 [I-D.ietf-tcpm-dctcp] 567 Bensley, S., Eggert, L., Thaler, D., Balasubramanian, P., 568 and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion 569 Control for Datacenters", draft-ietf-tcpm-dctcp-04 (work 570 in progress), February 2017. 572 [I-D.khademi-tcpm-alternativebackoff-ecn] 573 Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 574 "TCP Alternative Backoff with ECN (ABE)", draft-khademi- 575 tcpm-alternativebackoff-ecn-01 (work in progress), October 576 2016. 578 [I-D.khademi-tsvwg-ecn-response] 579 Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 580 "Updating the Explicit Congestion Notification (ECN) 581 Specification to Allow IETF Experimentation", draft- 582 khademi-tsvwg-ecn-response-01 (work in progress), July 583 2016. 585 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 586 Explicit Congestion Notification (ECN) Field", BCP 124, 587 RFC 4774, DOI 10.17487/RFC4774, November 2006, 588 . 590 [Trammell15] 591 Trammell, B., Kuehlewind, M., Boppart, D., Learmonth, I., 592 Fairhurst, G., and R. Scheffenegger, "Enabling Internet- 593 Wide Deployment of Explicit Congestion Notification". 595 In Proc Passive & Active Measurement (PAM'15) Conference 596 (2015) 598 Appendix A. Change History 600 [To be removed before RFC publication.] 602 Changes from draft-black-tsvwg-ecn-experimentation-00 to -01: 604 o Section 4.2 - also update RFC 3168 to remove sentence indicating 605 that senders are free to use both ECT codepoints. Add a SHOULD 606 for ECT Differences experiments to use ECT(1). 608 o Section 5 - only discourage use of random ECT values, but use NOT 609 RECOMMENDED to do so. Consistent use of ECT(1) without using 610 ECT(0) is ok. Mention possible changes in endpoint response. 612 o Add more Acknowledgements and Change History 614 o Additional editorial changes. 616 Changes from draft-black-tsvwg-ecn-experimentation-01 to -02: 618 o Add DCCP RFC updates and one missing RFC 3168 update (probe 619 packets). 621 o Discourage RTP usage of ECT(1). 623 o Strengthen text on lack of ECN Nonce deployment. 625 o Cross-reference the L4S draft appendix that discusses ECN Nonce 626 alternatives. 628 o Additional editorial changes. 630 Changes from draft-black-tsvwg-ecn-experimentation-02 to -03: 632 o Clarify that "SHOULD use ECT(0)" guidance from RFC 3168 is about 633 IP headers. 635 o Add a "SHOULD NOT" requirement that middleboxes not discard TCP 636 control packets, etc. solely because they use ECN. 638 o Switch to pre-5378 boilerplate, due to vintage of RFCs being 639 updated. 641 o Additional editorial changes. 643 Changes from draft-black-tsvwg-ecn-experimentation-03 to -04: 645 o Use "Congestion Response Differences" as name of experimentation 646 area instead of "Alternative Backoff" to avoid confusion with 647 specific experiment. 649 o Change ECT(1) requirement to "MUST NOT use unless otherwise 650 specified by an Experimental RFC" This resulted in extensive 651 changes to Section 4.2. 653 o Clean up and tighten language requiring all congestion responses 654 to be IETF-approved 656 o Additional editorial changes. 658 Initial WG draft, draft-ietf-tsvwg-ecn-experimentation-00, has same 659 contents as draft-black-tsvwg-ecn-experimentation-04. 661 Changes from draft-ietf-tsvwg-ecn-experimentation-00 to -01: 663 o Add mention of DCTCP as another protocol that could benefit from 664 ECN experimentation (near end of Section 2). 666 Author's Address 668 David Black 669 Dell EMC 670 176 South Street 671 Hopkinton, MA 01748 672 USA 674 Email: david.black@dell.com