idnits 2.17.1 draft-ietf-tsvwg-ecn-experimentation-08.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 (November 13, 2017) is 2355 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-03 == Outdated reference: A later version (-07) exists of draft-ietf-trill-ecn-support-03 == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-ecn-encap-guidelines-09 == Outdated reference: A later version (-29) exists of draft-ietf-tsvwg-ecn-l4s-id-01 == Outdated reference: A later version (-23) exists of draft-ietf-tsvwg-rfc6040update-shim-05 -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 7 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 November 13, 2017 5 (if approved) 6 Intended status: Standards Track 7 Expires: May 17, 2018 9 Relaxing Restrictions on Explicit Congestion Notification (ECN) 10 Experimentation 11 draft-ietf-tsvwg-ecn-experimentation-08 13 Abstract 15 This memo updates RFC 3168, which specifies Explicit Congestion 16 Notification (ECN) as an alternative to packet drops for indicating 17 network congestion to endpoints. It relaxes restrictions in RFC 3168 18 that hinder experimentation towards benefits beyond just removal of 19 loss. This memo summarizes the anticipated areas of experimentation 20 and updates RFC 3168 to enable experimentation in these areas. An 21 Experimental RFC in the IETF document stream is required to take 22 advantage of any of these enabling updates. In addition, this memo 23 makes related updates to the ECN specifications for RTP in RFC 6679 24 and for DCCP in RFC 4341, RFC 4342 and RFC 5622. This memo also 25 records the conclusion of the ECN nonce experiment in RFC 3540, and 26 provides the rationale for reclassification of RFC 3540 as Historic; 27 this reclassification enables new experimental use of the ECT(1) 28 codepoint. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 17, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.1. ECN Terminology . . . . . . . . . . . . . . . . . . . . . 3 78 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 79 2. ECN Experimentation: Overview . . . . . . . . . . . . . . . . 4 80 2.1. Effective Congestion Control is Required . . . . . . . . 5 81 2.2. Network Considerations for ECN Experimentation . . . . . 5 82 2.3. Operational and Management Considerations . . . . . . . . 6 83 3. ECN Nonce and RFC 3540 . . . . . . . . . . . . . . . . . . . 7 84 4. Updates to RFC 3168 . . . . . . . . . . . . . . . . . . . . . 8 85 4.1. Congestion Response Differences . . . . . . . . . . . . . 8 86 4.2. Congestion Marking Differences . . . . . . . . . . . . . 9 87 4.3. TCP Control Packets and Retransmissions . . . . . . . . . 12 88 5. ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . . 13 89 6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 . . . . . . 15 90 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 95 10.2. Informative References . . . . . . . . . . . . . . . . . 17 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 98 1. Introduction 100 This memo updates RFC 3168 [RFC3168] which specifies Explicit 101 Congestion Notification (ECN) as an alternative to packet drops for 102 indicating network congestion to endpoints. It relaxes restrictions 103 in RFC 3168 that hinder experimentation towards benefits beyond just 104 removal of loss. This memo summarizes the proposed areas of 105 experimentation and updates RFC 3168 to enable experimentation in 106 these areas. An Experimental RFC in the IETF document stream 107 [RFC4844] is required to take advantage of any of these enabling 108 updates. Putting all of these updates into a single document enables 109 experimentation to proceed without requiring a standards process 110 exception for each Experimental RFC that needs changes to RFC 3168, a 111 Proposed Standard RFC. 113 There is no need for this memo to update RFC 3168 to simplify 114 standardization of protocols and mechanisms that are documented in 115 Standards Track RFCs, as any Standards Track RFC can update RFC 3168 116 directly without either relying on updates in this memo or using a 117 standards process exception. 119 In addition, this memo makes related updates to the ECN specification 120 for RTP [RFC6679] and for three DCCP profiles ([RFC4341], [RFC4342] 121 and [RFC5622]) for the same reason. Each experiment is still 122 required to be documented in one or more separate RFCs, but use of 123 Experimental RFCs for this purpose does not require a process 124 exception to modify any of these Proposed Standard RFCs when the 125 modification falls within the bounds established by this memo (RFC 126 5622 is an Experimental RFC; it is modified by this memo for 127 consistency with modifications to the other two DCCP RFCs). 129 Some of the anticipated experimentation includes use of the ECT(1) 130 codepoint that was dedicated to the ECN nonce experiment in RFC 3540 131 [RFC3540]. This memo records the conclusion of the ECN nonce 132 experiment and provides the explanation for reclassification of RFC 133 3540 as Historic in order to enable new experimental use of the 134 ECT(1) codepoint. 136 1.1. ECN Terminology 138 ECT: ECN-Capable Transport. One of the two codepoints ECT(0) or 139 ECT(1) in the ECN field [RFC3168] of the IP header (v4 or v6). An 140 ECN-capable sender sets one of these to indicate that both transport 141 end-points support ECN. 143 Not-ECT: The ECN codepoint set by senders that indicates that the 144 transport is not ECN-capable. 146 CE: Congestion Experienced. The ECN codepoint that an intermediate 147 node sets to indicate congestion. A node sets an increasing 148 proportion of ECT packets to CE as the level of congestion increases. 150 1.2. Requirements Language 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in RFC 155 2119 [RFC2119]. 157 2. ECN Experimentation: Overview 159 Three areas of ECN experimentation are covered by this memo; the 160 cited Internet-Drafts should be consulted for the detailed goals and 161 rationale of each proposed experiment: 163 Congestion Response Differences: An ECN congestion indication 164 communicates a higher likelihood than a dropped packet that a 165 short queue exists at the network bottleneck node 166 [I-D.ietf-tcpm-alternativebackoff-ecn]. This difference suggests 167 that for congestion indicated by ECN, a different sender 168 congestion response (e.g., sender backs off by a smaller amount) 169 may be appropriate by comparison to the sender response to 170 congestion indicated by loss. Two examples of proposed sender 171 congestion response changes are described in 172 [I-D.ietf-tcpm-alternativebackoff-ecn] and 173 [I-D.ietf-tsvwg-ecn-l4s-id] - the proposal in the latter draft 174 couples the sender congestion response change to Congestion 175 Marking Differences functionality (see next paragraph). These 176 changes are at variance with RFC 3168's requirement that a 177 sender's congestion control response to ECN congestion indications 178 be the same as to drops. IETF approval, e.g., via an Experimental 179 RFC in the IETF document stream, is required for any sender 180 congestion response used in this area of experimentation. See 181 Section 4.1 for further discussion. 183 Congestion Marking Differences: Congestion marking at network nodes 184 can be configured to maintain very shallow queues in conjunction 185 with a different sender response to congestion indications (CE 186 marks), e.g., as proposed in [I-D.ietf-tsvwg-ecn-l4s-id]. The 187 traffic involved needs to be identified by the senders to the 188 network nodes in order to avoid damage to other network traffic 189 whose senders do not expect the more frequent congestion marking 190 used to maintain very shallow queues. Use of different ECN 191 codepoints, specifically ECT(0) and ECT(1), is a promising means 192 of traffic identification for this purpose, but that technique is 193 at variance with RFC 3168's requirement that ECT(0)-marked traffic 194 and ECT(1)-marked traffic not receive different treatment in the 195 network. IETF approval, e.g., via an Experimental RFC in the IETF 196 document stream, is required for any differences in congestion 197 marking or sender congestion response used in this area of 198 experimentation. See Section 4.2 for further discussion. 200 TCP Control Packets and Retransmissions: RFC 3168 limits the use of 201 ECN with TCP to data packets, excluding retransmissions. With the 202 successful deployment of ECN in large portions of the Internet, 203 there is interest in extending the benefits of ECN to TCP control 204 packets (e.g., SYNs) and retransmitted packets, e.g., as proposed 205 in [I-D.bagnulo-tcpm-generalized-ecn]. This is at variance with 206 RFC 3168's prohibition of use of ECN for TCP control packets and 207 retransmitted packets. See Section 4.3 for further discussion. 209 The scope of this memo is limited to these three areas of 210 experimentation. This memo expresses no view on the likely outcomes 211 of the proposed experiments and does not specify the experiments in 212 detail. Additional experiments in these areas are possible, e.g., on 213 use of ECN to support deployment of a protocol similar to DCTCP 214 [I-D.ietf-tcpm-dctcp] beyond DCTCP's current applicability that is 215 limited to data center environments. The purpose of this memo is to 216 remove constraints in standards track RFCs that stand in the way of 217 these areas of experimentation. 219 2.1. Effective Congestion Control is Required 221 Congestion control remains an important aspect of the Internet 222 architecture [RFC2914]. Any Experimental RFC in the IETF document 223 stream that takes advantage of this memo's updates to any RFC is 224 required to discuss the congestion control implications of the 225 experiment(s) in order to provide assurance that deployment of the 226 experiment(s) does not pose a congestion-based threat to the 227 operation of the Internet. 229 2.2. Network Considerations for ECN Experimentation 231 ECN functionality [RFC3168] is becoming widely deployed in the 232 Internet and is being designed into additional protocols such as 233 TRILL [I-D.ietf-trill-ecn-support]. ECN experiments are expected to 234 coexist with deployed ECN functionality, with the responsibility for 235 that coexistence falling primarily upon designers of experimental 236 changes to ECN. In addition, protocol designers and implementers, as 237 well as network operators, may desire to anticipate and/or support 238 ECN experiments. The following guidelines will help avoid conflicts 239 with the areas of ECN experimentation enabled by this memo: 241 1. RFC 3168's forwarding behavior remains the preferred approach for 242 routers that are not involved in ECN experiments, in particular 243 continuing to treat the ECT(0) and ECT(1) codepoints as 244 equivalent, as specified in Section 4.2 below. 246 2. Network nodes that forward packets SHOULD NOT assume that the ECN 247 CE codepoint indicates that the packet would have been dropped if 248 ECN were not in use. This is because Congestion Response 249 Differences experiments employ different congestion responses to 250 dropped packets by comparison to receipt of CE-marked packets 251 (see Section 4.1 below), so CE-marked packets SHOULD NOT be 252 arbitrarily dropped. A corresponding difference in congestion 253 responses already occurs when the ECN field is used for Pre- 254 Congestion Notification (PCN) [RFC6660]. 256 3. A network node MUST NOT originate traffic marked with ECT(1) 257 unless the network node is participating in a Congestion Marking 258 Differences experiment that uses ECT(1), as specified in 259 Section 4.2 below. 261 Some ECN experiments use ECN with packets where it has not been used 262 previously, specifically TCP control packets and retransmissions, see 263 Section 4.3 below, and in particular its new requirements for 264 middlebox behavior. In general, any system or protocol that inspects 265 or monitors network traffic SHOULD be prepared to encounter ECN usage 266 on packets and traffic that currently do not use ECN. 268 ECN field handling requirements for tunnel encapsulation and 269 decapsulation are specified in [RFC6040] which is in the process of 270 being updated by [I-D.ietf-tsvwg-rfc6040update-shim]. Related 271 guidance for encapsulations whose outer headers are not IP headers 272 can be found in [I-D.ietf-tsvwg-ecn-encap-guidelines]. These 273 requirements and guidance apply to all traffic, including traffic 274 that is part of any ECN experiment. 276 2.3. Operational and Management Considerations 278 Changes in network traffic behavior that result from ECN 279 experimentation are likely to impact network operations and 280 management. Designers of ECN experiments are expected to anticipate 281 possible impacts and consider how they may be dealt with. Specific 282 topics to consider include possible network management changes or 283 extensions, monitoring of the experimental deployment, collection of 284 data for evaluation of the experiment and possible interactions with 285 other protocols, particularly protocols that encapsulate network 286 traffic. 288 For further discussion, see [RFC5706]; the questions in Appendix A of 289 RFC 5706 provide a concise survey of some important aspects to 290 consider. 292 3. ECN Nonce and RFC 3540 294 As specified in RFC 3168, ECN uses two ECN Capable Transport (ECT) 295 codepoints to indicate that a packet supports ECN, ECT(0) and ECT(1). 296 RFC 3168 assigned the second codepoint, ECT(1), to support ECN nonce 297 functionality that discourages receivers from exploiting ECN to 298 improve their throughput at the expense of other network users. That 299 ECN nonce functionality is fully specified in Experimental RFC 3540 300 [RFC3540]. This section explains why RFC 3540 is being reclassified 301 as Historic and makes associated updates to RFC 3168. 303 While the ECN nonce works as specified, and has been deployed in 304 limited environments, widespread usage in the Internet has not 305 materialized. A study of the ECN behaviour of the top one million 306 web servers using 2014 data [Trammell15] found that after ECN was 307 negotiated, none of the 581,711 IPv4 servers tested were using both 308 ECT codepoints, which would have been a possible sign of ECN nonce 309 usage. Of the 17,028 IPv6 servers tested, 4 set both ECT(0) and 310 ECT(1) on data packets. This might have been evidence of use of the 311 ECN nonce by these 4 servers, but might equally have been due to 312 erroneous re-marking of the ECN field by a middlebox or router. 314 With the emergence of new experimental functionality that depends on 315 use of the ECT(1) codepoint for other purposes, continuing to reserve 316 that codepoint for the ECN nonce experiment is no longer justified. 317 In addition, other approaches to discouraging receivers from 318 exploiting ECN have emerged, see Appendix B.1 of 319 [I-D.ietf-tsvwg-ecn-l4s-id]. Therefore, in support of ECN 320 experimentation with the ECT(1) codepoint, this memo: 322 o Declares that the ECN nonce experiment [RFC3540] has concluded, 323 and notes the absence of widespread deployment. 325 o Updates RFC 3168 [RFC3168] to remove discussion of the ECN nonce 326 and use of ECT(1) for that nonce. 328 The four primary updates to RFC 3168 that remove discussion of the 329 ECN nonce and use of ECT(1) for that nonce are: 331 1. Remove the paragraph in Section 5 that immediately follows 332 Figure 1; this paragraph discusses the ECN nonce as the 333 motivation for two ECT codepoints. 335 2. Remove Section 11.2 "A Discussion of the ECN nonce." in its 336 entirety. 338 3. Remove the last paragraph of Section 12, which states that ECT(1) 339 may be used as part of the implementation of the ECN nonce. 341 4. Remove the first two paragraphs of Section 20.2, which discuss 342 the ECN nonce and alternatives. No changes are made to the rest 343 of Section 20.2, which discusses alternative uses for the fourth 344 ECN codepoint. 346 In addition, other less substantive RFC 3168 changes are required to 347 remove all other mentions of the ECN nonce and to remove implications 348 that ECT(1) is intended for use by the ECN nonce; these specific text 349 updates are omitted for brevity. 351 4. Updates to RFC 3168 353 The following subsections specify updates to RFC 3168 to enable the 354 three areas of experimentation summarized in Section 2. 356 4.1. Congestion Response Differences 358 RFC 3168 specifies that senders respond identically to packet drops 359 and ECN congestion indications. ECN congestion indications are 360 predominately originated by Active Queue Management (AQM) mechanisms 361 in intermediate buffers. AQM mechanisms are usually configured to 362 maintain shorter queue lengths than non-AQM based mechanisms, 363 particularly non-AQM drop-based mechanisms such as tail-drop, as AQM 364 mechanisms indicate congestion before the queue overflows. While the 365 occurrence of loss does not easily enable the receiver to determine 366 if AQM is used, the receipt of an ECN Congestion Experienced (CE) 367 mark conveys a strong likelihood that AQM was used to manage the 368 bottleneck queue. Hence an ECN congestion indication communicates a 369 higher likelihood than a dropped packet that a short queue exists at 370 the network bottleneck node [I-D.ietf-tcpm-alternativebackoff-ecn]. 371 This difference suggests that for congestion indicated by ECN, a 372 different sender congestion response (e.g., sender backs off by a 373 smaller amount) may be appropriate by comparison to the sender 374 response to congestion indicated by loss. However, section 5 of RFC 375 3168 specifies that: 377 Upon the receipt by an ECN-Capable transport of a single CE 378 packet, the congestion control algorithms followed at the end- 379 systems MUST be essentially the same as the congestion control 380 response to a *single* dropped packet. 382 This memo updates this RFC 3168 text to allow the congestion control 383 response (including the TCP Sender's congestion control response) to 384 a CE-marked packet to differ from the response to a dropped packet, 385 provided that the changes from RFC 3168 are documented in an 386 Experimental RFC in the IETF document stream. The specific change to 387 RFC 3168 is to insert the words "unless otherwise specified by an 388 Experimental RFC in the IETF document stream" at the end of the 389 sentence quoted above. 391 RFC 4774 [RFC4774] quotes the above text from RFC 3168 as background, 392 but does not impose requirements based on that text. Therefore no 393 update to RFC 4774 is required to enable this area of 394 experimentation. 396 Section 6.1.2 of RFC 3168 specifies that: 398 If the sender receives an ECN-Echo (ECE) ACK packet (that is, an 399 ACK packet with the ECN-Echo flag set in the TCP header), then the 400 sender knows that congestion was encountered in the network on the 401 path from the sender to the receiver. The indication of 402 congestion should be treated just as a congestion loss in non- 403 ECN-Capable TCP. That is, the TCP source halves the congestion 404 window "cwnd" and reduces the slow start threshold "ssthresh". 406 This memo also updates this RFC 3168 text to allow the congestion 407 control response (including the TCP Sender's congestion control 408 response) to a CE-marked packet to differ from the response to a 409 dropped packet, provided that the changes from RFC 3168 are 410 documented in an Experimental RFC in the IETF document stream. The 411 specific change to RFC 3168 is to insert the words "Unless otherwise 412 specified by an Experimental RFC in the IETF document stream" at the 413 beginning of the second sentence quoted above. 415 4.2. Congestion Marking Differences 417 Taken to its limit, an AQM algorithm that uses ECN congestion 418 indications can be configured to maintain very shallow queues, 419 thereby reducing network latency by comparison to maintaining a 420 larger queue. Significantly more aggressive sender responses to ECN 421 are needed to make effective use of such very shallow queues; 422 Datacenter TCP (DCTCP) [I-D.ietf-tcpm-dctcp] provides an example. In 423 this case, separate network node treatments are essential, both to 424 prevent the aggressive low latency traffic from starving conventional 425 traffic (if present) and to prevent any conventional traffic 426 disruption to any lower latency service that uses the very shallow 427 queues. Use of different ECN codepoints is a promising means of 428 identifying these two classes of traffic to network nodes, and hence 429 this area of experimentation is based on the use of the ECT(1) 430 codepoint to request ECN congestion marking behavior in the network 431 that differs from ECT(0). It is essential that any such change in 432 ECN congestion marking behavior be counterbalanced by use of a 433 different IETF-approved congestion response to CE marks at the 434 sender, e.g., as proposed in [I-D.ietf-tsvwg-ecn-l4s-id]. 436 Section 5 of RFC 3168 specifies that: 438 Routers treat the ECT(0) and ECT(1) codepoints as equivalent. 440 This memo updates RFC 3168 to allow routers to treat the ECT(0) and 441 ECT(1) codepoints differently, provided that the changes from RFC 442 3168 are documented in an Experimental RFC in the IETF document 443 stream. The specific change to RFC 3168 is to insert the words 444 "unless otherwise specified by an Experimental RFC in the IETF 445 document stream" at the end of the above sentence. 447 When an AQM is configured to use ECN congestion indications to 448 maintain a very shallow queue, congestion indications are marked on 449 packets that would not have been dropped if ECN was not in use. 450 Section 5 of RFC 3168 specifies that: 452 For a router, the CE codepoint of an ECN-Capable packet SHOULD 453 only be set if the router would otherwise have dropped the packet 454 as an indication of congestion to the end nodes. When the 455 router's buffer is not yet full and the router is prepared to drop 456 a packet to inform end nodes of incipient congestion, the router 457 should first check to see if the ECT codepoint is set in that 458 packet's IP header. If so, then instead of dropping the packet, 459 the router MAY instead set the CE codepoint in the IP header. 461 This memo updates RFC 3168 to allow congestion indications that are 462 not equivalent to drops, provided that the changes from RFC 3168 are 463 documented in an Experimental RFC in the IETF document stream. The 464 specific change is to change "For a router," to "Unless otherwise 465 specified by an Experimental RFC in the IETF document stream" at the 466 beginning of the first sentence of the above paragraph. 468 A larger update to RFC 3168 is necessary to enable sender usage of 469 ECT(1) to request network congestion marking behavior that maintains 470 very shallow queues at network nodes. When using loss as a 471 congestion signal, the number of signals provided should be reduced 472 to a minimum and hence only presence or absence of congestion is 473 communicated. In contrast, ECN can provide a richer signal, e.g., to 474 indicate the current level of congestion, without the disadvantage of 475 a larger number of packet losses. A proposed experiment in this 476 area, Low Latency Low Loss Scalable throughput (L4S) 477 [I-D.ietf-tsvwg-ecn-l4s-id] significantly increases the CE marking 478 probability for ECT(1)-marked traffic in a fashion that would 479 interact badly with existing sender congestion response functionality 480 because that functionality assumes that the network marks ECT packets 481 as frequently as it would drop Not-ECT packets. If network traffic 482 that uses such a conventional sender congestion response were to 483 encounter L4S's increased marking probability (and hence rate) at a 484 network bottleneck queue, the resulting traffic throughput is likely 485 to be much less than intended for the level of congestion at the 486 bottleneck queue. 488 This memo updates RFC 3168 to remove that interaction for ECT(1). 489 The specific update to Section 5 of RFC 3168 is to replace the 490 following two paragraphs: 492 Senders are free to use either the ECT(0) or the ECT(1) codepoint 493 to indicate ECT, on a packet-by-packet basis. 495 The use of both the two codepoints for ECT, ECT(0) and ECT(1), is 496 motivated primarily by the desire to allow mechanisms for the data 497 sender to verify that network elements are not erasing the CE 498 codepoint, and that data receivers are properly reporting to the 499 sender the receipt of packets with the CE codepoint set, as 500 required by the transport protocol. Guidelines for the senders 501 and receivers to differentiate between the ECT(0) and ECT(1) 502 codepoints will be addressed in separate documents, for each 503 transport protocol. In particular, this document does not address 504 mechanisms for TCP end-nodes to differentiate between the ECT(0) 505 and ECT(1) codepoints. Protocols and senders that only require a 506 single ECT codepoint SHOULD use ECT(0). 508 with this paragraph: 510 Protocols and senders MUST use the ECT(0) codepoint to indicate 511 ECT unless otherwise specified by an Experimental RFC in the IETF 512 document stream. Protocols and senders MUST NOT use the ECT(1) 513 codepoint to indicate ECT unless otherwise specified by an 514 Experimental RFC in the IETF document stream. Guidelines for 515 senders and receivers to differentiate between the ECT(0) and 516 ECT(1) codepoints will be addressed in separate documents, for 517 each transport protocol. In particular, this document does not 518 address mechanisms for TCP end-nodes to differentiate between the 519 ECT(0) and ECT(1) codepoints. 521 Congestion Marking Differences experiments SHOULD modify the network 522 behavior for ECT(1)-marked traffic rather than ECT(0)-marked traffic 523 if network behavior for only one ECT codepoint is modified. 524 Congestion Marking Differences experiments MUST NOT modify the 525 network behavior for ECT(0)-marked traffic in a fashion that requires 526 changes to sender congestion response to obtain desired network 527 behavior. If a Congestion Marking Differences experiment modifies 528 the network behavior for ECT(1)-marked traffic, e.g., CE-marking 529 behavior, in a fashion that requires changes to sender congestion 530 response to obtain desired network behavior, then the Experimental 531 RFC in the IETF document stream for that experiment MUST specify: 533 o The sender congestion response to CE marking in the network, and 535 o Router behavior changes, or the absence thereof, in forwarding CE- 536 marked packets that are part of the experiment. 538 In addition, this memo updates RFC 3168 to remove discussion of the 539 ECN nonce, as noted in Section 3 above. 541 4.3. TCP Control Packets and Retransmissions 543 With the successful use of ECN for traffic in large portions of the 544 Internet, there is interest in extending the benefits of ECN to TCP 545 control packets (e.g., SYNs) and retransmitted packets, e.g., as 546 proposed by ECN++ [I-D.bagnulo-tcpm-generalized-ecn]. 548 RFC 3168 prohibits use of ECN for TCP control packets and 549 retransmitted packets in a number of places: 551 o "To ensure the reliable delivery of the congestion indication of 552 the CE codepoint, an ECT codepoint MUST NOT be set in a packet 553 unless the loss of that packet in the network would be detected by 554 the end nodes and interpreted as an indication of congestion." 555 (Section 5.2) 557 o "A host MUST NOT set ECT on SYN or SYN-ACK packets." 558 (Section 6.1.1) 560 o "pure acknowledgement packets (e.g., packets that do not contain 561 any accompanying data) MUST be sent with the not-ECT codepoint." 562 (Section 6.1.4) 564 o "This document specifies ECN-capable TCP implementations MUST NOT 565 set either ECT codepoint (ECT(0) or ECT(1)) in the IP header for 566 retransmitted data packets, and that the TCP data receiver SHOULD 567 ignore the ECN field on arriving data packets that are outside of 568 the receiver's current window." (Section 6.1.5) 570 o "the TCP data sender MUST NOT set either an ECT codepoint or the 571 CWR bit on window probe packets." (Section 6.1.6) 573 This memo updates RFC 3168 to allow the use of ECT codepoints on SYN 574 and SYN-ACK packets, pure acknowledgement packets, window probe 575 packets and retransmissions of packets that were originally sent with 576 an ECT codepoint, provided that the changes from RFC 3168 are 577 documented in an Experimental RFC in the IETF document stream. The 578 specific change to RFC 3168 is to insert the words "unless otherwise 579 specified by an Experimental RFC in the IETF document stream" at the 580 end of each sentence quoted above. 582 In addition, beyond requiring TCP senders not to set ECT on TCP 583 control packets and retransmitted packets, RFC 3168 is silent on 584 whether it is appropriate for a network element, e.g. a firewall, to 585 discard such a packet as invalid. For this area of ECN 586 experimentation to be useful, middleboxes ought not to do that, 587 therefore RFC 3168 is updated by adding the following text to the end 588 of Section 6.1.1.1 on Middlebox Issues: 590 Unless otherwise specified by an Experimental RFC in the IETF 591 document stream, middleboxes SHOULD NOT discard TCP control 592 packets and retransmitted TCP packets solely because the ECN field 593 in the IP header does not contain Not-ECT. An exception to this 594 requirement occurs in responding to an attack that uses ECN 595 codepoints other than Not-ECT. For example, as part of the 596 response, it may be appropriate to drop ECT-marked TCP SYN packets 597 with higher probability than TCP SYN packets marked with not-ECT. 598 Any such exceptional discarding of TCP control packets and 599 retransmitted TCP packets in response to an attack MUST NOT be 600 done routinely in the absence of an attack and SHOULD only be done 601 if it is determined that the use of ECN is contributing to the 602 attack. 604 5. ECN for RTP Updates to RFC 6679 606 RFC 6679 [RFC6679] specifies use of ECN for RTP traffic; it allows 607 use of both the ECT(0) and ECT(1) codepoints, and provides the 608 following guidance on use of these codepoints in section 7.3.1 : 610 The sender SHOULD mark packets as ECT(0) unless the receiver 611 expresses a preference for ECT(1) or for a random ECT value using 612 the "ect" parameter in the "a=ecn-capable-rtp:" attribute. 614 The Congestion Marking Differences area of experimentation increases 615 the potential consequences of using ECT(1) instead of ECT(0), and 616 hence the above guidance is updated by adding the following two 617 sentences: 619 Random ECT values MUST NOT be used, as that may expose RTP to 620 differences in network treatment of traffic marked with ECT(1) and 621 ECT(0) and differences in associated endpoint congestion 622 responses. In addition, ECT(0) MUST be used unless otherwise 623 specified in an Experimental RFC in the IETF document stream. 625 Section 7.3.3 of RFC 6679 specifies RTP's response to receipt of CE 626 marked packets as being identical to the response to dropped packets: 628 The reception of RTP packets with ECN-CE marks in the IP header is 629 a notification that congestion is being experienced. The default 630 reaction on the reception of these ECN-CE-marked packets MUST be 631 to provide the congestion control algorithm with a congestion 632 notification that triggers the algorithm to react as if packet 633 loss had occurred. There should be no difference in congestion 634 response if ECN-CE marks or packet drops are detected. 636 In support of Congestion Response Differences experimentation, this 637 memo updates this text in a fashion similar to RFC 3168 to allow the 638 RTP congestion control response to a CE-marked packet to differ from 639 the response to a dropped packet, provided that the changes from RFC 640 6679 are documented in an Experimental RFC in the IETF document 641 stream. The specific change to RFC 6679 is to insert the words 642 "Unless otherwise specified by an Experimental RFC in the IETF 643 document stream" and reformat the last two sentences to be subject to 644 that condition, i.e.: 646 The reception of RTP packets with ECN-CE marks in the IP header is 647 a notification that congestion is being experienced. Unless 648 otherwise specified by an Experimental RFC in the IETF document 649 stream: 651 * The default reaction on the reception of these ECN-CE-marked 652 packets MUST be to provide the congestion control algorithm 653 with a congestion notification that triggers the algorithm to 654 react as if packet loss had occurred. 656 * There should be no difference in congestion response if ECN-CE 657 marks or packet drops are detected. 659 The second sentence of the immediately following paragraph in RFC 660 6679 requires a related update: 662 Other reactions to ECN-CE may be specified in the future, 663 following IETF Review. Detailed designs of such additional 664 reactions MUST be specified in a Standards Track RFC and be 665 reviewed to ensure they are safe for deployment under any 666 restrictions specified. 668 The update is to change "Standards Track RFC" to "Standards Track RFC 669 or Experimental RFC in the IETF document stream" for consistency with 670 the first update. 672 6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 674 The specifications of the three DCCP Congestion Control IDs (CCIDs) 2 675 [RFC4341], 3 [RFC4342] and 4 [RFC5622] contain broadly the same 676 wording as follows: 678 each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable with 679 either the ECT(0) or the ECT(1) codepoint set. 681 This memo updates these sentences in each of the three RFCs as 682 follows: 684 each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable. 685 Unless otherwise specified by an Experimental RFC in the IETF 686 document stream, such DCCP senders MUST set the ECT(0) codepoint. 688 In support of Congestion Marking Differences experimentation (as 689 noted in Section 3), this memo also updates all three of these RFCs 690 to remove discussion of the ECN nonce. The specific text updates are 691 omitted for brevity. 693 7. Acknowledgements 695 The content of this draft, including the specific portions of RFC 696 3168 that are updated draws heavily from 697 [I-D.khademi-tsvwg-ecn-response], whose authors are gratefully 698 acknowledged. The authors of the Internet Drafts describing the 699 experiments have motivated the production of this memo - their 700 interest in innovation is welcome and heartily acknowledged. Colin 701 Perkins suggested updating RFC 6679 on RTP and provided guidance on 702 where to make the updates. 704 The draft has been improved as a result of comments from a number of 705 reviewers, including Ben Campbell, Brian Carpenter, Benoit Claise, 706 Spencer Dawkins, Gorry Fairhurst, Sue Hares, Ingemar Johansson, Naeem 707 Khademi, Mirja Kuehlewind, Karen Nielsen, Hilarie Orman, Eric 708 Rescorla, Adam Roach and Michael Welzl. Bob Briscoe's thorough 709 reviews of multiple versions of this memo resulted in numerous 710 improvements including addition of the updates to the DCCP RFCs. 712 8. IANA Considerations 714 To reflect the reclassification of RFC 3540 as Historic, IANA is 715 requested to update the Transmission Control Protocol (TCP) Header 716 Flags registry (https://www.iana.org/assignments/tcp-header-flags/ 717 tcp-header-flags.xhtml#tcp-header-flags-1) to remove the registration 718 of bit 7 as the NS (Nonce Sum) bit and add an annotation to the 719 registry to state that bit 7 was used by Historic RFC 3540 as the NS 720 (Nonce Sum) bit. 722 9. Security Considerations 724 As a process memo that only relaxes restrictions on experimentation, 725 there are no protocol security considerations, as security 726 considerations for any experiments that take advantage of the relaxed 727 restrictions are discussed in the Internet-Drafts that propose the 728 experiments. 730 However, effective congestion control is crucial to the continued 731 operation of the Internet, and hence this memo places the 732 responsibility for not breaking Internet congestion control on the 733 experiments and the experimenters who propose them. This 734 responsibility includes the requirement to discuss congestion control 735 implications in an IETF document stream Experimental RFC for each 736 experiment, as stated in Section 2.1; review of that discussion by 737 the IETF community and the IESG prior to RFC publication is intended 738 to provide assurance that each experiment does not break Internet 739 congestion control. 741 See Appendix C.1 of [I-D.ietf-tsvwg-ecn-l4s-id] for discussion of 742 alternatives to the ECN nonce. 744 10. References 746 10.1. Normative References 748 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 749 Requirement Levels", BCP 14, RFC 2119, 750 DOI 10.17487/RFC2119, March 1997, 751 . 753 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 754 RFC 2914, DOI 10.17487/RFC2914, September 2000, 755 . 757 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 758 of Explicit Congestion Notification (ECN) to IP", 759 RFC 3168, DOI 10.17487/RFC3168, September 2001, 760 . 762 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 763 Congestion Notification (ECN) Signaling with Nonces", 764 RFC 3540, DOI 10.17487/RFC3540, June 2003, 765 . 767 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 768 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 769 Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 770 2006, . 772 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 773 Datagram Congestion Control Protocol (DCCP) Congestion 774 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 775 DOI 10.17487/RFC4342, March 2006, 776 . 778 [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 779 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate 780 Control for Small Packets (TFRC-SP)", RFC 5622, 781 DOI 10.17487/RFC5622, August 2009, 782 . 784 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 785 and K. Carlberg, "Explicit Congestion Notification (ECN) 786 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 787 2012, . 789 10.2. Informative References 791 [I-D.bagnulo-tcpm-generalized-ecn] 792 Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit 793 Congestion Notification (ECN) to TCP Control Packets", 794 draft-bagnulo-tcpm-generalized-ecn-04 (work in progress), 795 May 2017. 797 [I-D.ietf-tcpm-alternativebackoff-ecn] 798 Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 799 "TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm- 800 alternativebackoff-ecn-03 (work in progress), October 801 2017. 803 [I-D.ietf-tcpm-dctcp] 804 Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., 805 and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion 806 Control for Datacenters", draft-ietf-tcpm-dctcp-10 (work 807 in progress), August 2017. 809 [I-D.ietf-trill-ecn-support] 810 Eastlake, D. and B. Briscoe, "TRILL: ECN (Explicit 811 Congestion Notification) Support", draft-ietf-trill-ecn- 812 support-03 (work in progress), May 2017. 814 [I-D.ietf-tsvwg-ecn-encap-guidelines] 815 Briscoe, B., Kaippallimalil, J., and P. Thaler, 816 "Guidelines for Adding Congestion Notification to 817 Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- 818 encap-guidelines-09 (work in progress), July 2017. 820 [I-D.ietf-tsvwg-ecn-l4s-id] 821 Schepper, K. and B. Briscoe, "Identifying Modified 822 Explicit Congestion Notification (ECN) Semantics for 823 Ultra-Low Queuing Delay", draft-ietf-tsvwg-ecn-l4s-id-01 824 (work in progress), October 2017. 826 [I-D.ietf-tsvwg-rfc6040update-shim] 827 Briscoe, B., "Propagating Explicit Congestion Notification 828 Across IP Tunnel Headers Separated by a Shim", draft-ietf- 829 tsvwg-rfc6040update-shim-05 (work in progress), November 830 2017. 832 [I-D.khademi-tsvwg-ecn-response] 833 Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 834 "Updating the Explicit Congestion Notification (ECN) 835 Specification to Allow IETF Experimentation", draft- 836 khademi-tsvwg-ecn-response-01 (work in progress), July 837 2016. 839 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 840 Explicit Congestion Notification (ECN) Field", BCP 124, 841 RFC 4774, DOI 10.17487/RFC4774, November 2006, 842 . 844 [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC 845 Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, 846 July 2007, . 848 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 849 Management of New Protocols and Protocol Extensions", 850 RFC 5706, DOI 10.17487/RFC5706, November 2009, 851 . 853 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 854 Notification", RFC 6040, DOI 10.17487/RFC6040, November 855 2010, . 857 [RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three 858 Pre-Congestion Notification (PCN) States in the IP Header 859 Using a Single Diffserv Codepoint (DSCP)", RFC 6660, 860 DOI 10.17487/RFC6660, July 2012, 861 . 863 [Trammell15] 864 Trammell, B., Kuehlewind, M., Boppart, D., Learmonth, I., 865 Fairhurst, G., and R. Scheffenegger, "Enabling Internet- 866 Wide Deployment of Explicit Congestion Notification". 868 In Proc Passive & Active Measurement (PAM'15) Conference 869 (2015) 871 Appendix A. Change History 873 [To be removed before RFC publication.] 875 Changes from draft-ietf-tsvwg-ecn-experimentation-00 to -01: 877 o Add mention of DCTCP as another protocol that could benefit from 878 ECN experimentation (near end of Section 2). 880 Changes from draft-ietf-tsvwg-ecn-experimentation-01 to -02: 882 o Generalize to describe rationale for areas of experimentation, 883 with less focus on individual experiments 885 o Add ECN terminology section 887 o Change name of "ECT Differences" experimentation area to 888 "Congestion Marking Differences" 890 o Add overlooked RFC 3168 modification to Section 4.1 892 o Clarify text for Experimental RFC exception to ECT(1) non-usage 893 requirement 895 o Add explanation of exception to "SHOULD NOT drop" requirement in 896 4.3 898 o Rework RFC 3540 status change text to provide rationale for a 899 separate status change document that makes RFC 3540 Historic. 900 Don't obsolete RFC 3540. 902 o Significant editorial changes based on reviews by Mirja 903 Kuehlewind, Michael Welzl and Bob Briscoe. 905 Changes from draft-ietf-tsvwg-ecn-experimentation-02 to -03: 907 o Remove change history prior to WG adoption. 909 o Update L4S draft reference to reflect TSVWG adoption of draft. 911 o Change the "SHOULD" for DCCP sender use of ECT(0) to a "MUST" 912 (overlooked in earlier editing). 914 o Other minor edits. 916 Changes from draft-ietf-tsvwg-ecn-experimentation-03 to -04: 918 o Change name of "Generalized ECN" experimentation area to "TCP 919 Control Packets and Retransmissions." 921 o Add IANA Considerations text to request removal of the 922 registration of the NS bit in the TCP header. 924 Changes from draft-ietf-tsvwg-ecn-experimentation-04 to -05: 926 o Minor editorial changes from Area Director review 928 Changes from draft-ietf-tsvwg-ecn-experimentation-05 to -06: 930 o Add summary of RFC 3168 changes to remove the ECN nonce, and use 931 lower-case "nonce" instead of "Nonce" to match RFC 3168 usage. 933 o Add security considerations sentence to indicate that review of 934 Experimental RFCs prior to publication approval is the means to 935 ensure that congestion control is not broken by experiments. 937 o Other minor editorial changes from IETF Last Call 939 Changes from draft-ietf-tsvwg-ecn-experimentation-06 to -07: 941 o Change draft title to make scope clear - this only covers relaxing 942 of restrictions on ECN experimentation. 944 o Any Experimental RFC that takes advantage of this memo has to be 945 in the IETF document stream. 947 o Added sections 2.2 and 2.3 on considerations for other protocols 948 and O&M, relocated discussion of congestion control requirement to 949 section 2.1 from section 4.4 951 o Remove text indicating that ECT(1) may be assigned to L4S - the 952 requirement for an Experimental RFC suffices to ensure that 953 coordination with L4S will occur. 955 o Improve explanation of attack response exception to not dropping 956 packets "solely because the ECN field in the IP header does not 957 contain Not-ECT" in Section 4.3 959 o Fix L4S draft reference for discussion of ECN Nonce alternatives - 960 it's Appendix C.1, not B.1. 962 o Numerous additional editorial changes from IESG Evaluation 964 Changes from draft-ietf-tsvwg-ecn-experimentation-07 to -08: 966 o Edits from another careful review by Bob Briscoe. The primary 967 change is an editorial rewrite of Section 2.2 including changing 968 its name to better reflect its content. 970 Author's Address 972 David Black 973 Dell EMC 974 176 South Street 975 Hopkinton, MA 01748 976 USA 978 Email: david.black@dell.com