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