idnits 2.17.1 draft-ietf-tsvwg-ecn-experimentation-07.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 (October 20, 2017) is 2379 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 (-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-00 == Outdated reference: A later version (-23) exists of draft-ietf-tsvwg-rfc6040update-shim-04 -- 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 October 20, 2017 5 (if approved) 6 Intended status: Standards Track 7 Expires: April 23, 2018 9 Relaxing Restrictions on Explicit Congestion Notification (ECN) 10 Experimentation 11 draft-ietf-tsvwg-ecn-experimentation-07 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 April 23, 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. Considerations for Other Protocols . . . . . . . . . . . 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 . . . . . . 14 90 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 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 that a shorter queue exists at 165 the network bottleneck node by comparison to a longer queue that 166 is more likely when a packet drop occurs that indicates congestion 167 [I-D.ietf-tcpm-alternativebackoff-ecn]. This difference suggests 168 that for congestion indicated by ECN, a different sender 169 congestion response (e.g., sender backs off by a smaller amount) 170 may be appropriate by comparison to the sender response to 171 congestion indicated by loss. Two examples of proposed sender 172 congestion response changes are described in 173 [I-D.ietf-tcpm-alternativebackoff-ecn] and 174 [I-D.ietf-tsvwg-ecn-l4s-id] - the proposal in the latter draft 175 couples the sender congestion response change to Congestion 176 Marking Differences changes (see next paragraph). This is at 177 variance with RFC 3168's requirement that a sender's congestion 178 control response to ECN congestion indications be the same as to 179 drops. IETF approval, e.g., via an Experimental RFC in the IETF 180 document stream, is required for any sender congestion response 181 used in this area of experimentation. See Section 4.1 for further 182 discussion. 184 Congestion Marking Differences: Congestion marking at network nodes 185 can be configured to maintain very shallow queues in conjunction 186 with a different sender response to congestion indications (CE 187 marks), e.g., as proposed in [I-D.ietf-tsvwg-ecn-l4s-id]. The 188 traffic involved needs to be identified by the senders to the 189 network nodes in order to avoid damage to other network traffic 190 whose senders do not expect the more frequent congestion marking 191 used to maintain very shallow queues. Use of different ECN 192 codepoints, specifically ECT(0) and ECT(1), is a promising means 193 of traffic identification for this purpose, but that technique is 194 at variance with RFC 3168's requirement that ECT(0)-marked traffic 195 and ECT(1)-marked traffic not receive different treatment in the 196 network. IETF approval, e.g., via an Experimental RFC in the IETF 197 document stream, is required for any sender congestion response 198 used in this area of experimentation. See Section 4.2 for further 199 discussion. 201 TCP Control Packets and Retransmissions: RFC 3168 limits the use of 202 ECN with TCP to data packets, excluding retransmissions. With the 203 successful deployment of ECN in large portions of the Internet, 204 there is interest in extending the benefits of ECN to TCP control 205 packets (e.g., SYNs) and retransmitted packets, e.g., as proposed 206 in [I-D.bagnulo-tcpm-generalized-ecn]. This is at variance with 207 RFC 3168's prohibition of use of ECN for TCP control packets and 208 retransmitted packets. See Section 4.3 for further discussion. 210 The scope of this memo is limited to these three areas of 211 experimentation. This memo expresses no view on the likely outcomes 212 of the proposed experiments and does not specify the experiments in 213 detail. Additional experiments in these areas are possible, e.g., on 214 use of ECN to support deployment of a protocol similar to DCTCP 215 [I-D.ietf-tcpm-dctcp] beyond DCTCP's current applicability that is 216 limited to data center environments. The purpose of this memo is to 217 remove constraints in standards track RFCs that stand in the way of 218 these areas of experimentation. 220 2.1. Effective Congestion Control is Required 222 Congestion control remains an important aspect of the Internet 223 architecture [RFC2914]. Any Experimental RFC in the IETF document 224 stream that takes advantage of this memo's updates to any RFC is 225 required to discuss the congestion control implications of the 226 experiment(s) in order to provide assurance that deployment of the 227 experiment(s) does not pose a congestion-based threat to the 228 operation of the Internet. 230 2.2. Considerations for Other Protocols 232 ECN is widely deployed in the Internet and is being designed into 233 additional protocols such as TRILL [I-D.ietf-trill-ecn-support]. 234 While the responsibility for coexistence with other protocols and 235 transition from current ECN functionality falls primary upon the 236 designers of experimental changes to ECN, this subsection provides 237 some general guidelines for designers and users of other protocols 238 that minimize the likelihood of interaction with the areas of ECN 239 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. The ECN CE codepoint SHOULD NOT be assumed to indicate that the 247 packet would have been dropped if ECN were not in use, as that is 248 not the case for either Congestion Response Differences 249 experiments (see Section 4.1 below) or Congestion Marking 250 Differences experiments (see Section 4.2 below). This is already 251 the case when the ECN field is used for Pre-Congestion 252 Notification (PCN) [RFC6660]. 254 3. Traffic marked with ECT(1) MUST NOT be originated, as specified 255 in Section 4.2 below. 257 4. ECN may now be used on packets where it has not been used 258 previously, specifically TCP control packets and retransmissions, 259 see Section 4.3 below, and in particular its new requirements for 260 middlebox behavior. In general, any system or protocol that 261 inspects or monitors network traffic SHOULD be prepared to 262 encounter ECN usage on packets and traffic that currently do not 263 use ECN. 265 5. Requirements for handling of the ECN field by tunnel 266 encapsulation and decapsulation are specified in [RFC6040]. 267 Additional related guidance can be found in 268 [I-D.ietf-tsvwg-ecn-encap-guidelines] and 269 [I-D.ietf-tsvwg-rfc6040update-shim]. 271 2.3. Operational and Management Considerations 273 Changes in network traffic behavior that result from ECN 274 experimentation are likely to impact network operations and 275 management. Designers of ECN experiments are expected to anticipate 276 possible impacts and consider how they may be dealt with. Specific 277 topics to consider include possible network management changes or 278 extensions, monitoring of the experimental deployment, collection of 279 data for evaluation of the experiment and possible interactions with 280 other protocols, particularly protocols that encapsulate network 281 traffic. 283 For further discussion, see [RFC5706]; the questions in Appendix A 284 provide a concise survey of some important aspects to consider. 286 3. ECN Nonce and RFC 3540 288 As specified in RFC 3168, ECN uses two ECN Capable Transport (ECT) 289 codepoints to indicate that a packet supports ECN, ECT(0) and ECT(1). 290 The second codepoint, ECT(1), is used to support ECN nonce 291 functionality that discourages receivers from exploiting ECN to 292 improve their throughput at the expense of other network users, as 293 specified in Experimental RFC 3540 [RFC3540]. This section explains 294 why RFC 3540 is being reclassified as Historic and makes associated 295 updates to RFC 3168. 297 While the ECN nonce works as specified, and has been deployed in 298 limited environments, widespread usage in the Internet has not 299 materialized. A study of the ECN behaviour of the top one million 300 web servers using 2014 data [Trammell15] found that after ECN was 301 negotiated, none of the 581,711 IPv4 servers tested were using both 302 ECT codepoints, which would have been a possible sign of ECN nonce 303 usage. Of the 17,028 IPv6 servers tested, 4 set both ECT(0) and 304 ECT(1) on data packets. This might have been evidence of use of the 305 ECN nonce by these 4 servers, but might equally have been due to 306 erroneous re-marking of the ECN field by a middlebox or router. 308 With the emergence of new experimental functionality that depends on 309 use of the ECT(1) codepoint for other purposes, continuing to reserve 310 that codepoint for the ECN nonce experiment is no longer justified. 311 In addition, other approaches to discouraging receivers from 312 exploiting ECN have emerged, see Appendix B.1 of 313 [I-D.ietf-tsvwg-ecn-l4s-id]. Therefore, in support of ECN 314 experimentation with the ECT(1) codepoint, this memo: 316 o Declares that the ECN nonce experiment [RFC3540] has concluded, 317 and notes the absence of widespread deployment. 319 o Updates RFC 3168 [RFC3168] to remove discussion of the ECN nonce 320 and use of ECT(1) for that nonce. 322 The four primary updates to RFC 3168 that remove discussion of the 323 ECN nonce and use of ECT(1) for that nonce are: 325 1. Remove the paragraph in Section 5 that immediately follows 326 Figure 1; this paragraph discusses the ECN nonce as the 327 motivation for two ECT codepoints. 329 2. Remove Section 11.2 "A Discussion of the ECN nonce." in its 330 entirety. 332 3. Remove the last paragraph of Section 12, which states that ECT(1) 333 may be used as part of the implementation of the ECN nonce. 335 4. Remove the first two paragraphs of Section 20.2, which discuss 336 the ECN nonce and alternatives. No changes are made to the rest 337 of Section 20.2, which discusses alternate uses for the fourth 338 ECN codepoint. 340 In addition, other less substantive RFC 3168 changes are required to 341 remove all other mentions of the ECN nonce and to remove implications 342 that ECT(1) is intended for use by the ECN nonce; these specific text 343 updates are omitted for brevity. 345 4. Updates to RFC 3168 347 The following subsections specify updates to RFC 3168 to enable the 348 three areas of experimentation summarized in Section 2. 350 4.1. Congestion Response Differences 352 RFC 3168 specifies that senders respond identically to packet drops 353 and ECN congestion indications. ECN congestion indications are 354 predominately originated by Active Queue Management (AQM) mechanisms 355 in intermediate buffers. AQM mechanisms are usually configured to 356 maintain shorter queue lengths than non-AQM based mechanisms, 357 particularly non-AQM drop-based mechanisms such as tail-drop, as AQM 358 mechanisms indicate congestion before the queue overflows. While the 359 occurrence of loss does not easily enable the receiver to determine 360 if AQM is used, the receipt of an ECN Congestion Experienced (CE) 361 mark conveys a strong likelihood that AQM was used to manage the 362 bottleneck queue. Hence an ECN congestion indication communicates a 363 higher likelihood that a shorter queue exists at the network 364 bottleneck node by comparison to a packet drop that indicates 365 congestion [I-D.ietf-tcpm-alternativebackoff-ecn]. This difference 366 suggests that for congestion indicated by ECN, a different sender 367 congestion response (e.g., sender backs off by a smaller amount) may 368 be appropriate by comparison to the sender response to congestion 369 indicated by loss. However, section 5 of RFC 3168 specifies that: 371 Upon the receipt by an ECN-Capable transport of a single CE 372 packet, the congestion control algorithms followed at the end- 373 systems MUST be essentially the same as the congestion control 374 response to a *single* dropped packet. 376 This memo updates this RFC 3168 text to allow the congestion control 377 response (including the TCP Sender's congestion control response) to 378 a CE-marked packet to differ from the response to a dropped packet, 379 provided that the changes from RFC 3168 are documented in an 380 Experimental RFC in the IETF document stream. The specific change to 381 RFC 3168 is to insert the words "unless otherwise specified by an 382 Experimental RFC in the IETF document stream" at the end of the 383 sentence quoted above. 385 RFC 4774 [RFC4774] quotes the above text from RFC 3168 as background, 386 but does not impose requirements based on that text. Therefore no 387 update to RFC 4774 is required to enable this area of 388 experimentation. 390 Section 6.1.2 of RFC 3168 specifies that: 392 If the sender receives an ECN-Echo (ECE) ACK packet (that is, an 393 ACK packet with the ECN-Echo flag set in the TCP header), then the 394 sender knows that congestion was encountered in the network on the 395 path from the sender to the receiver. The indication of 396 congestion should be treated just as a congestion loss in non- 397 ECN-Capable TCP. That is, the TCP source halves the congestion 398 window "cwnd" and reduces the slow start threshold "ssthresh". 400 This memo also updates this RFC 3168 text to allow the congestion 401 control response (including the TCP Sender's congestion control 402 response) to a CE-marked packet to differ from the response to a 403 dropped packet, provided that the changes from RFC 3168 are 404 documented in an Experimental RFC in the IETF document stream. The 405 specific change to RFC 3168 is to insert the words "Unless otherwise 406 specified by an Experimental RFC in the IETF document stream" at the 407 beginning of the second sentence quoted above. 409 4.2. Congestion Marking Differences 411 Taken to its limit, an AQM algorithm that uses ECN congestion 412 indications can be configured to maintain very shallow queues, 413 thereby reducing network latency by comparison to maintaining a 414 larger queue. Significantly more aggressive sender responses to ECN 415 are needed to make effective use of such very shallow queues; 416 Datacenter TCP (DCTCP) [I-D.ietf-tcpm-dctcp] provides an example. In 417 this case, separate network node treatments are essential, both to 418 prevent the aggressive low latency traffic from starving conventional 419 traffic (if present) and to prevent any conventional traffic 420 disruption to any lower latency service that uses the very shallow 421 queues. Use of different ECN codepoints is a promising means of 422 identifying these two classes of traffic to network nodes, and hence 423 this area of experimentation is based on the use of the ECT(1) 424 codepoint to request ECN congestion marking behavior in the network 425 that differs from ECT(0) counterbalanced by use of a different IETF- 426 approved congestion response to CE marks at the sender, e.g., as 427 proposed in [I-D.ietf-tsvwg-ecn-l4s-id]. 429 Section 5 of RFC 3168 specifies that: 431 Routers treat the ECT(0) and ECT(1) codepoints as equivalent. 433 This memo updates RFC 3168 to allow routers to treat the ECT(0) and 434 ECT(1) codepoints differently, provided that the changes from RFC 435 3168 are documented in an Experimental RFC in the IETF document 436 stream. The specific change to RFC 3168 is to insert the words 437 "unless otherwise specified by an Experimental RFC in the IETF 438 document stream" at the end of the above sentence. 440 When an AQM is configured to use ECN congestion indications to 441 maintain a very shallow queue, congestion indications are marked on 442 packets that would not have been dropped if ECN was not in use. 443 Section 5 of RFC 3168 specifies that: 445 For a router, the CE codepoint of an ECN-Capable packet SHOULD 446 only be set if the router would otherwise have dropped the packet 447 as an indication of congestion to the end nodes. When the 448 router's buffer is not yet full and the router is prepared to drop 449 a packet to inform end nodes of incipient congestion, the router 450 should first check to see if the ECT codepoint is set in that 451 packet's IP header. If so, then instead of dropping the packet, 452 the router MAY instead set the CE codepoint in the IP header. 454 This memo updates RFC 3168 to allow congestion indications that are 455 not equivalent to drops, provided that the changes from RFC 3168 are 456 documented in an Experimental RFC in the IETF document stream. The 457 specific change is to change "For a router," to "Unless otherwise 458 specified by an Experimental RFC in the IETF document stream" at the 459 beginning of the first sentence of the above paragraph. 461 A larger update to RFC 3168 is necessary to enable sender usage of 462 ECT(1) to request network congestion marking behavior that maintains 463 very shallow queues at network nodes. When using loss as a 464 congestion signal, the number of signals provided should be reduced 465 to a minimum and hence only presence or absence of congestion is 466 communicated. In contrast, ECN can provide a richer signal, e.g., to 467 indicate the current level of congestion, without the disadvantage of 468 a larger number of packet losses. A proposed experiment in this 469 area, Low Latency Low Loss Scalable throughput (L4S) 470 [I-D.ietf-tsvwg-ecn-l4s-id] significantly increases the CE marking 471 probability for ECT(1)-marked traffic in a fashion that would 472 interact badly with existing sender congestion response functionality 473 because that functionality assumes that the network marks ECT packets 474 as frequently as it would drop Not-ECT packets. If network traffic 475 that uses such a conventional sender congestion response were to 476 encounter L4S's increased marking probability (and hence rate) at a 477 network bottleneck queue, the resulting traffic throughput is likely 478 to be much less than intended for the level of congestion at the 479 bottleneck queue. 481 This memo updates RFC 3168 to remove that interaction for ECT(1). 482 The specific update to Section 5 of RFC 3168 is to replace the 483 following two paragraphs: 485 Senders are free to use either the ECT(0) or the ECT(1) codepoint 486 to indicate ECT, on a packet-by-packet basis. 488 The use of both the two codepoints for ECT, ECT(0) and ECT(1), is 489 motivated primarily by the desire to allow mechanisms for the data 490 sender to verify that network elements are not erasing the CE 491 codepoint, and that data receivers are properly reporting to the 492 sender the receipt of packets with the CE codepoint set, as 493 required by the transport protocol. Guidelines for the senders 494 and receivers to differentiate between the ECT(0) and ECT(1) 495 codepoints will be addressed in separate documents, for each 496 transport protocol. In particular, this document does not address 497 mechanisms for TCP end-nodes to differentiate between the ECT(0) 498 and ECT(1) codepoints. Protocols and senders that only require a 499 single ECT codepoint SHOULD use ECT(0). 501 with this paragraph: 503 Protocols and senders MUST use the ECT(0) codepoint to indicate 504 ECT unless otherwise specified by an Experimental RFC in the IETF 505 document stream. Protocols and senders MUST NOT use the ECT(1) 506 codepoint to indicate ECT unless otherwise specified by an 507 Experimental RFC in the IETF document stream. Guidelines for 508 senders and receivers to differentiate between the ECT(0) and 509 ECT(1) codepoints will be addressed in separate documents, for 510 each transport protocol. In particular, this document does not 511 address mechanisms for TCP end-nodes to differentiate between the 512 ECT(0) and ECT(1) codepoints. 514 Congestion Marking Differences experiments SHOULD modify the network 515 behavior for ECT(1)-marked traffic rather than ECT(0)-marked traffic 516 if network behavior for only one ECT codepoint is modified. 517 Congestion Marking Differences experiments MUST NOT modify the 518 network behavior for ECT(0)-marked traffic in a fashion that requires 519 changes to sender congestion response to obtain desired network 520 behavior. If a Congestion Marking Differences experiment modifies 521 the network behavior for ECT(1)-marked traffic, e.g., CE-marking 522 behavior, in a fashion that requires changes to sender congestion 523 response to obtain desired network behavior, then the Experimental 524 RFC in the IETF document stream for that experiment MUST specify: 526 o The sender congestion response to CE marking in the network, and 528 o Router behavior changes, or the absence thereof, in forwarding CE- 529 marked packets that are part of the experiment. 531 In addition, this memo updates RFC 3168 to remove discussion of the 532 ECN nonce, as noted in Section 3 above. 534 4.3. TCP Control Packets and Retransmissions 536 With the successful use of ECN for traffic in large portions of the 537 Internet, there is interest in extending the benefits of ECN to TCP 538 control packets (e.g., SYNs) and retransmitted packets, e.g., as 539 proposed by ECN++ [I-D.bagnulo-tcpm-generalized-ecn]. 541 RFC 3168 prohibits use of ECN for TCP control packets and 542 retransmitted packets in a number of places: 544 o "To ensure the reliable delivery of the congestion indication of 545 the CE codepoint, an ECT codepoint MUST NOT be set in a packet 546 unless the loss of that packet in the network would be detected by 547 the end nodes and interpreted as an indication of congestion." 548 (Section 5.2) 550 o "A host MUST NOT set ECT on SYN or SYN-ACK packets." 551 (Section 6.1.1) 553 o "pure acknowledgement packets (e.g., packets that do not contain 554 any accompanying data) MUST be sent with the not-ECT codepoint." 555 (Section 6.1.4) 557 o "This document specifies ECN-capable TCP implementations MUST NOT 558 set either ECT codepoint (ECT(0) or ECT(1)) in the IP header for 559 retransmitted data packets, and that the TCP data receiver SHOULD 560 ignore the ECN field on arriving data packets that are outside of 561 the receiver's current window." (Section 6.1.5) 563 o "the TCP data sender MUST NOT set either an ECT codepoint or the 564 CWR bit on window probe packets." (Section 6.1.6) 566 This memo updates RFC 3168 to allow the use of ECT codepoints on SYN 567 and SYN-ACK packets, pure acknowledgement packets, window probe 568 packets and retransmissions of packets that were originally sent with 569 an ECT codepoint, provided that the changes from RFC 3168 are 570 documented in an Experimental RFC in the IETF document stream. The 571 specific change to RFC 3168 is to insert the words "unless otherwise 572 specified by an Experimental RFC in the IETF document stream" at the 573 end of each sentence quoted above. 575 In addition, beyond requiring TCP senders not to set ECT on TCP 576 control packets and retransmitted packets, RFC 3168 is silent on 577 whether it is appropriate for a network element, e.g. a firewall, to 578 discard such a packet as invalid. For this area of ECN 579 experimentation to be useful, middleboxes ought not to do that, 580 therefore RFC 3168 is updated by adding the following text to the end 581 of Section 6.1.1.1 on Middlebox Issues: 583 Unless otherwise specified by an Experimental RFC in the IETF 584 document stream, middleboxes SHOULD NOT discard TCP control 585 packets and retransmitted TCP packets solely because the ECN field 586 in the IP header does not contain Not-ECT. An exception to this 587 requirement occurs in responding to an attack that uses ECN 588 codepoints other than Not-ECT. For example, as part of the 589 response, it may be appropriate to drop ECT-marked TCP SYN packets 590 with higher probability than TCP SYN packets marked with not-ECT. 591 Any such exceptional discarding of TCP control packets and 592 retransmitted TCP packets in response to an attack MUST NOT be 593 done routinely in the absence of an attack and SHOULD only be done 594 if it is determined that the use of ECN is contributing to the 595 attack. 597 5. ECN for RTP Updates to RFC 6679 599 RFC 6679 [RFC6679] specifies use of ECN for RTP traffic; it allows 600 use of both the ECT(0) and ECT(1) codepoints, and provides the 601 following guidance on use of these codepoints in section 7.3.1 : 603 The sender SHOULD mark packets as ECT(0) unless the receiver 604 expresses a preference for ECT(1) or for a random ECT value using 605 the "ect" parameter in the "a=ecn-capable-rtp:" attribute. 607 The Congestion Marking Differences area of experimentation increases 608 the potential consequences of using ECT(1) instead of ECT(0), and 609 hence the above guidance is updated by adding the following two 610 sentences: 612 Random ECT values MUST NOT be used, as that may expose RTP to 613 differences in network treatment of traffic marked with ECT(1) and 614 ECT(0) and differences in associated endpoint congestion 615 responses. In addition, ECT(0) MUST be used unless otherwise 616 specified in an Experimental RFC in the IETF document stream. 618 Section 7.3.3 of RFC 6679 specifies RTP's response to receipt of CE 619 marked packets as being identical to the response to dropped packets: 621 The reception of RTP packets with ECN-CE marks in the IP header is 622 a notification that congestion is being experienced. The default 623 reaction on the reception of these ECN-CE-marked packets MUST be 624 to provide the congestion control algorithm with a congestion 625 notification that triggers the algorithm to react as if packet 626 loss had occurred. There should be no difference in congestion 627 response if ECN-CE marks or packet drops are detected. 629 In support of Congestion Response Differences experimentation, this 630 memo updates this text in a fashion similar to RFC 3168 to allow the 631 RTP congestion control response to a CE-marked packet to differ from 632 the response to a dropped packet, provided that the changes from RFC 633 6679 are documented in an Experimental RFC in the IETF document 634 stream. The specific change to RFC 6679 is to insert the words 635 "Unless otherwise specified by an Experimental RFC in the IETF 636 document stream" and reformat the last two sentences to be subject to 637 that condition, i.e.: 639 The reception of RTP packets with ECN-CE marks in the IP header is 640 a notification that congestion is being experienced. Unless 641 otherwise specified by an Experimental RFC in the IETF document 642 stream: 644 * The default reaction on the reception of these ECN-CE-marked 645 packets MUST be to provide the congestion control algorithm 646 with a congestion notification that triggers the algorithm to 647 react as if packet loss had occurred. 649 * There should be no difference in congestion response if ECN-CE 650 marks or packet drops are detected. 652 The second sentence of the immediately following paragraph in RFC 653 6679 requires a related update: 655 Other reactions to ECN-CE may be specified in the future, 656 following IETF Review. Detailed designs of such additional 657 reactions MUST be specified in a Standards Track RFC and be 658 reviewed to ensure they are safe for deployment under any 659 restrictions specified. 661 The update is to change "Standards Track RFC" to "Standards Track RFC 662 or Experimental RFC in the IETF document stream" for consistency with 663 the first update. 665 6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 667 The specifications of the three DCCP Congestion Control IDs (CCIDs) 2 668 [RFC4341], 3 [RFC4342] and 4 [RFC5622] contain broadly the same 669 wording as follows: 671 each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable with 672 either the ECT(0) or the ECT(1) codepoint set. 674 This memo updates these sentences in each of the three RFCs as 675 follows: 677 each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable. 678 Unless otherwise specified by an Experimental RFC in the IETF 679 document stream, such DCCP senders MUST set the ECT(0) codepoint. 681 In support of Congestion Marking Differences experimentation (as 682 noted in Section 3), this memo also updates all three of these RFCs 683 to remove discussion of the ECN nonce. The specific text updates are 684 omitted for brevity. 686 7. Acknowledgements 688 The content of this draft, including the specific portions of RFC 689 3168 that are updated draws heavily from 690 [I-D.khademi-tsvwg-ecn-response], whose authors are gratefully 691 acknowledged. The authors of the Internet Drafts describing the 692 experiments have motivated the production of this memo - their 693 interest in innovation is welcome and heartily acknowledged. Colin 694 Perkins suggested updating RFC 6679 on RTP and provided guidance on 695 where to make the updates. 697 The draft has been improved as a result of comments from a number of 698 reviewers, including Ben Campbell, Brian Carpenter, Benoit Claise, 699 Spencer Dawkins, Gorry Fairhurst, Sue Hares, Ingemar Johansson, Naeem 700 Khademi, Mirja Kuehlewind, Karen Nielsen, Hilarie Orman, Eric 701 Rescorla, Adam Roach and Michael Welzl. Bob Briscoe's thorough 702 review of an early version of this memo resulted in numerous 703 improvements including addition of the updates to the DCCP RFCs. 705 8. IANA Considerations 707 To reflect the reclassification of RFC 3540 as Historic, IANA is 708 requested to update the Transmission Control Protocol (TCP) Header 709 Flags registry (https://www.iana.org/assignments/tcp-header-flags/ 710 tcp-header-flags.xhtml#tcp-header-flags-1) to remove the registration 711 of bit 7 as the NS (Nonce Sum) bit and add an annotation to the 712 registry to state that bit 7 was used by Historic RFC 3540 as the NS 713 (Nonce Sum) bit. 715 9. Security Considerations 717 As a process memo that only relaxes restrictions on experimentation, 718 there are no protocol security considerations, as security 719 considerations for any experiments that take advantage of the relaxed 720 restrictions are discussed in the Internet-Drafts that propose the 721 experiments. 723 However, effective congestion control is crucial to the continued 724 operation of the Internet, and hence this memo places the 725 responsibility for not breaking Internet congestion control on the 726 experiments and the experimenters who propose them. This 727 responsibility includes the requirement to discuss congestion control 728 implications in an IETF document stream Experimental RFC for each 729 experiment, as stated in Section 2.1; review of that discussion by 730 the IETF community and the IESG prior to RFC publication is intended 731 to provide assurance that each experiment does not break Internet 732 congestion control. 734 See Appendix C.1 of [I-D.ietf-tsvwg-ecn-l4s-id] for discussion of 735 alternatives to the ECN nonce. 737 10. References 739 10.1. Normative References 741 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 742 Requirement Levels", BCP 14, RFC 2119, 743 DOI 10.17487/RFC2119, March 1997, 744 . 746 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 747 RFC 2914, DOI 10.17487/RFC2914, September 2000, 748 . 750 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 751 of Explicit Congestion Notification (ECN) to IP", 752 RFC 3168, DOI 10.17487/RFC3168, September 2001, 753 . 755 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 756 Congestion Notification (ECN) Signaling with Nonces", 757 RFC 3540, DOI 10.17487/RFC3540, June 2003, 758 . 760 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 761 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 762 Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 763 2006, . 765 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 766 Datagram Congestion Control Protocol (DCCP) Congestion 767 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 768 DOI 10.17487/RFC4342, March 2006, 769 . 771 [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 772 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate 773 Control for Small Packets (TFRC-SP)", RFC 5622, 774 DOI 10.17487/RFC5622, August 2009, 775 . 777 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 778 and K. Carlberg, "Explicit Congestion Notification (ECN) 779 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 780 2012, . 782 10.2. Informative References 784 [I-D.bagnulo-tcpm-generalized-ecn] 785 Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit 786 Congestion Notification (ECN) to TCP Control Packets", 787 draft-bagnulo-tcpm-generalized-ecn-04 (work in progress), 788 May 2017. 790 [I-D.ietf-tcpm-alternativebackoff-ecn] 791 Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 792 "TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm- 793 alternativebackoff-ecn-01 (work in progress), May 2017. 795 [I-D.ietf-tcpm-dctcp] 796 Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., 797 and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion 798 Control for Datacenters", draft-ietf-tcpm-dctcp-10 (work 799 in progress), August 2017. 801 [I-D.ietf-trill-ecn-support] 802 Eastlake, D. and B. Briscoe, "TRILL: ECN (Explicit 803 Congestion Notification) Support", draft-ietf-trill-ecn- 804 support-03 (work in progress), May 2017. 806 [I-D.ietf-tsvwg-ecn-encap-guidelines] 807 Briscoe, B., Kaippallimalil, J., and P. Thaler, 808 "Guidelines for Adding Congestion Notification to 809 Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- 810 encap-guidelines-09 (work in progress), July 2017. 812 [I-D.ietf-tsvwg-ecn-l4s-id] 813 Schepper, K. and B. Briscoe, "Identifying Modified 814 Explicit Congestion Notification (ECN) Semantics for 815 Ultra-Low Queuing Delay", draft-ietf-tsvwg-ecn-l4s-id-00 816 (work in progress), May 2017. 818 [I-D.ietf-tsvwg-rfc6040update-shim] 819 Briscoe, B., "Propagating Explicit Congestion Notification 820 Across IP Tunnel Headers Separated by a Shim", draft-ietf- 821 tsvwg-rfc6040update-shim-04 (work in progress), July 2017. 823 [I-D.khademi-tsvwg-ecn-response] 824 Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 825 "Updating the Explicit Congestion Notification (ECN) 826 Specification to Allow IETF Experimentation", draft- 827 khademi-tsvwg-ecn-response-01 (work in progress), July 828 2016. 830 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 831 Explicit Congestion Notification (ECN) Field", BCP 124, 832 RFC 4774, DOI 10.17487/RFC4774, November 2006, 833 . 835 [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC 836 Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, 837 July 2007, . 839 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 840 Management of New Protocols and Protocol Extensions", 841 RFC 5706, DOI 10.17487/RFC5706, November 2009, 842 . 844 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 845 Notification", RFC 6040, DOI 10.17487/RFC6040, November 846 2010, . 848 [RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three 849 Pre-Congestion Notification (PCN) States in the IP Header 850 Using a Single Diffserv Codepoint (DSCP)", RFC 6660, 851 DOI 10.17487/RFC6660, July 2012, 852 . 854 [Trammell15] 855 Trammell, B., Kuehlewind, M., Boppart, D., Learmonth, I., 856 Fairhurst, G., and R. Scheffenegger, "Enabling Internet- 857 Wide Deployment of Explicit Congestion Notification". 859 In Proc Passive & Active Measurement (PAM'15) Conference 860 (2015) 862 Appendix A. Change History 864 [To be removed before RFC publication.] 866 Changes from draft-ietf-tsvwg-ecn-experimentation-00 to -01: 868 o Add mention of DCTCP as another protocol that could benefit from 869 ECN experimentation (near end of Section 2). 871 Changes from draft-ietf-tsvwg-ecn-experimentation-01 to -02: 873 o Generalize to describe rationale for areas of experimentation, 874 with less focus on individual experiments 876 o Add ECN terminology section 878 o Change name of "ECT Differences" experimentation area to 879 "Congestion Marking Differences" 881 o Add overlooked RFC 3168 modification to Section 4.1 883 o Clarify text for Experimental RFC exception to ECT(1) non-usage 884 requirement 886 o Add explanation of exception to "SHOULD NOT drop" requirement in 887 4.3 889 o Rework RFC 3540 status change text to provide rationale for a 890 separate status change document that makes RFC 3540 Historic. 891 Don't obsolete RFC 3540. 893 o Significant editorial changes based on reviews by Mirja 894 Kuehlewind, Michael Welzl and Bob Briscoe. 896 Changes from draft-ietf-tsvwg-ecn-experimentation-02 to -03: 898 o Remove change history prior to WG adoption. 900 o Update L4S draft reference to reflect TSVWG adoption of draft. 902 o Change the "SHOULD" for DCCP sender use of ECT(0) to a "MUST" 903 (overlooked in earlier editing). 905 o Other minor edits. 907 Changes from draft-ietf-tsvwg-ecn-experimentation-03 to -04: 909 o Change name of "Generalized ECN" experimentation area to "TCP 910 Control Packets and Retransmissions." 912 o Add IANA Considerations text to request removal of the 913 registration of the NS bit in the TCP header. 915 Changes from draft-ietf-tsvwg-ecn-experimentation-04 to -05: 917 o Minor editorial changes from Area Director review 919 Changes from draft-ietf-tsvwg-ecn-experimentation-05 to -06: 921 o Add summary of RFC 3168 changes to remove the ECN nonce, and use 922 lower-case "nonce" instead of "Nonce" to match RFC 3168 usage. 924 o Add security considerations sentence to indicate that review of 925 Experimental RFCs prior to publication approval is the means to 926 ensure that congestion control is not broken by experiments. 928 o Other minor editorial changes from IETF Last Call 930 Changes from draft-ietf-tsvwg-ecn-experimentation-06 to -07: 932 o Change draft title to make scope clear - this only covers relaxing 933 of restrictions on ECN experimentation. 935 o Any Experimental RFC that takes advantage of this memo has to be 936 in the IETF document stream. 938 o Added sections 2.2 and 2.3 on considerations for other protocols 939 and O&M, relocated discussion of congestion control requirement to 940 section 2.1 from section 4.4 942 o Remove text indicating that ECT(1) may be assigned to L4S - the 943 requirement for an Experimental RFC suffices to ensure that 944 coordination with L4S will occur. 946 o Improve explanation of attack response exception to not dropping 947 packets "solely because the ECN field in the IP header does not 948 contain Not-ECT" in Section 4.3 950 o Fix L4S draft reference for discussion of ECN Nonce alternatives - 951 it's Appendix C.1, not B.1. 953 o Numerous additional editorial changes from IESG Evaluation 955 Author's Address 957 David Black 958 Dell EMC 959 176 South Street 960 Hopkinton, MA 01748 961 USA 963 Email: david.black@dell.com