idnits 2.17.1 draft-black-tsvwg-ecn-experimentation-02.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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 28, 2016) is 2709 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 (-02) exists of draft-briscoe-tsvwg-ecn-l4s-id-01 == Outdated reference: A later version (-01) exists of draft-khademi-tcpm-alternativebackoff-ecn-00 Summary: 2 errors (**), 0 flaws (~~), 3 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) October 28, 2016 5 Updates: 3168, 4341, 4342, 5622, 6679 6 (if approved) 7 Intended status: Standards Track 8 Expires: May 1, 2017 10 Explicit Congestion Notification (ECN) Experimentation 11 draft-black-tsvwg-ecn-experimentation-02 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 1, 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 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 65 2. Scope of ECN Experiments . . . . . . . . . . . . . . . . . . 3 66 3. ECN Nonce and RFC 3540 . . . . . . . . . . . . . . . . . . . 4 67 4. Updates to RFC 3168 . . . . . . . . . . . . . . . . . . . . . 5 68 4.1. Alternative Backoff . . . . . . . . . . . . . . . . . . . 5 69 4.2. ECT Differences . . . . . . . . . . . . . . . . . . . . . 5 70 4.3. Generalized ECN . . . . . . . . . . . . . . . . . . . . . 6 71 4.4. Effective Congestion Control is Required . . . . . . . . 7 72 5. ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . . 7 73 6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 . . . . . . 8 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 10.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 Multiple protocol experiments have been proposed that involve changes 85 to Explicit Congestion Notification (ECN) as specified in RFC 3168 86 [RFC3168]. This memo summarizes the proposed areas of 87 experimentation to provide an overview to the Internet community and 88 updates RFC 3168 to allow the experiments to proceed without 89 requiring a standards process exception for each Experimental RFC to 90 update RFC 3168, a Proposed Standard RFC. This memo also makes 91 related updates to the ECN specification for RTP in RFC 6679 92 [RFC6679] for the same reason. Each experiment is still required to 93 be documented in one or more separate RFCs, but use of Experimental 94 RFCs for this purpose does not require a process exception to modify 95 RFC 3168 or RFC 6679 when the modification falls within the bounds 96 established by this memo. 98 One of these areas of experimentation involves use of the ECT(1) 99 codepoint that was dedicated to the ECN Nonce experiment as described 100 in RFC 3540 [RFC3540]. This memo records the conclusion of the ECN 101 Nonce experiment, obsoletes RFC 3540 and reclassifies it as Historic. 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in RFC 108 2119 [RFC2119]. 110 2. Scope of ECN Experiments 112 Three areas of ECN experimentation are covered by this memo; the 113 cited Internet-Drafts should be consulted for the goals and rationale 114 of each proposed experiment: 116 Alternative Backoff: For congestion indicated by ECN, use a 117 different IETF-approved TCP sender response (e.g., reduce the 118 response so that the sender backs off by a smaller amount) by 119 comparison to congestion indicated by loss, e.g., as proposed in 120 [I-D.khademi-tcpm-alternativebackoff-ecn] and 121 [I-D.briscoe-tsvwg-ecn-l4s-id] - the experiment in the latter 122 draft couples the backoff change to ECT Differences functionality 123 (next bullet). This is at variance with RFC 3168's requirement 124 that a TCP sender's congestion control response to ECN congestion 125 indications be the same as to drops. 127 ECT Differences: Use ECT(1) to request ECN congestion marking 128 behavior in the network that differs from ECT(0) counterbalanced 129 by a changed response to each mark at the sender, e.g., as 130 proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. This is at variance 131 with RFC 3168's requirement that ECT(0)-marked traffic and ECT(1)- 132 marked traffic not receive different treatment in the network. 134 Generalized ECN: Use ECN for TCP control packets (i.e., send control 135 packets such as SYN with ECT marking) and for retransmitted 136 packets, e.g., as proposed in [I-D.bagnulo-tsvwg-generalized-ecn]. 137 This is at variance with RFC 3168's prohibition of use of ECN for 138 TCP control packets and retransmitted packets 140 The scope of this memo is limited to these three areas of 141 experimentation. This memo neither prejudges the outcomes of the 142 proposed experiments nor specifies the experiments in detail. The 143 purpose of this memo is to remove constraints in standards track RFCs 144 that serve to prohibit these areas of experimentation. 146 3. ECN Nonce and RFC 3540 148 As specified in RFC 3168, ECN uses two ECN Capable Transport (ECT) 149 codepoints to indicate that a packet supports ECN, ECT(0) and ECT(1), 150 with the second codepoint used to support ECN nonce functionality to 151 discourage receivers from exploiting ECN to improve their throughput 152 at the expense of other network users, as specified in experimental 153 RFC 3540 [RFC3540]. 155 While the ECN Nonce works as specified, and has been deployed in 156 limited environments, widespread usage in the Internet has not 157 materialized. A study of the ECN behaviour of the Alexa top 1M web 158 servers using 2014 data [Trammell15] found that after ECN was 159 negotiated, none of the 581,711 IPv4 servers tested were using both 160 ECT codepoints, which would have been a possible sign of ECN Nonce 161 usage. Of the 17,028 IPv6 servers tested, 4 set both ECT(0) and 162 ECT(1) on data packets. This might have been evidence of use of the 163 ECN Nonce by these 4 servers, but equally it might have been due to 164 re-marking of the ECN field by an erroneous middlebox or router. 166 With the emergence of new experimental functionality that depends on 167 use of the ECT(1) codepoint for other purposes, continuing to reserve 168 that codepoint for the ECN Nonce experiment is no longer justified. 169 In addition, alternative approaches to discouraging receivers from 170 exploiting ECN have emerged, see Appendix B.1 of 171 [I-D.briscoe-tsvwg-ecn-l4s-id]. Therefore, in support of ECN 172 experimentation with the ECT(1) codepoint, this memo: 174 o Declares that the ECN Nonce experiment [RFC3540] has concluded, 175 and notes the absence of widespread deployment. 177 o Obsoletes RFC 3540 in order to facilitate experimental use of the 178 ECT(1) codepoint. 180 o Reclassifies RFC 3540 as Historic to document the ECN Nonce 181 experiment and discourage further implementation of the ECN Nonce. 183 o Updates RFC 3168 [RFC3168] to remove discussion of the ECN Nonce 184 and use of ECT(1) for that Nonce. The specific text updates are 185 omitted for brevity. 187 The following guidance on ECT codepoint usage in Section 5 of RFC 188 3168 is relevant when the ECN Nonce is not implemented: 190 Protocols and senders that only require a single ECT codepoint 191 SHOULD use ECT(0). 193 OPEN ISSUE: Change the above requirement in RFC 3168 from SHOULD to 194 MUST towards reserving ECT(1) for experimentation? 196 4. Updates to RFC 3168 198 RFC 3168 can only be updated directly by another standards track RFC 199 unless a standards process exception is approved by the IESG. In 200 support of the above areas of experimentation, and specifically to 201 avoid multiple uncoordinated requests to the IESG for process 202 exceptions, this memo updates RFC 3168 [RFC3168] ito allow changes in 203 the following areas, provided that the changes are documented by an 204 Experimental RFC. It is also possible to change RFC 3168 via 205 publication of another standards track RFC. 207 4.1. Alternative Backoff 209 Section 5 of RFC 3168 specifies that: 211 "Upon the receipt by an ECN-Capable transport of a single CE 212 packet, the congestion control algorithms followed at the end- 213 systems MUST be essentially the same as the congestion control 214 response to a *single* dropped packet." 216 In support of Alternative Backoff experimentation, this memo updates 217 RFC 3168 to allow the congestion control response (including the TCP 218 Sender's congestion control response) to a CE-marked packet to differ 219 from the response to a dropped packet, provided that the changes from 220 RFC 3168 are documented in an Experimental RFC. The specific change 221 to RFC 3168 is to insert the words "unless otherwise specified by an 222 Experimental RFC" at the end of the sentence quoted above. 224 RFC 4774 [RFC4774] quotes the above text from RFC 3168 as background, 225 but does not impose requirements based on that text. Therefore no 226 update to RFC 4774 is required to enable this area of 227 experimentation. 229 4.2. ECT Differences 231 Section 5 of RFC 3168 specifies that: 233 "Routers treat the ECT(0) and ECT(1) codepoints as equivalent. 234 Senders are free to use either the ECT(0) or the ECT(1) codepoint 235 to indicate ECT, on a packet-by-packet basis." 237 In support of ECT Differences experimentation, this memo updates RFC 238 3168 to allow routers to treat the ECT(0) and ECT(1) codepoints 239 differently, and allow requirements to be imposed on sender usage of 240 ECT(0) and ECT(1), provided that the changes from RFC 3168 are 241 documented in an Experimental RFC. That change makes the second 242 sentence quoted above misleading, so RFC 3168 is also updated to 243 remove that sentence. The specific change to RFC 3168 is to insert 244 the words "unless otherwise specified by an Experimental RFC" at the 245 end of the first sentence, and remove the second sentence with this 246 result: 248 "Routers treat the ECT(0) and ECT(1) codepoints as equivalent 249 unless otherwise specified by an Experimental RFC." 251 As ECT(0) was the original codepoint used to signal ECN capability, 252 ECT Differences experiments SHOULD modify the network behavior for 253 ECT(1) rather than ECT(0) if network behavior for only one ECT 254 codepoint is modified. 256 In support of ECT Differences experimentation, this memo also updates 257 RFC 3168 to remove discussion of the ECN Nonce, as noted in Section 3 258 above. 260 4.3. Generalized ECN 262 RFC 3168 prohibits use of ECN for TCP control packets and 263 retransmitted packets in a number of places: 265 o "To ensure the reliable delivery of the congestion indication of 266 the CE codepoint, an ECT codepoint MUST NOT be set in a packet 267 unless the loss of that packet in the network would be detected by 268 the end nodes and interpreted as an indication of congestion." 269 (Section 5.2) 271 o "A host MUST NOT set ECT on SYN or SYN-ACK packets." 272 (Section 6.1.1) 274 o "pure acknowledgement packets (e.g., packets that do not contain 275 any accompanying data) MUST be sent with the not-ECT codepoint." 276 (Section 6.1.4) 278 o "This document specifies ECN-capable TCP implementations MUST NOT 279 set either ECT codepoint (ECT(0) or ECT(1)) in the IP header for 280 retransmitted data packets, and that the TCP data receiver SHOULD 281 ignore the ECN field on arriving data packets that are outside of 282 the receiver's current window." (Section 6.1.5) 284 o "the TCP data sender MUST NOT set either an ECT codepoint or the 285 CWR bit on window probe packets." (Section 6.1.6) 287 In support of Generalized ECN experimentation, this memo updates RFC 288 3168 to allow the use of ECT codepoints on SYN and SYN-ACK packets, 289 pure acknowledgement packets, window probe packets and 290 retransmissions of packets that were originally sent with an ECT 291 codepoint, provided that the changes from RFC 3168 are documented in 292 an Experimental RFC. The specific change to RFC 3168 is to insert 293 the words "unless otherwise specified by an Experimental RFC" at the 294 end of each sentence quoted above. 296 4.4. Effective Congestion Control is Required 298 Congestion control remains an important aspect of the Internet 299 architecture [RFC2914]. Any Experimental RFC that takes advantage of 300 this memo's updates to RFC 3168 or RFC 6679 is required to discuss 301 the congestion control implications of the experiment(s) in order to 302 provide assurance that deployment of the experiment(s) does not pose 303 a congestion-based threat to the operation of the Internet. 305 5. ECN for RTP Updates to RFC 6679 307 RFC 6679 [RFC6679] specifies use of ECN for RTP traffic; it allows 308 use of both the ECT(0) and ECT(1) codepoints, and provides the 309 following guidance on use of these codepoints in section 7.3.1 : 311 The sender SHOULD mark packets as ECT(0) unless the receiver 312 expresses a preference for ECT(1) or for a random ECT value using 313 the "ect" parameter in the "a=ecn-capable-rtp:" attribute. 315 The ECT Differences area of experimentation increases the potential 316 consequences of using ECT(1) instead of ECT(0), and hence the above 317 guidance is updated by adding the following two sentences: 319 Use of random ECT values is NOT RECOMMENDED, as that may expose 320 RTP to differences in network treatment of traffic marked with 321 ECT(1) and ECT(0) and differences in associated endpoint 322 congestion responses, e.g., as proposed in 323 [I-D.briscoe-tsvwg-ecn-l4s-id]. ECT(0) SHOULD be used unless 324 there is a need for more than one ECT codepoint or unless 325 otherwise specified in an Experimental RFC. 327 Section 7.3.3 of RFC 6679 specifies RTP's response to receipt of CE 328 marked packets as being identical to the response to dropped packets: 330 The reception of RTP packets with ECN-CE marks in the IP header is 331 a notification that congestion is being experienced. The default 332 reaction on the reception of these ECN-CE-marked packets MUST be 333 to provide the congestion control algorithm with a congestion 334 notification that triggers the algorithm to react as if packet 335 loss had occurred. There should be no difference in congestion 336 response if ECN-CE marks or packet drops are detected. 338 In support of Alternative Backoff experimentation, this memo updates 339 this text in a fashion similar to RFC 3168 to allow the RTP 340 congestion control response to a CE-marked packet to differ from the 341 response to a dropped packet, provided that the changes from RFC 6679 342 are documented in an Experimental RFC. The specific change to RFC 343 6679 is to insert the words "Unless otherwise specified by an 344 Experimental RFC" and reformat the last two sentences to be subject 345 to that condition, i.e.: 347 The reception of RTP packets with ECN-CE marks in the IP header is 348 a notification that congestion is being experienced. Unless 349 otherwise specified by an Experimental RFC: 351 * The default reaction on the reception of these ECN-CE-marked 352 packets MUST be to provide the congestion control algorithm 353 with a congestion notification that triggers the algorithm to 354 react as if packet loss had occurred. 356 * There should be no difference in congestion response if ECN-CE 357 marks or packet drops are detected. 359 The second sentence of the immediately following paragraph in RFC 360 6679 requires a related update: 362 Other reactions to ECN-CE may be specified in the future, 363 following IETF Review. Detailed designs of such alternative 364 reactions MUST be specified in a Standards Track RFC and be 365 reviewed to ensure they are safe for deployment under any 366 restrictions specified. 368 The update is to change "Standards Track RFC" to "Standards Track RFC 369 or Experimental RFC" for consistency with the first update. 371 6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 373 The specifications of the three DCCP Congestion Control IDs (CCIDs) 2 374 [RFC4341], 3 [RFC4342] and 4 [RFC5622] contain broadly the same 375 wording as follows: 377 each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable with 378 either the ECT(0) or the ECT(1) codepoint set. 380 This memo updates these sentences in each of the three RFCs as 381 follows: 383 each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable. 384 Unless otherwise specified by an Experimental RFC, such DCCP 385 senders SHOULD set the ECT(0) codepoint. 387 In support of ECT Differences experimentation (as noted in 388 Section 3), this memo also updates all three of these RFCs to remove 389 discussion of the ECN Nonce. The specific text updates are omitted 390 for brevity. 392 7. Acknowledgements 394 The content of this draft, including the specific portions of RFC 395 3168 that are updated draws heavily from 396 [I-D.khademi-tsvwg-ecn-response], whose authors are gratefully 397 acknowledged. The authors of the Internet Drafts describing the 398 experiments have motivated the production of this memo - their 399 interest in innovation is welcome and heartily acknowledged. Colin 400 Perkins suggested updating RFC 6679 on RTP and provided guidance on 401 where to make the updates. 403 The draft has been improved as a result of comments from a number of 404 reviewers, including Spencer Dawkins, Gorry Fairhurst, Ingemar 405 Johansson, Naeem Khademi, Mirja Kuehlewind and Michael Welzl. Bob 406 Briscoe's thorough review of an early version of this draft resulted 407 in numerous improvments including addition of the updates to the DCCP 408 RFCs. 410 8. IANA Considerations 412 This memo includes no request to IANA. 414 9. Security Considerations 416 As a process memo that makes no changes to existing protocols, there 417 are no protocol security considerations. 419 However, effective congestion control is crucial to the continued 420 operation of the Internet, and hence this memo places the 421 responsibility for not breaking Internet congestion control on the 422 experiments and the experimenters who propose them, as specified in 423 Section 4.4. 425 Security considerations for the proposed experiments are dicussed in 426 the Internet-Drafts that propose them. 428 See Appendix B.1 of [I-D.briscoe-tsvwg-ecn-l4s-id] for discussion of 429 alteratives to the ECN Nonce. 431 10. References 433 10.1. Normative References 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, 437 DOI 10.17487/RFC2119, March 1997, 438 . 440 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 441 RFC 2914, DOI 10.17487/RFC2914, September 2000, 442 . 444 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 445 of Explicit Congestion Notification (ECN) to IP", 446 RFC 3168, DOI 10.17487/RFC3168, September 2001, 447 . 449 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 450 Congestion Notification (ECN) Signaling with Nonces", 451 RFC 3540, DOI 10.17487/RFC3540, June 2003, 452 . 454 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 455 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 456 Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 457 2006, . 459 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 460 Datagram Congestion Control Protocol (DCCP) Congestion 461 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 462 DOI 10.17487/RFC4342, March 2006, 463 . 465 [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 466 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate 467 Control for Small Packets (TFRC-SP)", RFC 5622, 468 DOI 10.17487/RFC5622, August 2009, 469 . 471 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 472 and K. Carlberg, "Explicit Congestion Notification (ECN) 473 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 474 2012, . 476 10.2. Informative References 478 [I-D.bagnulo-tsvwg-generalized-ecn] 479 Bagnulo, M. and B. Briscoe, "Adding Explicit Congestion 480 Notification (ECN) to TCP control packets", draft-bagnulo- 481 tsvwg-generalized-ecn-01 (work in progress), July 2016. 483 [I-D.briscoe-tsvwg-ecn-l4s-id] 484 Schepper, K., Briscoe, B., and I. Tsang, "Identifying 485 Modified Explicit Congestion Notification (ECN) Semantics 486 for Ultra-Low Queuing Delay", draft-briscoe-tsvwg-ecn-l4s- 487 id-01 (work in progress), March 2016. 489 [I-D.khademi-tcpm-alternativebackoff-ecn] 490 Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 491 "TCP Alternative Backoff with ECN (ABE)", draft-khademi- 492 tcpm-alternativebackoff-ecn-00 (work in progress), May 493 2016. 495 [I-D.khademi-tsvwg-ecn-response] 496 Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 497 "Updating the Explicit Congestion Notification (ECN) 498 Specification to Allow IETF Experimentation", draft- 499 khademi-tsvwg-ecn-response-01 (work in progress), July 500 2016. 502 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 503 Explicit Congestion Notification (ECN) Field", BCP 124, 504 RFC 4774, DOI 10.17487/RFC4774, November 2006, 505 . 507 [Trammell15] 508 Trammell, B., Kuehlewind, M., Boppart, D., Learmonth, I., 509 Fairhurst, G., and R. Scheffenegger, "Enabling Internet- 510 Wide Deployment of Explicit Congestion Notification". 512 In Proc Passive & Active Measurement (PAM'15) Conference 513 (2015) 515 Appendix A. Change History 517 [To be removed before RFC publication.] 519 Changes from draft-black-tsvwg-ecn-experimentation-00 to -01 521 o Section 4.2 - also update RFC 3168 to remove sentence indicating 522 that senders are free to use both ECT codepoints. Add a SHOULD 523 for ECT Differences experiments to use ECT(1). 525 o Section 5 - only discourage use of random ECT values, but use NOT 526 RECOMMENDED to do so. Consistent use of ECT(1) without using 527 ECT(0) is ok. Mention possible changes in endpoint response. 529 o Add more Acknowledgements and Change History 531 o Additional editorial changes. 533 Changes from draft-black-tsvwg-ecn-experimentation-01 to -02 535 o Add DCCP RFC updates and one missing RFC 3168 update (probe 536 packets). 538 o Discourage RTP usage of ECT(1). 540 o Strengthen text on lack of ECN Nonce deployment. 542 o Cross-reference the L4S draft appendix that discusses ECN Nonce 543 alternatives. 545 o Additional editorial changes. 547 Author's Address 549 David Black 550 Dell EMC 551 176 South Street 552 Hopkinton, MA 01748 553 USA 555 Email: david.black@dell.com