idnits 2.17.1 draft-ietf-tsvwg-ecn-experimentation-06.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. -- The draft header indicates that this document updates RFC6679, but the abstract doesn't seem to directly say this. It does mention RFC6679 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3168, updated by this document, for RFC5378 checks: 2000-11-17) -- The document seems to 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 (September 20, 2017) is 2409 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 (-12) exists of draft-ietf-tcpm-alternativebackoff-ecn-01 == Outdated reference: A later version (-29) exists of draft-ietf-tsvwg-ecn-l4s-id-00 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 6 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 Updates: 3168, 4341, 4342, 5622, 6679 September 20, 2017 5 (if approved) 6 Intended status: Standards Track 7 Expires: March 24, 2018 9 Explicit Congestion Notification (ECN) Experimentation 10 draft-ietf-tsvwg-ecn-experimentation-06 12 Abstract 14 This memo updates RFC 3168, which specifies Explicit Congestion 15 Notification (ECN) as a replacement for packet drops as indicators of 16 network congestion. It relaxes restrictions in RFC 3168 that would 17 otherwise hinder experimentation towards benefits beyond just removal 18 of loss. This memo summarizes the anticipated areas of 19 experimentation and updates RFC 3168 to enable experimentation in 20 these areas. An Experimental RFC is required to take advantage of 21 any of these enabling updates. In addition, this memo makes related 22 updates to the ECN specifications for RTP in RFC 6679 and for DCCP in 23 RFC 4341, RFC 4342 and RFC 5622. This memo also records the 24 conclusion of the ECN nonce experiment in RFC 3540, and provides the 25 rationale for reclassification of RFC 3540 as Historic; this 26 reclassification enables new experimental use of the ECT(1) 27 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 https://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 March 24, 2018. 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 (https://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. ECN Terminology . . . . . . . . . . . . . . . . . . . . . 3 77 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 78 2. Proposed ECN Experiments: Background . . . . . . . . . . . . 4 79 3. ECN Nonce and RFC 3540 . . . . . . . . . . . . . . . . . . . 5 80 4. Updates to RFC 3168 . . . . . . . . . . . . . . . . . . . . . 6 81 4.1. Congestion Response Differences . . . . . . . . . . . . . 6 82 4.2. Congestion Marking Differences . . . . . . . . . . . . . 8 83 4.3. TCP Control Packets and Retransmissions . . . . . . . . . 10 84 4.4. Effective Congestion Control is Required . . . . . . . . 11 85 5. ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . . 12 86 6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 . . . . . . 13 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 92 10.2. Informative References . . . . . . . . . . . . . . . . . 15 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 95 1. Introduction 97 This memo updates RFC 3168 [RFC3168] which specifies Explicit 98 Congestion Notification (ECN) as a replacement for packet drops as 99 indicators of network congestion. It relaxes restrictions in RFC 100 3168 that would otherwise hinder experimentation towards benefits 101 beyond just removal of loss. This memo summarizes the proposed areas 102 of experimentation and updates RFC 3168 to enable experimentation in 103 these areas. An Experimental RFC MUST be published for any protocol 104 or mechanism that takes advantage of any of these enabling updates. 105 Putting all of these updates into a single document enables 106 experimentation to proceed without requiring a standards process 107 exception for each Experimental RFC that needs changes to RFC 3168, a 108 Proposed Standard RFC. 110 There is no need to make changes for protocols and mechanisms that 111 are documented in Standards Track RFCs, as any Standards Track RFC 112 can update RFC 3168 without needing a standards process exception. 114 In addition, this memo makes related updates to the ECN specification 115 for RTP [RFC6679] and for three DCCP profiles ([RFC4341], [RFC4342] 116 and [RFC5622]) for the same reason. Each experiment is still 117 required to be documented in one or more separate RFCs, but use of 118 Experimental RFCs for this purpose does not require a process 119 exception to modify any of these Proposed Standard RFCs when the 120 modification falls within the bounds established by this memo (RFC 121 5622 is an Experimental RFC; it is modified by this memo for 122 consistency with modifications to the other two DCCP RFCs). 124 Some of the anticipated experimentation includes use of the ECT(1) 125 codepoint that was dedicated to the ECN nonce experiment in RFC 3540 126 [RFC3540]. This memo records the conclusion of the ECN nonce 127 experiment and provides the explanation for reclassification of RFC 128 3540 as Historic in order to enable new experimental use of the 129 ECT(1) codepoint. 131 1.1. ECN Terminology 133 ECT: ECN-Capable Transport. One of the two codepoints ECT(0) or 134 ECT(1) in the ECN field [RFC3168] of the IP header (v4 or v6). An 135 ECN-capable sender sets one of these to indicate that both transport 136 end-points support ECN. 138 Not-ECT: The ECN codepoint set by senders that indicates that the 139 transport is not ECN-capable. 141 CE: Congestion Experienced. The ECN codepoint that an intermediate 142 node sets to indicate congestion. A node sets an increasing 143 proportion of ECT packets to CE as the level of congestion increases. 145 1.2. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in RFC 150 2119 [RFC2119]. 152 2. Proposed ECN Experiments: Background 154 Three areas of ECN experimentation are covered by this memo; the 155 cited Internet-Drafts should be consulted for the detailed goals and 156 rationale of each proposed experiment: 158 Congestion Response Differences: As discussed further in 159 Section 4.1, an ECN congestion indication communicates a higher 160 likelihood that a shorter queue exists at the network bottleneck 161 node by comparison to a packet drop that indicates congestion 162 [I-D.ietf-tcpm-alternativebackoff-ecn]. This difference suggests 163 that for congestion indicated by ECN, a different sender 164 congestion response (e.g., reduce the response so that the sender 165 backs off by a smaller amount) may be appropriate by comparison to 166 the sender response to congestion indicated by loss, e.g., as 167 proposed in [I-D.ietf-tcpm-alternativebackoff-ecn] and 168 [I-D.ietf-tsvwg-ecn-l4s-id] - the experiment in the latter draft 169 couples the backoff change to Congestion Marking Differences 170 changes (next bullet). This is at variance with RFC 3168's 171 requirement that a sender's congestion control response to ECN 172 congestion indications be the same as to drops. IETF approval, 173 e.g., via an Experimental RFC, is required for any sender 174 congestion response used in this area of experimentation. 176 Congestion Marking Differences: As discussed further in Section 4.2, 177 when taken to its limit, congestion marking at network nodes can 178 be configured to maintain very shallow queues in conjunction with 179 a different IETF-approved congestion response to congestion 180 indications (CE marks) at the sender, e.g., as proposed in 181 [I-D.ietf-tsvwg-ecn-l4s-id]. The traffic involved needs to be 182 identified by the senders to the network nodes in order to avoid 183 damage to other network traffic whose senders do not expect the 184 more frequent congestion marking used to maintain very shallow 185 queues. Use of different ECN codepoints, specifically ECT(0) and 186 ECT(1), is a promising means of traffic identification for this 187 purpose, but that technique is at variance with RFC 3168's 188 requirement that ECT(0)-marked traffic and ECT(1)-marked traffic 189 not receive different treatment in the network. 191 TCP Control Packets and Retransmissions: RFC 3168 limits the use of 192 ECN with TCP to data packets, excluding retransmissions. With the 193 successful deployment of ECN in large portions of the Internet, 194 there is interest in extending the benefits of ECN to TCP control 195 packets (e.g., SYNs) and retransmitted packets, e.g., as proposed 196 in [I-D.bagnulo-tcpm-generalized-ecn]. This is at variance with 197 RFC 3168's prohibition of use of ECN for TCP control packets and 198 retransmitted packets. 200 The scope of this memo is limited to these three areas of 201 experimentation. This memo expresses no view on the likely outcomes 202 of the proposed experiments and does not specify the experiments in 203 detail. Additional experiments in these areas are possible, e.g., on 204 use of ECN to support deployment of a protocol similar to DCTCP 205 [I-D.ietf-tcpm-dctcp] beyond DCTCP's current applicability that is 206 limited to data center environments. The purpose of this memo is to 207 remove constraints in standards track RFCs that stand in the way of 208 these areas of experimentation. 210 3. ECN Nonce and RFC 3540 212 As specified in RFC 3168, ECN uses two ECN Capable Transport (ECT) 213 codepoints to indicate that a packet supports ECN, ECT(0) and ECT(1), 214 with the second codepoint used to support ECN nonce functionality to 215 discourage receivers from exploiting ECN to improve their throughput 216 at the expense of other network users, as specified in experimental 217 RFC 3540 [RFC3540]. This section explains why RFC 3540 is being 218 reclassified as Historic and makes associated updates to RFC 3168. 220 While the ECN nonce works as specified, and has been deployed in 221 limited environments, widespread usage in the Internet has not 222 materialized. A study of the ECN behaviour of the top one million 223 web servers using 2014 data [Trammell15] found that after ECN was 224 negotiated, none of the 581,711 IPv4 servers tested were using both 225 ECT codepoints, which would have been a possible sign of ECN nonce 226 usage. Of the 17,028 IPv6 servers tested, 4 set both ECT(0) and 227 ECT(1) on data packets. This might have been evidence of use of the 228 ECN nonce by these 4 servers, but might equally have been due to re- 229 marking of the ECN field by an erroneous middlebox or router. 231 With the emergence of new experimental functionality that depends on 232 use of the ECT(1) codepoint for other purposes, continuing to reserve 233 that codepoint for the ECN nonce experiment is no longer justified. 234 In addition, other approaches to discouraging receivers from 235 exploiting ECN have emerged, see Appendix B.1 of 237 [I-D.ietf-tsvwg-ecn-l4s-id]. Therefore, in support of ECN 238 experimentation with the ECT(1) codepoint, this memo: 240 o Declares that the ECN nonce experiment [RFC3540] has concluded, 241 and notes the absence of widespread deployment. 243 o Updates RFC 3168 [RFC3168] to remove discussion of the ECN nonce 244 and use of ECT(1) for that nonce. 246 The four primary updates to RFC 3168 that remove discussion of the 247 ECN nonce and use of ECT(1) for that nonce are: 249 1. Remove the paragraph in Section 5 that immediately follows 250 Figure 1; this paragraph discusses the ECN nonce as the 251 motivation for two ECT codepoints. 253 2. Remove Section 11.2 "A Discussion of the ECN nonce." in its 254 entirety. 256 3. Remove the last paragraph of Section 12, which states that ECT(1) 257 may be used as part of the implementation of the ECN nonce. 259 4. Remove the first two paragraphs of Section 20.2, which discuss 260 the ECN nonce and alternatives. No changes are made to the rest 261 of Section 20.2, which discusses alternate uses for the fourth 262 ECN codepoint. 264 Additional minor changes remove other mentions of the ECN nonce and 265 implications that ECT(1) is intended for use by the ECN nonce; the 266 specific text updates are omitted for brevity. 268 4. Updates to RFC 3168 270 The following subsections specify updates to RFC 3168 to enable the 271 three areas of experimentation summarized in Section 2. 273 4.1. Congestion Response Differences 275 RFC 3168 specifies that senders respond identically to packet drops 276 and ECN congestion indications. ECN congestion indications are 277 predominately originated by Active Queue Management (AQM) mechanisms 278 in intermediate buffers. AQM mechanisms are usually configured to 279 maintain shorter queue lengths than non-AQM based mechanisms, 280 particularly non-AQM drop-based mechanisms such as tail-drop, as AQM 281 mechanisms indicate congestion before the queue overflows. While the 282 occurrence of loss does not easily enable the receiver to determine 283 if AQM is used, the receipt of an ECN Congestion Experienced (CE) 284 mark conveys a strong likelihood that AQM was used to manage the 285 bottleneck queue. Hence an ECN congestion indication communicates a 286 higher likelihood that a shorter queue exists at the network 287 bottleneck node by comparison to a packet drop that indicates 288 congestion [I-D.ietf-tcpm-alternativebackoff-ecn]. This difference 289 suggests that for congestion indicated by ECN, a different sender 290 congestion response (e.g., reduce the response so that the sender 291 backs off by a smaller amount) may be appropriate by comparison to 292 the sender response to congestion indicated by loss. However, 293 section 5 of RFC 3168 specifies that: 295 Upon the receipt by an ECN-Capable transport of a single CE 296 packet, the congestion control algorithms followed at the end- 297 systems MUST be essentially the same as the congestion control 298 response to a *single* dropped packet. 300 This memo updates this RFC 3168 text to allow the congestion control 301 response (including the TCP Sender's congestion control response) to 302 a CE-marked packet to differ from the response to a dropped packet, 303 provided that the changes from RFC 3168 are documented in an 304 Experimental RFC. The specific change to RFC 3168 is to insert the 305 words "unless otherwise specified by an Experimental RFC" at the end 306 of the sentence quoted above. 308 RFC 4774 [RFC4774] quotes the above text from RFC 3168 as background, 309 but does not impose requirements based on that text. Therefore no 310 update to RFC 4774 is required to enable this area of 311 experimentation. 313 Section 6.1.2 of RFC 3168 specifies that: 315 If the sender receives an ECN-Echo (ECE) ACK packet (that is, an 316 ACK packet with the ECN-Echo flag set in the TCP header), then the 317 sender knows that congestion was encountered in the network on the 318 path from the sender to the receiver. The indication of 319 congestion should be treated just as a congestion loss in non- 320 ECN-Capable TCP. That is, the TCP source halves the congestion 321 window "cwnd" and reduces the slow start threshold "ssthresh". 323 This memo also updates this RFC 3168 text to allow the congestion 324 control response (including the TCP Sender's congestion control 325 response) to a CE-marked packet to differ from the response to a 326 dropped packet, provided that the changes from RFC 3168 are 327 documented in an Experimental RFC. The specific change to RFC 3168 328 is to insert the words "Unless otherwise specified by an Experimental 329 RFC" at the beginning of the second sentence quoted above. 331 4.2. Congestion Marking Differences 333 Taken to its limit, an AQM algorithm that uses ECN congestion 334 indications can be configured to maintain very shallow queues, 335 thereby reducing network latency by comparison to maintaining a 336 larger queue. Significantly more aggressive sender responses to ECN 337 are needed to make effective use of such very shallow queues; 338 Datacenter TCP (DCTCP) [I-D.ietf-tcpm-dctcp] provides an example. In 339 this case, separate network node treatments are essential, both to 340 prevent the aggressive low latency traffic starving conventional 341 traffic (if present) and to prevent any conventional traffic 342 disruption to any lower latency service that uses the very shallow 343 queues. Use of different ECN codepoints is a promising means of 344 identifying these two classes of traffic to network nodes, and hence 345 this area of experimentation is based on the use of the ECT(1) 346 codepoint to request ECN congestion marking behavior in the network 347 that differs from ECT(0) counterbalanced by use of a different IETF- 348 approved congestion response to CE marks at the sender, e.g., as 349 proposed in [I-D.ietf-tsvwg-ecn-l4s-id]. 351 Section 5 of RFC 3168 specifies that: 353 Routers treat the ECT(0) and ECT(1) codepoints as equivalent. 355 This memo updates RFC 3168 to allow routers to treat the ECT(0) and 356 ECT(1) codepoints differently, provided that the changes from RFC 357 3168 are documented in an Experimental RFC. The specific change to 358 RFC 3168 is to insert the words "unless otherwise specified by an 359 Experimental RFC" at the end of the above sentence. 361 When an AQM is configured to use ECN congestion indications to 362 maintain a very shallow queue, congestion indications are marked on 363 packets that would not have been dropped if ECN was not in use. 364 Section 5 of RFC 3168 specifies that: 366 For a router, the CE codepoint of an ECN-Capable packet SHOULD 367 only be set if the router would otherwise have dropped the packet 368 as an indication of congestion to the end nodes. When the 369 router's buffer is not yet full and the router is prepared to drop 370 a packet to inform end nodes of incipient congestion, the router 371 should first check to see if the ECT codepoint is set in that 372 packet's IP header. If so, then instead of dropping the packet, 373 the router MAY instead set the CE codepoint in the IP header. 375 This memo updates RFC 3168 to allow congestion indications that are 376 not equivalent to drops, provided that the changes from RFC 3168 are 377 documented in an Experimental RFC. The specific change is to change 378 "For a router," to "Unless otherwise specified by an Experimental 379 RFC" at the beginning of the first sentence of the above paragraph. 381 A larger update to RFC 3168 is necessary to enable sender usage of 382 ECT(1) to request network congestion marking behavior that maintains 383 very shallow queues at network nodes. When using loss as a 384 congestion signal, the number of signals provided should be reduced 385 to a minimum and hence only presence or absence of congestion is 386 communicated. In contrast, ECN can provide a richer signal, e.g., to 387 indicate the current level of congestion, without the disadvantage of 388 a larger number of packet losses. A proposed experiment in this 389 area, Low Latency Low Loss Scalable throughput (L4S) 390 [I-D.ietf-tsvwg-ecn-l4s-id] significantly increases the CE marking 391 probability for ECT(1)-marked traffic in a fashion that would 392 interact badly with existing sender congestion response functionality 393 because that functionality assumes that the network marks ECT packets 394 as frequently as it would drop Not-ECT packets. If network traffic 395 that uses such a conventional sender congestion response were to 396 encounter L4S's increased marking probability (and hence rate) at a 397 network bottleneck queue, the resulting traffic throughput is likely 398 to be much less than intended for the level of congestion at the 399 bottleneck queue. 401 To avoid that interaction, this memo reserves ECT(1) for 402 experimentation, initially for L4S. The specific update to Section 5 403 of RFC 3168 is to remove the following two paragraphs: 405 Senders are free to use either the ECT(0) or the ECT(1) codepoint 406 to indicate ECT, on a packet-by-packet basis. 408 The use of both the two codepoints for ECT, ECT(0) and ECT(1), is 409 motivated primarily by the desire to allow mechanisms for the data 410 sender to verify that network elements are not erasing the CE 411 codepoint, and that data receivers are properly reporting to the 412 sender the receipt of packets with the CE codepoint set, as 413 required by the transport protocol. Guidelines for the senders 414 and receivers to differentiate between the ECT(0) and ECT(1) 415 codepoints will be addressed in separate documents, for each 416 transport protocol. In particular, this document does not address 417 mechanisms for TCP end-nodes to differentiate between the ECT(0) 418 and ECT(1) codepoints. Protocols and senders that only require a 419 single ECT codepoint SHOULD use ECT(0). 421 and replace it with this paragraph: 423 Protocols and senders MUST use the ECT(0) codepoint to indicate 424 ECT unless otherwise specified by an Experimental RFC. Guidelines 425 for senders and receivers to differentiate between the ECT(0) and 426 ECT(1) codepoints will be addressed in separate documents, for 427 each transport protocol. In particular, this document does not 428 address mechanisms for TCP end-nodes to differentiate between the 429 ECT(0) and ECT(1) codepoints. 431 Congestion Marking Differences experiments SHOULD modify the network 432 behavior for ECT(1)-marked traffic rather than ECT(0)-marked traffic 433 if network behavior for only one ECT codepoint is modified. 434 Congestion Marking Differences experiments MUST NOT modify the 435 network behavior for ECT(0)-marked traffic in a fashion that requires 436 changes to sender congestion response to obtain desired network 437 behavior. If a Congestion Marking Differences experiment modifies 438 the network behavior for ECT(1)-marked traffic, e.g., CE-marking 439 behavior, in a fashion that requires changes to sender congestion 440 response to obtain desired network behavior, then the Experimental 441 RFC for that experiment MUST specify: 443 o The sender congestion response to CE marking in the network, and 445 o Router behavior changes, or the absence thereof, in forwarding CE- 446 marked packets that are part of the experiment. 448 In addition, until the conclusion of the L4S experiment, use of 449 ECT(1) in IETF RFCs is not appropriate, as the IETF may decide to 450 allocate ECT(1) exclusively for L4S usage if the L4S experiment is 451 successful. 453 In addition, this memo updates RFC 3168 to remove discussion of the 454 ECN nonce, as noted in Section 3 above. 456 4.3. TCP Control Packets and Retransmissions 458 With the successful use of ECN for traffic in large portions of the 459 Internet, there is interest in extending the benefits of ECN to TCP 460 control packets (e.g., SYNs) and retransmitted packets, e.g., as 461 proposed by ECN++ [I-D.bagnulo-tcpm-generalized-ecn]. 463 RFC 3168 prohibits use of ECN for TCP control packets and 464 retransmitted packets in a number of places: 466 o "To ensure the reliable delivery of the congestion indication of 467 the CE codepoint, an ECT codepoint MUST NOT be set in a packet 468 unless the loss of that packet in the network would be detected by 469 the end nodes and interpreted as an indication of congestion." 470 (Section 5.2) 472 o "A host MUST NOT set ECT on SYN or SYN-ACK packets." 473 (Section 6.1.1) 475 o "pure acknowledgement packets (e.g., packets that do not contain 476 any accompanying data) MUST be sent with the not-ECT codepoint." 477 (Section 6.1.4) 479 o "This document specifies ECN-capable TCP implementations MUST NOT 480 set either ECT codepoint (ECT(0) or ECT(1)) in the IP header for 481 retransmitted data packets, and that the TCP data receiver SHOULD 482 ignore the ECN field on arriving data packets that are outside of 483 the receiver's current window." (Section 6.1.5) 485 o "the TCP data sender MUST NOT set either an ECT codepoint or the 486 CWR bit on window probe packets." (Section 6.1.6) 488 This memo updates RFC 3168 to allow the use of ECT codepoints on SYN 489 and SYN-ACK packets, pure acknowledgement packets, window probe 490 packets and retransmissions of packets that were originally sent with 491 an ECT codepoint, provided that the changes from RFC 3168 are 492 documented in an Experimental RFC. The specific change to RFC 3168 493 is to insert the words "unless otherwise specified by an Experimental 494 RFC" at the end of each sentence quoted above. 496 In addition, beyond requiring TCP senders not to set ECT on TCP 497 control packets and retransmitted packets, RFC 3168 is silent on 498 whether it is appropriate for a network element, e.g. a firewall, to 499 discard such a packet as invalid. For this area of ECN 500 experimentation to be useful, middleboxes ought not to do that, 501 therefore RFC 3168 is updated by adding the following text to the end 502 of Section 6.1.1.1 on Middlebox Issues: 504 Unless otherwise specified by an Experimental RFC, middleboxes 505 SHOULD NOT discard TCP control packets and retransmitted TCP 506 packets solely because the ECN field in the IP header does not 507 contain Not-ECT. An exception to this requirement occurs in 508 responding to an ongoing attack. For example, as part of the 509 response, it may be appropriate to drop more ECT-marked TCP SYN 510 packets than TCP SYN packets marked with not-ECT. Any such 511 exceptional discarding of TCP control packets and retransmitted 512 TCP packets in response to an attack MUST NOT be done routinely in 513 the absence of an attack and SHOULD only be done if it is 514 determined that the ECT capability is contributing to the attack. 516 4.4. Effective Congestion Control is Required 518 Congestion control remains an important aspect of the Internet 519 architecture [RFC2914]. Any Experimental RFC that takes advantage of 520 this memo's updates to any RFC is required to discuss the congestion 521 control implications of the experiment(s) in order to provide 522 assurance that deployment of the experiment(s) does not pose a 523 congestion-based threat to the operation of the Internet. 525 5. ECN for RTP Updates to RFC 6679 527 RFC 6679 [RFC6679] specifies use of ECN for RTP traffic; it allows 528 use of both the ECT(0) and ECT(1) codepoints, and provides the 529 following guidance on use of these codepoints in section 7.3.1 : 531 The sender SHOULD mark packets as ECT(0) unless the receiver 532 expresses a preference for ECT(1) or for a random ECT value using 533 the "ect" parameter in the "a=ecn-capable-rtp:" attribute. 535 The Congestion Marking Differences area of experimentation increases 536 the potential consequences of using ECT(1) instead of ECT(0), and 537 hence the above guidance is updated by adding the following two 538 sentences: 540 Random ECT values MUST NOT be used, as that may expose RTP to 541 differences in network treatment of traffic marked with ECT(1) and 542 ECT(0) and differences in associated endpoint congestion 543 responses, e.g., as proposed in [I-D.ietf-tsvwg-ecn-l4s-id]. In 544 addition, ECT(0) MUST be used unless otherwise specified in an 545 Experimental RFC. 547 Section 7.3.3 of RFC 6679 specifies RTP's response to receipt of CE 548 marked packets as being identical to the response to dropped packets: 550 The reception of RTP packets with ECN-CE marks in the IP header is 551 a notification that congestion is being experienced. The default 552 reaction on the reception of these ECN-CE-marked packets MUST be 553 to provide the congestion control algorithm with a congestion 554 notification that triggers the algorithm to react as if packet 555 loss had occurred. There should be no difference in congestion 556 response if ECN-CE marks or packet drops are detected. 558 In support of Congestion Response Differences experimentation, this 559 memo updates this text in a fashion similar to RFC 3168 to allow the 560 RTP congestion control response to a CE-marked packet to differ from 561 the response to a dropped packet, provided that the changes from RFC 562 6679 are documented in an Experimental RFC. The specific change to 563 RFC 6679 is to insert the words "Unless otherwise specified by an 564 Experimental RFC" and reformat the last two sentences to be subject 565 to that condition, i.e.: 567 The reception of RTP packets with ECN-CE marks in the IP header is 568 a notification that congestion is being experienced. Unless 569 otherwise specified by an Experimental RFC: 571 * The default reaction on the reception of these ECN-CE-marked 572 packets MUST be to provide the congestion control algorithm 573 with a congestion notification that triggers the algorithm to 574 react as if packet loss had occurred. 576 * There should be no difference in congestion response if ECN-CE 577 marks or packet drops are detected. 579 The second sentence of the immediately following paragraph in RFC 580 6679 requires a related update: 582 Other reactions to ECN-CE may be specified in the future, 583 following IETF Review. Detailed designs of such additional 584 reactions MUST be specified in a Standards Track RFC and be 585 reviewed to ensure they are safe for deployment under any 586 restrictions specified. 588 The update is to change "Standards Track RFC" to "Standards Track RFC 589 or Experimental RFC" for consistency with the first update. 591 6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 593 The specifications of the three DCCP Congestion Control IDs (CCIDs) 2 594 [RFC4341], 3 [RFC4342] and 4 [RFC5622] contain broadly the same 595 wording as follows: 597 each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable with 598 either the ECT(0) or the ECT(1) codepoint set. 600 This memo updates these sentences in each of the three RFCs as 601 follows: 603 each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable. 604 Unless otherwise specified by an Experimental RFC, such DCCP 605 senders MUST set the ECT(0) codepoint. 607 In support of Congestion Marking Differences experimentation (as 608 noted in Section 3), this memo also updates all three of these RFCs 609 to remove discussion of the ECN nonce. The specific text updates are 610 omitted for brevity. 612 7. Acknowledgements 614 The content of this draft, including the specific portions of RFC 615 3168 that are updated draws heavily from 616 [I-D.khademi-tsvwg-ecn-response], whose authors are gratefully 617 acknowledged. The authors of the Internet Drafts describing the 618 experiments have motivated the production of this memo - their 619 interest in innovation is welcome and heartily acknowledged. Colin 620 Perkins suggested updating RFC 6679 on RTP and provided guidance on 621 where to make the updates. 623 The draft has been improved as a result of comments from a number of 624 reviewers, including Brian Carpenter, Spencer Dawkins, Gorry 625 Fairhurst, Ingemar Johansson, Naeem Khademi, Mirja Kuehlewind, Karen 626 Nielsen, Hilarie Orman and Michael Welzl. Bob Briscoe's thorough 627 review of an early version of this draft resulted in numerous 628 improvements including addition of the updates to the DCCP RFCs. 630 8. IANA Considerations 632 To reflect the reclassification of RFC 3540 as Historic, IANA is 633 requested to update the Transmission Control Protocol (TCP) Header 634 Flags registry (https://www.iana.org/assignments/tcp-header-flags/ 635 tcp-header-flags.xhtml#tcp-header-flags-1) to remove the registration 636 of bit 7 as the NS (Nonce Sum) bit and add an annotation to the 637 registry to state that bit 7 was used by Historic RFC 3540 as the NS 638 (Nonce Sum) bit. 640 9. Security Considerations 642 As a process memo that only removes limitations on proposed 643 experiments, there are no protocol security considerations. Security 644 considerations for the proposed experiments are discussed in the 645 Internet-Drafts that propose them. 647 However, effective congestion control is crucial to the continued 648 operation of the Internet, and hence this memo places the 649 responsibility for not breaking Internet congestion control on the 650 experiments and the experimenters who propose them. This 651 responsibility includes the requirement to discuss congestion control 652 implications in an Experimental RFC for each experiment, as stated in 653 Section 4.4; review of that discussion by the IETF community and the 654 IESG prior to RFC publication is intended to provide assurance that 655 each experiment does not break Internet congestion control. 657 See Appendix B.1 of [I-D.ietf-tsvwg-ecn-l4s-id] for discussion of 658 alternatives to the ECN nonce. 660 10. References 662 10.1. Normative References 664 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 665 Requirement Levels", BCP 14, RFC 2119, 666 DOI 10.17487/RFC2119, March 1997, 667 . 669 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 670 RFC 2914, DOI 10.17487/RFC2914, September 2000, 671 . 673 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 674 of Explicit Congestion Notification (ECN) to IP", 675 RFC 3168, DOI 10.17487/RFC3168, September 2001, 676 . 678 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 679 Congestion Notification (ECN) Signaling with Nonces", 680 RFC 3540, DOI 10.17487/RFC3540, June 2003, 681 . 683 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 684 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 685 Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 686 2006, . 688 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 689 Datagram Congestion Control Protocol (DCCP) Congestion 690 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 691 DOI 10.17487/RFC4342, March 2006, 692 . 694 [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 695 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate 696 Control for Small Packets (TFRC-SP)", RFC 5622, 697 DOI 10.17487/RFC5622, August 2009, 698 . 700 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 701 and K. Carlberg, "Explicit Congestion Notification (ECN) 702 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 703 2012, . 705 10.2. Informative References 707 [I-D.bagnulo-tcpm-generalized-ecn] 708 Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit 709 Congestion Notification (ECN) to TCP Control Packets", 710 draft-bagnulo-tcpm-generalized-ecn-04 (work in progress), 711 May 2017. 713 [I-D.ietf-tcpm-alternativebackoff-ecn] 714 Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 715 "TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm- 716 alternativebackoff-ecn-01 (work in progress), May 2017. 718 [I-D.ietf-tcpm-dctcp] 719 Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., 720 and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion 721 Control for Datacenters", draft-ietf-tcpm-dctcp-10 (work 722 in progress), August 2017. 724 [I-D.ietf-tsvwg-ecn-l4s-id] 725 Schepper, K. and B. Briscoe, "Identifying Modified 726 Explicit Congestion Notification (ECN) Semantics for 727 Ultra-Low Queuing Delay", draft-ietf-tsvwg-ecn-l4s-id-00 728 (work in progress), May 2017. 730 [I-D.khademi-tsvwg-ecn-response] 731 Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 732 "Updating the Explicit Congestion Notification (ECN) 733 Specification to Allow IETF Experimentation", draft- 734 khademi-tsvwg-ecn-response-01 (work in progress), July 735 2016. 737 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 738 Explicit Congestion Notification (ECN) Field", BCP 124, 739 RFC 4774, DOI 10.17487/RFC4774, November 2006, 740 . 742 [Trammell15] 743 Trammell, B., Kuehlewind, M., Boppart, D., Learmonth, I., 744 Fairhurst, G., and R. Scheffenegger, "Enabling Internet- 745 Wide Deployment of Explicit Congestion Notification". 747 In Proc Passive & Active Measurement (PAM'15) Conference 748 (2015) 750 Appendix A. Change History 752 [To be removed before RFC publication.] 754 Changes from draft-ietf-tsvwg-ecn-experimentation-00 to -01: 756 o Add mention of DCTCP as another protocol that could benefit from 757 ECN experimentation (near end of Section 2). 759 Changes from draft-ietf-tsvwg-ecn-experimentation-01 to -02: 761 o Generalize to describe rationale for areas of experimentation, 762 with less focus on individual experiments 764 o Add ECN terminology section 766 o Change name of "ECT Differences" experimentation area to 767 "Congestion Marking Differences" 769 o Add overlooked RFC 3168 modification to Section 4.1 771 o Clarify text for Experimental RFC exception to ECT(1) non-usage 772 requirement 774 o Add explanation of exception to "SHOULD NOT drop" requirement in 775 4.3 777 o Rework RFC 3540 status change text to provide rationale for a 778 separate status change document that makes RFC 3540 Historic. 779 Don't obsolete RFC 3540. 781 o Significant editorial changes based on reviews by Mirja 782 Kuehlewind, Michael Welzl and Bob Briscoe. 784 Changes from draft-ietf-tsvwg-ecn-experimentation-02 to -03: 786 o Remove change history prior to WG adoption. 788 o Update L4S draft reference to reflect TSVWG adoption of draft. 790 o Change the "SHOULD" for DCCP sender use of ECT(0) to a "MUST" 791 (overlooked in earlier editing). 793 o Other minor edits. 795 Changes from draft-ietf-tsvwg-ecn-experimentation-03 to -04: 797 o Change name of "Generalized ECN" experimentation area to "TCP 798 Control Packets and Retransmissions." 800 o Add IANA Considerations text to request removal of the 801 registration of the NS bit in the TCP header. 803 Changes from draft-ietf-tsvwg-ecn-experimentation-04 to -05: 805 o Minor editorial changes from Area Director review 807 Changes from draft-ietf-tsvwg-ecn-experimentation-05 to -06: 809 o Add summary of RFC 3168 changes to remove the ECN nonce, and use 810 lower-case "nonce" instead of "Nonce" to match RFC 3168 usage. 812 o Add security considerations sentence to indicate that review of 813 Experimental RFCs prior to publication approval is the means to 814 ensure that congestion control is not broken by experiments. 816 o Other minor editorial changes from IETF Last Call 818 Author's Address 820 David Black 821 Dell EMC 822 176 South Street 823 Hopkinton, MA 01748 824 USA 826 Email: david.black@dell.com