idnits 2.17.1 draft-black-tsvwg-ecn-experimentation-03.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 (October 31, 2016) is 2732 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) October 31, 2016 5 Updates: 3168, 4341, 4342, 5622, 6679 6 (if approved) 7 Intended status: Standards Track 8 Expires: May 4, 2017 10 Explicit Congestion Notification (ECN) Experimentation 11 draft-black-tsvwg-ecn-experimentation-03 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 May 4, 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. Alternative Backoff . . . . . . . . . . . . . . . . . . . 5 81 4.2. ECT Differences . . . . . . . . . . . . . . . . . . . . . 6 82 4.3. Generalized ECN . . . . . . . . . . . . . . . . . . . . . 6 83 4.4. Effective Congestion Control is Required . . . . . . . . 7 84 5. ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . . 8 85 6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 . . . . . . 9 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 90 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 91 10.2. Informative References . . . . . . . . . . . . . . . . . 11 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 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 Alternative Backoff: For congestion indicated by ECN, use a 129 different IETF-approved TCP sender response (e.g., reduce the 130 response so that the sender backs off by a smaller amount) by 131 comparison to congestion indicated by loss, e.g., as proposed in 132 [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 TCP 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 a changed response to each mark at the sender, e.g., as 142 proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. This is at variance 143 with RFC 3168's requirement that ECT(0)-marked traffic and ECT(1)- 144 marked traffic not receive different treatment in the network. 146 Generalized ECN: Use ECN for TCP control packets (i.e., send control 147 packets such as SYN with ECT marking) and for retransmitted 148 packets, e.g., as proposed in [I-D.bagnulo-tsvwg-generalized-ecn]. 149 This is at variance with RFC 3168's prohibition of use of ECN for 150 TCP control packets and retransmitted packets 152 The scope of this memo is limited to these three areas of 153 experimentation. This memo neither prejudges the outcomes of the 154 proposed experiments nor specifies the experiments in detail. The 155 purpose of this memo is to remove constraints in standards track RFCs 156 that serve to prohibit these areas of experimentation. 158 3. ECN Nonce and RFC 3540 160 As specified in RFC 3168, ECN uses two ECN Capable Transport (ECT) 161 codepoints to indicate that a packet supports ECN, ECT(0) and ECT(1), 162 with the second codepoint used to support ECN nonce functionality to 163 discourage receivers from exploiting ECN to improve their throughput 164 at the expense of other network users, as specified in experimental 165 RFC 3540 [RFC3540]. 167 While the ECN Nonce works as specified, and has been deployed in 168 limited environments, widespread usage in the Internet has not 169 materialized. A study of the ECN behaviour of the Alexa top 1M web 170 servers using 2014 data [Trammell15] found that after ECN was 171 negotiated, none of the 581,711 IPv4 servers tested were using both 172 ECT codepoints, which would have been a possible sign of ECN Nonce 173 usage. Of the 17,028 IPv6 servers tested, 4 set both ECT(0) and 174 ECT(1) on data packets. This might have been evidence of use of the 175 ECN Nonce by these 4 servers, but equally it might have been due to 176 re-marking of the ECN field by an erroneous middlebox or router. 178 With the emergence of new experimental functionality that depends on 179 use of the ECT(1) codepoint for other purposes, continuing to reserve 180 that codepoint for the ECN Nonce experiment is no longer justified. 181 In addition, alternative approaches to discouraging receivers from 182 exploiting ECN have emerged, see Appendix B.1 of 183 [I-D.briscoe-tsvwg-ecn-l4s-id]. Therefore, in support of ECN 184 experimentation with the ECT(1) codepoint, this memo: 186 o Declares that the ECN Nonce experiment [RFC3540] has concluded, 187 and notes the absence of widespread deployment. 189 o Obsoletes RFC 3540 in order to facilitate experimental use of the 190 ECT(1) codepoint. 192 o Reclassifies RFC 3540 as Historic to document the ECN Nonce 193 experiment and discourage further implementation of the ECN Nonce. 195 o Updates RFC 3168 [RFC3168] to remove discussion of the ECN Nonce 196 and use of ECT(1) for that Nonce. The specific text updates are 197 omitted for brevity. 199 The following guidance on ECT codepoint usage in the ECN field of IP 200 headers from Section 5 of RFC 3168 is relevant when the ECN Nonce is 201 not implemented: 203 Protocols and senders that only require a single ECT codepoint 204 SHOULD use ECT(0). 206 OPEN ISSUE: Change the above requirement in RFC 3168 from SHOULD to 207 MUST towards reserving ECT(1) for experimentation? 209 4. Updates to RFC 3168 211 RFC 3168 can only be updated directly by another standards track RFC 212 unless a standards process exception is approved by the IESG. In 213 support of the above areas of experimentation, and specifically to 214 avoid multiple uncoordinated requests to the IESG for process 215 exceptions, this memo updates RFC 3168 [RFC3168] ito allow changes in 216 the following areas, provided that the changes are documented by an 217 Experimental RFC. It is also possible to change RFC 3168 via 218 publication of another standards track RFC. 220 4.1. Alternative Backoff 222 Section 5 of RFC 3168 specifies that: 224 "Upon the receipt by an ECN-Capable transport of a single CE 225 packet, the congestion control algorithms followed at the end- 226 systems MUST be essentially the same as the congestion control 227 response to a *single* dropped packet." 229 In support of Alternative Backoff experimentation, this memo updates 230 RFC 3168 to allow the congestion control response (including the TCP 231 Sender's congestion control response) to a CE-marked packet to differ 232 from the response to a dropped packet, provided that the changes from 233 RFC 3168 are documented in an Experimental RFC. The specific change 234 to RFC 3168 is to insert the words "unless otherwise specified by an 235 Experimental RFC" at the end of the sentence quoted above. 237 RFC 4774 [RFC4774] quotes the above text from RFC 3168 as background, 238 but does not impose requirements based on that text. Therefore no 239 update to RFC 4774 is required to enable this area of 240 experimentation. 242 4.2. ECT Differences 244 Section 5 of RFC 3168 specifies that: 246 "Routers treat the ECT(0) and ECT(1) codepoints as equivalent. 247 Senders are free to use either the ECT(0) or the ECT(1) codepoint 248 to indicate ECT, on a packet-by-packet basis." 250 In support of ECT Differences experimentation, this memo updates RFC 251 3168 to allow routers to treat the ECT(0) and ECT(1) codepoints 252 differently, and allow requirements to be imposed on sender usage of 253 ECT(0) and ECT(1), provided that the changes from RFC 3168 are 254 documented in an Experimental RFC. That change makes the second 255 sentence quoted above misleading, so RFC 3168 is also updated to 256 remove that sentence. The specific change to RFC 3168 is to insert 257 the words "unless otherwise specified by an Experimental RFC" at the 258 end of the first sentence, and remove the second sentence with this 259 result: 261 "Routers treat the ECT(0) and ECT(1) codepoints as equivalent 262 unless otherwise specified by an Experimental RFC." 264 As ECT(0) was the original codepoint used to signal ECN capability, 265 ECT Differences experiments SHOULD modify the network behavior for 266 ECT(1) rather than ECT(0) if network behavior for only one ECT 267 codepoint is modified. 269 In support of ECT Differences experimentation, this memo also updates 270 RFC 3168 to remove discussion of the ECN Nonce, as noted in Section 3 271 above. 273 4.3. Generalized ECN 275 RFC 3168 prohibits use of ECN for TCP control packets and 276 retransmitted packets in a number of places: 278 o "To ensure the reliable delivery of the congestion indication of 279 the CE codepoint, an ECT codepoint MUST NOT be set in a packet 280 unless the loss of that packet in the network would be detected by 281 the end nodes and interpreted as an indication of congestion." 282 (Section 5.2) 284 o "A host MUST NOT set ECT on SYN or SYN-ACK packets." 285 (Section 6.1.1) 287 o "pure acknowledgement packets (e.g., packets that do not contain 288 any accompanying data) MUST be sent with the not-ECT codepoint." 289 (Section 6.1.4) 291 o "This document specifies ECN-capable TCP implementations MUST NOT 292 set either ECT codepoint (ECT(0) or ECT(1)) in the IP header for 293 retransmitted data packets, and that the TCP data receiver SHOULD 294 ignore the ECN field on arriving data packets that are outside of 295 the receiver's current window." (Section 6.1.5) 297 o "the TCP data sender MUST NOT set either an ECT codepoint or the 298 CWR bit on window probe packets." (Section 6.1.6) 300 In support of Generalized ECN experimentation, this memo updates RFC 301 3168 to allow the use of ECT codepoints on SYN and SYN-ACK packets, 302 pure acknowledgement packets, window probe packets and 303 retransmissions of packets that were originally sent with an ECT 304 codepoint, provided that the changes from RFC 3168 are documented in 305 an Experimental RFC. The specific change to RFC 3168 is to insert 306 the words "unless otherwise specified by an Experimental RFC" at the 307 end of each sentence quoted above. 309 In addition, beyond requiring TCP senders not to set ECT on TCP 310 control packets and retransmitted packets, RFC 3168 is silent on 311 whether it is appropriate for a network element, e.g. a firewall, to 312 discard such a packet as invalid. For Generalized ECN 313 experimentation to be useful, middleboxes ought not to do that, 314 therefore RFC 3168 is updated by adding the following text to the end 315 of Section 6.1.1.1 on Middlebox Issues: 317 "Unless otherwise specified by an Experimental RFC, middleboxes 318 SHOULD NOT discard TCP control packets and retransmitted TCP 319 packets solely because the ECN field in the IP header does not 320 contain Not-ECT." 322 4.4. Effective Congestion Control is Required 324 Congestion control remains an important aspect of the Internet 325 architecture [RFC2914]. Any Experimental RFC that takes advantage of 326 this memo's updates to RFC 3168 or RFC 6679 is required to discuss 327 the congestion control implications of the experiment(s) in order to 328 provide assurance that deployment of the experiment(s) does not pose 329 a congestion-based threat to the operation of the Internet. 331 5. ECN for RTP Updates to RFC 6679 333 RFC 6679 [RFC6679] specifies use of ECN for RTP traffic; it allows 334 use of both the ECT(0) and ECT(1) codepoints, and provides the 335 following guidance on use of these codepoints in section 7.3.1 : 337 The sender SHOULD mark packets as ECT(0) unless the receiver 338 expresses a preference for ECT(1) or for a random ECT value using 339 the "ect" parameter in the "a=ecn-capable-rtp:" attribute. 341 The ECT Differences area of experimentation increases the potential 342 consequences of using ECT(1) instead of ECT(0), and hence the above 343 guidance is updated by adding the following two sentences: 345 Use of random ECT values is NOT RECOMMENDED, as that may expose 346 RTP to differences in network treatment of traffic marked with 347 ECT(1) and ECT(0) and differences in associated endpoint 348 congestion responses, e.g., as proposed in 349 [I-D.briscoe-tsvwg-ecn-l4s-id]. ECT(0) SHOULD be used unless 350 there is a need for more than one ECT codepoint or unless 351 otherwise specified in an Experimental RFC. 353 Section 7.3.3 of RFC 6679 specifies RTP's response to receipt of CE 354 marked packets as being identical to the response to dropped packets: 356 The reception of RTP packets with ECN-CE marks in the IP header is 357 a notification that congestion is being experienced. The default 358 reaction on the reception of these ECN-CE-marked packets MUST be 359 to provide the congestion control algorithm with a congestion 360 notification that triggers the algorithm to react as if packet 361 loss had occurred. There should be no difference in congestion 362 response if ECN-CE marks or packet drops are detected. 364 In support of Alternative Backoff experimentation, this memo updates 365 this text in a fashion similar to RFC 3168 to allow the RTP 366 congestion control response to a CE-marked packet to differ from the 367 response to a dropped packet, provided that the changes from RFC 6679 368 are documented in an Experimental RFC. The specific change to RFC 369 6679 is to insert the words "Unless otherwise specified by an 370 Experimental RFC" and reformat the last two sentences to be subject 371 to that condition, i.e.: 373 The reception of RTP packets with ECN-CE marks in the IP header is 374 a notification that congestion is being experienced. Unless 375 otherwise specified by an Experimental RFC: 377 * The default reaction on the reception of these ECN-CE-marked 378 packets MUST be to provide the congestion control algorithm 379 with a congestion notification that triggers the algorithm to 380 react as if packet loss had occurred. 382 * There should be no difference in congestion response if ECN-CE 383 marks or packet drops are detected. 385 The second sentence of the immediately following paragraph in RFC 386 6679 requires a related update: 388 Other reactions to ECN-CE may be specified in the future, 389 following IETF Review. Detailed designs of such alternative 390 reactions MUST be specified in a Standards Track RFC and be 391 reviewed to ensure they are safe for deployment under any 392 restrictions specified. 394 The update is to change "Standards Track RFC" to "Standards Track RFC 395 or Experimental RFC" for consistency with the first update. 397 6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 399 The specifications of the three DCCP Congestion Control IDs (CCIDs) 2 400 [RFC4341], 3 [RFC4342] and 4 [RFC5622] contain broadly the same 401 wording as follows: 403 each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable with 404 either the ECT(0) or the ECT(1) codepoint set. 406 This memo updates these sentences in each of the three RFCs as 407 follows: 409 each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable. 410 Unless otherwise specified by an Experimental RFC, such DCCP 411 senders SHOULD set the ECT(0) codepoint. 413 In support of ECT Differences experimentation (as noted in 414 Section 3), this memo also updates all three of these RFCs to remove 415 discussion of the ECN Nonce. The specific text updates are omitted 416 for brevity. 418 7. Acknowledgements 420 The content of this draft, including the specific portions of RFC 421 3168 that are updated draws heavily from 422 [I-D.khademi-tsvwg-ecn-response], whose authors are gratefully 423 acknowledged. The authors of the Internet Drafts describing the 424 experiments have motivated the production of this memo - their 425 interest in innovation is welcome and heartily acknowledged. Colin 426 Perkins suggested updating RFC 6679 on RTP and provided guidance on 427 where to make the updates. 429 The draft has been improved as a result of comments from a number of 430 reviewers, including Spencer Dawkins, Gorry Fairhurst, Ingemar 431 Johansson, Naeem Khademi, Mirja Kuehlewind and Michael Welzl. Bob 432 Briscoe's thorough review of an early version of this draft resulted 433 in numerous improvments including addition of the updates to the DCCP 434 RFCs. 436 8. IANA Considerations 438 This memo includes no request to IANA. 440 9. Security Considerations 442 As a process memo that makes no changes to existing protocols, there 443 are no protocol security considerations. 445 However, effective congestion control is crucial to the continued 446 operation of the Internet, and hence this memo places the 447 responsibility for not breaking Internet congestion control on the 448 experiments and the experimenters who propose them, as specified in 449 Section 4.4. 451 Security considerations for the proposed experiments are dicussed in 452 the Internet-Drafts that propose them. 454 See Appendix B.1 of [I-D.briscoe-tsvwg-ecn-l4s-id] for discussion of 455 alteratives to the ECN Nonce. 457 10. References 459 10.1. Normative References 461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, 463 DOI 10.17487/RFC2119, March 1997, 464 . 466 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 467 RFC 2914, DOI 10.17487/RFC2914, September 2000, 468 . 470 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 471 of Explicit Congestion Notification (ECN) to IP", 472 RFC 3168, DOI 10.17487/RFC3168, September 2001, 473 . 475 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 476 Congestion Notification (ECN) Signaling with Nonces", 477 RFC 3540, DOI 10.17487/RFC3540, June 2003, 478 . 480 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 481 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 482 Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 483 2006, . 485 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 486 Datagram Congestion Control Protocol (DCCP) Congestion 487 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 488 DOI 10.17487/RFC4342, March 2006, 489 . 491 [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 492 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate 493 Control for Small Packets (TFRC-SP)", RFC 5622, 494 DOI 10.17487/RFC5622, August 2009, 495 . 497 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 498 and K. Carlberg, "Explicit Congestion Notification (ECN) 499 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 500 2012, . 502 10.2. Informative References 504 [I-D.bagnulo-tsvwg-generalized-ecn] 505 Bagnulo, M. and B. Briscoe, "Adding Explicit Congestion 506 Notification (ECN) to TCP control packets", draft-bagnulo- 507 tsvwg-generalized-ecn-01 (work in progress), July 2016. 509 [I-D.briscoe-tsvwg-ecn-l4s-id] 510 Schepper, K., Briscoe, B., and I. Tsang, "Identifying 511 Modified Explicit Congestion Notification (ECN) Semantics 512 for Ultra-Low Queuing Delay", draft-briscoe-tsvwg-ecn-l4s- 513 id-02 (work in progress), October 2016. 515 [I-D.khademi-tcpm-alternativebackoff-ecn] 516 Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 517 "TCP Alternative Backoff with ECN (ABE)", draft-khademi- 518 tcpm-alternativebackoff-ecn-01 (work in progress), October 519 2016. 521 [I-D.khademi-tsvwg-ecn-response] 522 Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 523 "Updating the Explicit Congestion Notification (ECN) 524 Specification to Allow IETF Experimentation", draft- 525 khademi-tsvwg-ecn-response-01 (work in progress), July 526 2016. 528 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 529 Explicit Congestion Notification (ECN) Field", BCP 124, 530 RFC 4774, DOI 10.17487/RFC4774, November 2006, 531 . 533 [Trammell15] 534 Trammell, B., Kuehlewind, M., Boppart, D., Learmonth, I., 535 Fairhurst, G., and R. Scheffenegger, "Enabling Internet- 536 Wide Deployment of Explicit Congestion Notification". 538 In Proc Passive & Active Measurement (PAM'15) Conference 539 (2015) 541 Appendix A. Change History 543 [To be removed before RFC publication.] 545 Changes from draft-black-tsvwg-ecn-experimentation-00 to -01: 547 o Section 4.2 - also update RFC 3168 to remove sentence indicating 548 that senders are free to use both ECT codepoints. Add a SHOULD 549 for ECT Differences experiments to use ECT(1). 551 o Section 5 - only discourage use of random ECT values, but use NOT 552 RECOMMENDED to do so. Consistent use of ECT(1) without using 553 ECT(0) is ok. Mention possible changes in endpoint response. 555 o Add more Acknowledgements and Change History 557 o Additional editorial changes. 559 Changes from draft-black-tsvwg-ecn-experimentation-01 to -02: 561 o Add DCCP RFC updates and one missing RFC 3168 update (probe 562 packets). 564 o Discourage RTP usage of ECT(1). 566 o Strengthen text on lack of ECN Nonce deployment. 568 o Cross-reference the L4S draft appendix that discusses ECN Nonce 569 alternatives. 571 o Additional editorial changes. 573 Changes from draft-black-tsvwg-ecn-experimentation-02 to -03: 575 o Clarify that "SHOULD use ECT(0)" guidance from RFC 3168 is about 576 IP headers. 578 o Add a "SHOULD NOT" requirement that middleboxes not discard TCP 579 control packets, etc. solely because they use ECN. 581 o Switch to pre-5378 boilerplate, due to vintage of RFCs being 582 updated. 584 Author's Address 586 David Black 587 Dell EMC 588 176 South Street 589 Hopkinton, MA 01748 590 USA 592 Email: david.black@dell.com