idnits 2.17.1 draft-briscoe-tsvwg-ecn-l4s-id-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1015 has weird spacing: '...initial even...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o it SHOULD not lead to some packets of a transport-layer flow being served by a different queue from others. -- The document date (October 31, 2016) is 2728 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-black-tsvwg-ecn-experimentation-02 == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-accurate-ecn-02 == Outdated reference: A later version (-07) exists of draft-ietf-tcpm-cubic-02 == Outdated reference: A later version (-10) exists of draft-ietf-tcpm-dctcp-02 == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-ecn-encap-guidelines-07 == Outdated reference: A later version (-06) exists of draft-stewart-tsvwg-sctpecn-05 -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Services (tsv) K. De Schepper 3 Internet-Draft Nokia Bell Labs 4 Intended status: Experimental B. Briscoe, Ed. 5 Expires: May 4, 2017 Simula Research Lab 6 I. Tsang 7 Nokia Bell Labs 8 October 31, 2016 10 Identifying Modified Explicit Congestion Notification (ECN) Semantics 11 for Ultra-Low Queuing Delay 12 draft-briscoe-tsvwg-ecn-l4s-id-02 14 Abstract 16 This specification defines the identifier to be used on IP packets 17 for a new network service called low latency, low loss and scalable 18 throughput (L4S). It is similar to the original (or 'Classic') 19 Explicit Congestion Notification (ECN). 'Classic' ECN marking was 20 required to be equivalent to a drop, both when applied in the network 21 and when responded to by a transport. Unlike 'Classic' ECN marking, 22 for packets carrying the L4S identifier, the network applies marking 23 more immediately and more aggressively than drop, and the transport 24 response to each mark is reduced and smoothed relative to that for 25 drop. The two changes counterbalance each other so that the 26 throughput of an L4S flow will be roughly the same as a 'Classic' 27 flow under the same conditions. However, the much more frequent 28 control signals and the finer responses to them result in ultra-low 29 queuing delay without compromising link utilization, even during high 30 load. Examples of new active queue management (AQM) marking 31 algorithms and examples of new transports (whether TCP-like or real- 32 time) are specified separately. The new L4S identifier is the key 33 piece that enables them to interwork and distinguishes them from 34 'Classic' traffic. It gives an incremental migration path so that 35 existing 'Classic' TCP traffic will be no worse off, but it can be 36 prevented from degrading the ultra-low delay and loss of the new 37 scalable transports. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on May 4, 2017. 56 Copyright Notice 58 Copyright (c) 2016 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.1. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 76 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 2. L4S Packet Identifier . . . . . . . . . . . . . . . . . . . . 6 78 2.1. L4S Packet Identification Requirements . . . . . . . . . 6 79 2.2. L4S Packet Identification . . . . . . . . . . . . . . . . 7 80 2.3. Pre-Requisite Transport Layer Behaviour . . . . . . . . . 8 81 2.4. L4S Packet Identification by Network Nodes with 82 Transport-Layer Awareness . . . . . . . . . . . . . . . . 9 83 2.5. The Meaning of CE Relative to Drop . . . . . . . . . . . 10 84 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 85 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 86 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 87 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 89 6.2. Informative References . . . . . . . . . . . . . . . . . 11 90 Appendix A. Alternative Identifiers . . . . . . . . . . . . . . 15 91 A.1. ECT(1) and CE codepoints . . . . . . . . . . . . . . . . 16 92 A.2. ECN Plus a Diffserv Codepoint (DSCP) . . . . . . . . . . 18 93 A.3. ECN capability alone . . . . . . . . . . . . . . . . . . 20 94 A.4. Protocol ID . . . . . . . . . . . . . . . . . . . . . . . 21 95 A.5. Source or destination addressing . . . . . . . . . . . . 21 96 A.6. Summary: Merits of Alternative Identifiers . . . . . . . 22 98 Appendix B. Potential Competing Uses for the ECT(1) Codepoint . 23 99 B.1. Integrity of Congestion Feedback . . . . . . . . . . . . 23 100 B.2. Notification of Less Severe Congestion than CE . . . . . 24 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 103 1. Introduction 105 This specification defines the identifier to be used on IP packets 106 for a new network service called low latency, low loss and scalable 107 throughput (L4S). It is similar to the original (or 'Classic') 108 Explicit Congestion Notification (ECN). 'Classic' ECN marking was 109 required to be equivalent to a drop, both when applied in the network 110 and when responded to by a transport. Unlike 'Classic' ECN marking, 111 the network applies L4S marking more immediately and more 112 aggressively than drop, and the transport response to each mark is 113 reduced and smoothed relative to that for drop. The two changes 114 counterbalance each other so that the bit-rate of an L4S flow will be 115 roughly the same as a 'Classic' flow under the same conditions. 116 However, the much more frequent control signals and the finer 117 responses to them result in ultra-low queuing delay without 118 compromising link utilization, even during high load. 120 An example of an active queue management (AQM) marking algorithm that 121 enables the L4S service is the DualQ Coupled AQM defined in a 122 complementary specification [I-D.briscoe-aqm-dualq-coupled]. An 123 example of a scalable transport that would enable the L4S service is 124 Data Centre TCP (DCTCP), which until now has been applicable solely 125 to controlled environments like data centres [I-D.ietf-tcpm-dctcp], 126 because it is too aggressive to co-exist with existing TCP. However, 127 AQMs like DualQ Coupled enable scalable transports like DCTCP to co- 128 exist with existing traffic, each getting roughly the same flow rate 129 when they compete under similar conditions. Note that DCTCP will 130 still not be safe to deploy on the Internet until it satisfies the 131 'Safety Additions' listed in Appendix A of 132 [I-D.briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem]. 134 The new L4S identifier is the key piece that enables these two parts 135 to interwork and distinguishes them from 'Classic' traffic. It gives 136 an incremental migration path so that existing 'Classic' TCP traffic 137 will be no worse off, but it can be prevented from degrading the 138 ultra-low delay and loss of the new scalable transports. The 139 performance improvement is so great that it is hoped it will motivate 140 initial deployment of the separate parts of this system. 142 1.1. Problem 144 Latency is becoming the critical performance factor for many (most?) 145 applications on the public Internet, e.g. Web, voice, conversational 146 video, gaming, finance apps, remote desktop and cloud-based 147 applications. In the developed world, further increases in access 148 network bit-rate offer diminishing returns, whereas latency is still 149 a multi-faceted problem. In the last decade or so, much has been 150 done to reduce propagation time by placing caches or servers closer 151 to users. However, queuing remains a major component of latency. 153 The Diffserv architecture provides Expedited Forwarding [RFC3246], so 154 that low latency traffic can jump the queue of other traffic. 155 However, on access links dedicated to individual sites (homes, small 156 enterprises or mobile devices), often all traffic at any one time 157 will be latency-sensitive. Then Diffserv is of little use. Instead, 158 we need to remove the causes of any unnecessary delay. 160 The bufferbloat project has shown that excessively-large buffering 161 ('bufferbloat') has been introducing significantly more delay than 162 the underlying propagation time. These delays appear only 163 intermittently--only when a capacity-seeking (e.g. TCP) flow is long 164 enough for the queue to fill the buffer, making every packet in other 165 flows sharing the buffer sit through the queue. 167 Active queue management (AQM) was originally developed to solve this 168 problem (and others). Unlike Diffserv, which gives low latency to 169 some traffic at the expense of others, AQM controls latency for _all_ 170 traffic in a class. In general, AQMs introduce an increasing level 171 of discard from the buffer the longer the queue persists above a 172 shallow threshold. This gives sufficient signals to capacity-seeking 173 (aka. greedy) flows to keep the buffer empty for its intended 174 purpose: absorbing bursts. However, RED [RFC2309] and other 175 algorithms from the 1990s were sensitive to their configuration and 176 hard to set correctly. So, AQM was not widely deployed. 178 More recent state-of-the-art AQMs, e.g. 179 fq_CoDel [I-D.ietf-aqm-fq-codel], PIE [I-D.ietf-aqm-pie], Adaptive 180 RED [ARED01], are easier to configure, because they define the 181 queuing threshold in time not bytes, so it is invariant for different 182 link rates. However, no matter how good the AQM, the sawtoothing 183 rate of TCP will either cause queuing delay to vary or cause the link 184 to be under-utilized. Even with a perfectly tuned AQM, the 185 additional queuing delay will be of the same order as the underlying 186 speed-of-light delay across the network. Flow-queuing can isolate 187 one flow from another, but it cannot isolate a TCP flow from the 188 delay variations it inflicts on itself, and it has other problems - 189 it overrides the flow rate decisions of variable rate video 190 applications, it does not recognise the flows within IPSec VPN 191 tunnels and it is relatively expensive to implement. 193 Latency is not our only concern: It was known when TCP was first 194 developed that it would not scale to high bandwidth-delay products. 195 Given regular broadband bit-rates over WAN distances are 196 already [RFC3649] beyond the scaling range of 'Classic' TCP Reno, 197 'less unscalable' Cubic [I-D.ietf-tcpm-cubic] and 198 Compound [I-D.sridharan-tcpm-ctcp] variants of TCP have been 199 successfully deployed. However, these are now approaching their 200 scaling limits. Unfortunately, fully scalable TCPs such as DCTCP 201 [I-D.ietf-tcpm-dctcp] cause 'Classic' TCP to starve itself, which is 202 why they have been confined to private data centres or research 203 testbeds (until now). 205 It turns out that a TCP algorithm like DCTCP that solves TCP's 206 scalability problem also solves the latency problem, because the 207 finer sawteeth cause very little queuing delay. A supporting paper 208 [DCttH15] gives the full explanation of why the design solves both 209 the latency and the scaling problems, both in plain English and in 210 more precise mathematical form. The explanation is summarised 211 without the maths in [I-D.briscoe-aqm-dualq-coupled]. 213 1.2. Terminology 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 217 "OPTIONAL" in this document are to be interpreted as described in 218 [RFC2119]. In this document, these words will appear with that 219 interpretation only when in ALL CAPS. Lower case uses of these words 220 are not to be interpreted as carrying RFC-2119 significance. 222 Classic service: The 'Classic' service is intended for all the 223 behaviours that currently co-exist with TCP Reno (e.g. TCP Cubic, 224 Compound, SCTP, etc). 226 Low-Latency, Low-Loss and Scalable (L4S) service: The 'L4S' service 227 is intended for traffic from scalable TCP algorithms such as Data 228 Centre TCP. But it is also more general--it will allow a set of 229 congestion controls with similar scaling properties to DCTCP (e.g. 230 Relentless [Mathis09]) to evolve. 232 Both Classic and L4S services can cope with a proportion of 233 unresponsive or less-responsive traffic as well (e.g. DNS, VoIP, 234 etc). 236 Classic ECN: The original Explicit Congestion Notification (ECN) 237 protocol [RFC3168]. 239 1.3. Scope 241 The new L4S identifier defined in this specification is applicable 242 for IPv4 and IPv6 packets (as for classic ECN [RFC3168]). It is 243 applicable for the unicast, multicast and anycast forwarding modes. 244 It is an orthogonal packet classification to Differentiated Services 245 (Diffserv [RFC2474]), therefore it can be applied to any packet in 246 any Diffserv traffic class. However, as with classic ECN, any 247 particular forwarding node might not implement an active queue 248 management algorithm in all its Diffserv queues. 250 This document is intended for experimental status, so it does not 251 update any standards track RFCs. Therefore it depends on 252 [I-D.black-tsvwg-ecn-experimentation], which proposes to: 254 o update the ECN proposed standard [RFC3168] (in certain specified 255 cases including the present document) to relax the requirement 256 that an ECN mark must be equivalent to a drop, both when applied 257 by the network, and when responded to by the sender; 259 o obsolete the experimental ECN nonce [RFC3540] (see Appendix B.1 260 for rationale); 262 o make consequent updates to the following proposed standard RFCs to 263 reflect the above two bullets: 265 * ECN for RTP [RFC6679]; 267 * the congestion control specifications of various DCCP CCIDs 268 [RFC4341], [RFC4342], [RFC5622]. 270 2. L4S Packet Identifier 272 2.1. L4S Packet Identification Requirements 274 Ideally, the identifier for packets using the Low Latency, Low Loss, 275 Scalable throughput (L4S) service ought to meet the following 276 requirements: 278 o it SHOULD survive end-to-end between source and destination 279 applications: across the boundary between host and network, 280 between interconnected networks, and through middleboxes; 282 o it SHOULD be common to IPv4 and IPv6 and transport agnostic; 284 o it SHOULD be incrementally deployable; 285 o it SHOULD enable an AQM to classify packets encapsulated by outer 286 IP or lower-layer headers; 288 o it SHOULD consume minimal extra codepoints; 290 o it SHOULD not lead to some packets of a transport-layer flow being 291 served by a different queue from others. 293 Whether the identifier would be recoverable if the experiment failed 294 is a factor that could be taken into account. However, this has not 295 been made a requirement, because that would favour schemes that would 296 be easier to fail, rather than those more likely to succeed. 298 It is recognised that the chosen identifier is unlikely to satisfy 299 all these requirements, particularly given the limited space left in 300 the IP header. Therefore a compromise will be necessary, which is 301 why all the requirements are expressed with the word 'SHOULD' not 302 'MUST'. Appendix A discusses the pros and cons of the compromises 303 made in various competing identification schemes against the above 304 requirements. On the basis of this analysis, the "ECT(1) and CE 305 codepoints" is the best compromise. Therefore this scheme is defined 306 in detail in the following section (Section 2.2), while Appendix A 307 has been left to document the rationale for this decision. 309 2.2. L4S Packet Identification 311 The L4S treatment is an alternative packet marking treatment 312 [RFC4774] to the classic ECN treatment [RFC3168]. Like classic ECN, 313 it identifies both network and host behaviour: it identifies the 314 marking treatment that network nodes are expected to apply to L4S 315 packets, and it identifies packets that have been sent from hosts 316 that are expected to comply with a broad type of behaviour. 318 For a packet to receive L4S treatment as it is forwarded, the sender 319 MUST set the ECN field in the IP header (v4 or v6) to the ECT(1) 320 codepoint. 322 A network node that implements the L4S service MUST classify arriving 323 ECT(1) packets for L4S treatment and it SHOULD classify arriving CE 324 packets for L4S treatment as well. Section 2.4 describes a possible 325 exception to this latter rule. 327 The L4S AQM treatment follows similar codepoint transition rules to 328 those in RFC 3168. Specifically, the ECT(1) codepoint MUST NOT be 329 changed to any other codepoint than CE, and CE MUST NOT be changed to 330 any other codepoint. An ECT(1) packet is classified as ECN-capable 331 and, if congestion increases, an L4S AQM algorithm will mark the ECN 332 field as CE for an increasing proportion of packets, otherwise 333 forwarding packets unchanged as ECT(1). The L4S marking treatment is 334 defined in Section 2.5. Under persistent overload conditions, the 335 AQM will follow RFC 3168 and turn off ECN marking, using drop as a 336 congestion signal until the overload episode has subsided. 338 The L4S treatment is the default for ECT(1) packets in all Diffserv 339 Classes [RFC4774]. 341 For backward compatibility in uncontrolled environments, a network 342 node that implements the L4S treatment MUST also implement a classic 343 AQM treatment. It MUST classify arriving ECT(0) and Not-ECT packets 344 for treatment by the Classic AQM. Classic treatment means that the 345 AQM will mark ECT(0) packets under the same conditions as it would 346 drop Not-ECT packets [RFC3168]. 348 2.3. Pre-Requisite Transport Layer Behaviour 350 For a host to send packets with the L4S identifier (ECT(1)), it 351 SHOULD implement a congestion control behaviour that ensures the flow 352 rate is inversely proportional to the proportion of bytes in packets 353 marked with the CE codepoint. This is termed a scalable congestion 354 control, because the number of control signals (ECN marks) per round 355 trip remains roughly constant for any flow rate. As with all 356 transport behaviours, a detailed specification will need to be 357 defined for each type of transport or application, including the 358 timescale over which the proportionality is averaged, and control of 359 burstiness. The inverse proportionality requirement above is worded 360 as a 'SHOULD' rather than a 'MUST' to allow reasonable flexibility 361 when defining these specifications. 363 Data Center TCP (DCTCP [I-D.ietf-tcpm-dctcp]) is an example of a 364 scalable congestion control. 366 Each sender in a session can use a scalable congestion control 367 independently of the congestion control used by the receiver(s) when 368 they send data. Therefore theoretically there might be ECT(1) 369 packets in one direction and ECT(0) in the other. 371 In general, a scalable congestion control needs feedback of the 372 extent of CE marking on the forward path. Due to the history of TCP 373 development, when ECN was added it reported no more than one CE mark 374 per round trip. Some transport protocols derived from TCP mimick 375 this behaviour while others report the extent of TCP marking. This 376 means that some transport protocols will need to be updated as a pre- 377 requisite for scalable congestion control. The position for a few 378 well-known transport protocols is given below. 380 TCP: Support for accurate ECN feedback (AccECN 381 [I-D.ietf-tcpm-accurate-ecn]) by both ends is a pre-requisite for 382 scalable congestion control. However, the reverse does not apply. 383 So even if both ends support AccECN, either of the two ends can 384 choose not to use a scalable congestion control, whatever the 385 other end's choice. Nonetheless, the presence of ECT(1) in the IP 386 headers even in one direction of a TCP connection will imply that 387 both ends support AccECN. 389 SCTP: An ECN feedback protocol such as that specified in 390 [I-D.stewart-tsvwg-sctpecn] would be a pre-requisite for scalable 391 congestion control. That draft would update the ECN feedback 392 protocol sketched out in Appendix A of the standards track 393 specification of SCTP [RFC4960] by adding a field to report the 394 number of CE marks. 396 RTP over UDP: A pre-requisite for scalable congestion control is for 397 both (all) ends of one media-level hop to signal ECN support using 398 the ecn-capable-rtp attribute [RFC6679]. However, the reverse 399 does not apply, so each end of a media-level hop can independently 400 choose not to use a scalable congestion control, even if both ends 401 support ECN. Nonetheless, the presence of ECT(1) implies that 402 both (all) ends of that hop support ECN. 404 DCCP: The ACK vector in DCCP [RFC4340] is already sufficient to 405 report the extent of CE marking as needed by a scalable congestion 406 control. 408 2.4. L4S Packet Identification by Network Nodes with Transport-Layer 409 Awareness 411 To implement the L4S treatment, a network node does not need to 412 identify transport-layer flows. Nonetheless, if an implementer is 413 willing to identify transport-layer flows at a network node, and if 414 the most recent ECT packet in the same flow was ECT(0), the node MAY 415 classify CE packets for classic ECN [RFC3168] treatment. In all 416 other cases, a network node MUST classify CE packets for L4S 417 treatment. Examples of such other cases are: i) if no ECT packets 418 have yet been identified in a flow; ii) if it is not desirable for a 419 network node to identify transport-layer flows; or iii) if the most 420 recent ECT packet in a flow was ECT(1). 422 If an implementer uses flow-awareness to classify CE packets, to 423 determine whether the flow is using ECT(0) or ECT(1) it only uses the 424 most recent ECT packet of a flow {ToDo: this advice will need to be 425 verified experimentally}. This is because a sender might have to 426 switch from sending ECT(1) (L4S) packets to sending ECT(0) (Classic) 427 packets, or back again, in the middle of a transport-layer flow. 429 Such a switch-over is likely to be very rare, but It could be 430 necessary if the path bottleneck moves from a network node that 431 supports L4S to one that only supports Classic ECN. A host ought to 432 be able to detect such a change from a change in RTT variation. 434 2.5. The Meaning of CE Relative to Drop 436 The likelihood that an AQM drops a Not-ECT Classic packet (p_C) MUST 437 be roughly proportional to the square of the likelihood that it would 438 have marked it if it had been an L4S packet (p_L). That is 440 p_C ~= (p_L / k)^2 442 The constant of proportionality (k) does not have to be standardised 443 for interoperability, but a value of 2 is RECOMMENDED. 445 [I-D.briscoe-aqm-dualq-coupled] specifies the essential aspects of an 446 L4S AQM, as well as recommending other aspects. It gives example 447 implementations in appendices. 449 The term 'likelihood' is used above to allow for marking and dropping 450 to be either probabilistic or deterministic. The example AQMs in 451 [I-D.briscoe-aqm-dualq-coupled] drop and mark probabilistically, so 452 the drop probability is arranged to be the square of the marking 453 probability. Nonetheless, an alternative AQM that dropped and marked 454 deterministically would be valid, as long as the dropping frequency 455 was proportional to the square of the marking frequency. 457 Note that, contrary to RFC 3168, an AQM implementing the L4S and 458 Classic treatments does not mark an ECT(1) packet under the same 459 conditions that it would have dropped a Not-ECT packet. However, it 460 does mark an ECT(0) packet under the same conditions that it would 461 have dropped a Not-ECT packet. 463 3. IANA Considerations 465 This specification contains no IANA considerations. 467 4. Security Considerations 469 Two approaches to assure the integrity of signals using the new 470 identifer are introduced in Appendix B.1. 472 5. Acknowledgements 474 Thanks to Richard Scheffenegger, John Leslie, David Taeht, Jonathan 475 Morton, Gorry Fairhurst, Michael Welzl, Mikael Abrahamsson and Andrew 476 McGregor for the discussions that led to this specification. 478 The authors' contributions were part-funded by the European Community 479 under its Seventh Framework Programme through the Reducing Internet 480 Transport Latency (RITE) project (ICT-317700). The views expressed 481 here are solely those of the authors. 483 6. References 485 6.1. Normative References 487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 488 Requirement Levels", BCP 14, RFC 2119, 489 DOI 10.17487/RFC2119, March 1997, 490 . 492 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 493 of Explicit Congestion Notification (ECN) to IP", 494 RFC 3168, DOI 10.17487/RFC3168, September 2001, 495 . 497 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 498 Explicit Congestion Notification (ECN) Field", BCP 124, 499 RFC 4774, DOI 10.17487/RFC4774, November 2006, 500 . 502 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 503 and K. Carlberg, "Explicit Congestion Notification (ECN) 504 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 505 2012, . 507 6.2. Informative References 509 [ARED01] Floyd, S., Gummadi, R., and S. Shenker, "Adaptive RED: An 510 Algorithm for Increasing the Robustness of RED's Active 511 Queue Management", ACIRI Technical Report , August 2001, 512 . 514 [DCttH15] De Schepper, K., Bondarenko, O., Briscoe, B., and I. 515 Tsang, "'Data Centre to the Home': Ultra-Low Latency for 516 All", 2015, . 519 (Under submission) 521 [I-D.bagnulo-tswg-generalized-ecn] 522 Bagnulo, M. and B. Briscoe, "Adding Explicit Congestion 523 Notification (ECN) to TCP control packets", draft-bagnulo- 524 tswg-generalized-ecn-00 (work in progress), July 2016. 526 [I-D.black-tsvwg-ecn-experimentation] 527 Black, D., "Explicit Congestion Notification (ECN) 528 Experimentation", draft-black-tsvwg-ecn-experimentation-02 529 (work in progress), October 2016. 531 [I-D.briscoe-aqm-dualq-coupled] 532 Schepper, K., Briscoe, B., Bondarenko, O., and I. Tsang, 533 "DualQ Coupled AQM for Low Latency, Low Loss and Scalable 534 Throughput", draft-briscoe-aqm-dualq-coupled-01 (work in 535 progress), March 2016. 537 [I-D.briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem] 538 Briscoe, B., Schepper, K., and M. Bagnulo, "Low Latency, 539 Low Loss, Scalable Throughput (L4S) Internet Service: 540 Problem Statement", draft-briscoe-tsvwg-aqm-tcpm-rmcat- 541 l4s-problem-02 (work in progress), July 2016. 543 [I-D.ietf-aqm-fq-codel] 544 Hoeiland-Joergensen, T., McKenney, P., 545 dave.taht@gmail.com, d., Gettys, J., and E. Dumazet, "The 546 FlowQueue-CoDel Packet Scheduler and Active Queue 547 Management Algorithm", draft-ietf-aqm-fq-codel-06 (work in 548 progress), March 2016. 550 [I-D.ietf-aqm-pie] 551 Pan, R., Natarajan, P., Baker, F., and G. White, "PIE: A 552 Lightweight Control Scheme To Address the Bufferbloat 553 Problem", draft-ietf-aqm-pie-10 (work in progress), 554 September 2016. 556 [I-D.ietf-tcpm-accurate-ecn] 557 Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More 558 Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate- 559 ecn-02 (work in progress), October 2016. 561 [I-D.ietf-tcpm-cubic] 562 Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and 563 R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", 564 draft-ietf-tcpm-cubic-02 (work in progress), August 2016. 566 [I-D.ietf-tcpm-dctcp] 567 Bensley, S., Eggert, L., Thaler, D., Balasubramanian, P., 568 and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion 569 Control for Datacenters", draft-ietf-tcpm-dctcp-02 (work 570 in progress), July 2016. 572 [I-D.ietf-tsvwg-ecn-encap-guidelines] 573 Briscoe, B., Kaippallimalil, J., and P. Thaler, 574 "Guidelines for Adding Congestion Notification to 575 Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- 576 encap-guidelines-07 (work in progress), July 2016. 578 [I-D.moncaster-tcpm-rcv-cheat] 579 Moncaster, T., Briscoe, B., and A. Jacquet, "A TCP Test to 580 Allow Senders to Identify Receiver Non-Compliance", draft- 581 moncaster-tcpm-rcv-cheat-03 (work in progress), July 2014. 583 [I-D.sridharan-tcpm-ctcp] 584 Sridharan, M., Tan, K., Bansal, D., and D. Thaler, 585 "Compound TCP: A New TCP Congestion Control for High-Speed 586 and Long Distance Networks", draft-sridharan-tcpm-ctcp-02 587 (work in progress), November 2008. 589 [I-D.stewart-tsvwg-sctpecn] 590 Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream 591 Control Transmission Protocol (SCTP)", draft-stewart- 592 tsvwg-sctpecn-05 (work in progress), January 2014. 594 [Mathis09] 595 Mathis, M., "Relentless Congestion Control", PFLDNeT'09 , 596 May 2009, . 599 [QV] Briscoe, B. and P. Hurtig, "Up to Speed with Queue View", 600 RITE Technical Report D2.3; Appendix C.2, August 2015, 601 . 604 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 605 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 606 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 607 S., Wroclawski, J., and L. Zhang, "Recommendations on 608 Queue Management and Congestion Avoidance in the 609 Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, 610 . 612 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 613 "Definition of the Differentiated Services Field (DS 614 Field) in the IPv4 and IPv6 Headers", RFC 2474, 615 DOI 10.17487/RFC2474, December 1998, 616 . 618 [RFC2983] Black, D., "Differentiated Services and Tunnels", 619 RFC 2983, DOI 10.17487/RFC2983, October 2000, 620 . 622 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 623 J., Courtney, W., Davari, S., Firoiu, V., and D. 624 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 625 Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, 626 . 628 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 629 Congestion Notification (ECN) Signaling with Nonces", 630 RFC 3540, DOI 10.17487/RFC3540, June 2003, 631 . 633 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", 634 RFC 3649, DOI 10.17487/RFC3649, December 2003, 635 . 637 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 638 Congestion Control Protocol (DCCP)", RFC 4340, 639 DOI 10.17487/RFC4340, March 2006, 640 . 642 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 643 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 644 Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 645 2006, . 647 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 648 Datagram Congestion Control Protocol (DCCP) Congestion 649 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 650 DOI 10.17487/RFC4342, March 2006, 651 . 653 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 654 RFC 4960, DOI 10.17487/RFC4960, September 2007, 655 . 657 [RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. 658 Ramakrishnan, "Adding Explicit Congestion Notification 659 (ECN) Capability to TCP's SYN/ACK Packets", RFC 5562, 660 DOI 10.17487/RFC5562, June 2009, 661 . 663 [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 664 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate 665 Control for Small Packets (TFRC-SP)", RFC 5622, 666 DOI 10.17487/RFC5622, August 2009, 667 . 669 [RFC6077] Papadimitriou, D., Ed., Welzl, M., Scharf, M., and B. 670 Briscoe, "Open Research Issues in Internet Congestion 671 Control", RFC 6077, DOI 10.17487/RFC6077, February 2011, 672 . 674 [RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three 675 Pre-Congestion Notification (PCN) States in the IP Header 676 Using a Single Diffserv Codepoint (DSCP)", RFC 6660, 677 DOI 10.17487/RFC6660, July 2012, 678 . 680 [RFC7560] Kuehlewind, M., Ed., Scheffenegger, R., and B. Briscoe, 681 "Problem Statement and Requirements for Increased Accuracy 682 in Explicit Congestion Notification (ECN) Feedback", 683 RFC 7560, DOI 10.17487/RFC7560, August 2015, 684 . 686 [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 687 Concepts, Abstract Mechanism, and Requirements", RFC 7713, 688 DOI 10.17487/RFC7713, December 2015, 689 . 691 [VCP] Xia, Y., Subramanian, L., Stoica, I., and S. Kalyanaraman, 692 "One more bit is enough", Proc. SIGCOMM'05, ACM CCR 693 35(4)37--48, 2005, 694 . 696 Appendix A. Alternative Identifiers 698 This appendix is informative, not normative. It records the pros and 699 cons of various alternative ways to identify L4S packets to record 700 the rationale for the choice of ECT(1) (Appendix A.1) as the L4S 701 identifier. At the end, Appendix A.6 summarises the distinguishing 702 features of the leading alternatives. It is intended to supplement, 703 not replace the detailed text. 705 The leading solutions all use the ECN field, sometimes in combination 706 with the Diffserv field. Both the ECN and Diffserv fields have the 707 additional advantage that they are no different in either IPv4 or 708 IPv6. A couple of alternatives that use other fields are mentioned 709 at the end, but it is quickly explained why they are not serious 710 contenders. 712 A.1. ECT(1) and CE codepoints 714 Definition: 716 Packets with ECT(1) and conditionally packets with CE would 717 signify L4S semantics as an alternative to the semantics of 718 classic ECN [RFC3168], specifically: 720 * The ECT(1) codepoint would signify that the packet was sent by 721 an L4S-capable sender; 723 * Given shortage of codepoints, both L4S and classic ECN sides of 724 an AQM would have to use the same CE codepoint to indicate that 725 a packet had experienced congestion. If a packet that had 726 already been marked CE in an upstream buffer arrived at a 727 subsequent AQM, this AQM would then have to guess whether to 728 classify CE packets as L4S or classic ECN. Choosing the L4S 729 treatment would be a safer choice, because then a few classic 730 packets might arrive early, rather than a few L4S packets 731 arriving late; 733 * Additional information might be available if the classifier 734 were transport-aware. Then it could classify a CE packet for 735 classic ECN treatment if the most recent ECT packet in the same 736 flow had been marked ECT(0). However, the L4S service ought 737 not to need tranport-layer awareness; 739 Cons: 741 Consumes the last ECN codepoint: The L4S service is intended to 742 supersede the service provided by classic ECN, therefore using 743 ECT(1) to identify L4S packets could ultimately mean that the 744 ECT(0) codepoint was 'wasted' purely to distinguish one form of 745 ECN from its successor; 747 ECN hard in some lower layers: It is not always possible to support 748 ECN in an AQM acting in a buffer below the IP layer 749 [I-D.ietf-tsvwg-ecn-encap-guidelines]. In such cases, the L4S 750 service would have to drop rather than mark frames even though 751 they might contain an ECN-capable packet. However, such cases 752 would be unusual. 754 Risk of reordering classic CE packets: Having to classify all CE 755 packets as L4S risks some classic CE packets arriving early, which 756 is a form of reordering. Reordering can cause the TCP sender to 757 retransmit spuriously. However, one or two packets delivered 758 early does not cause any spurious retransmissions because the 759 subsequent packets continue to move the cumulative acknowledgement 760 boundary forwards. Anyway, the risk of reordering would be low, 761 because: i) it is quite unusual to experience more than one 762 bottleneck queue on a path; ii) even then, reordering would only 763 occur if there was simultaneous mixing of classic and L4S traffic, 764 which would be more unlikely in an access link, which is where 765 most bottlenecks are located; iii) even then, spurious 766 retransmissions would only occur if a contiguous sequence of three 767 or more classic CE packets from one bottleneck arrived at the 768 next, which should in itself happen very rarely with a good AQM. 769 The risk would be completely eliminated in AQMs that were 770 transport-aware (but they should not need to be); 772 Non-L4S service for control packets: The classic ECN RFCs [RFC3168] 773 and [RFC5562] require a sender to clear the ECN field to Not-ECT 774 for retransmissions and certain control packets specifically pure 775 ACKs, window probes and SYNs. When L4S packets are classified by 776 the ECN field alone, these control packets would not be classified 777 into an L4S queue, and could therefore be delayed relative to the 778 other packets in the flow. This would not cause re-ordering 779 (because retransmissions are already out of order, and the control 780 packets carry no data). However, it would make critical control 781 packets more vulnerable to loss and delay. To address this 782 problem, [I-D.bagnulo-tswg-generalized-ecn] proposes an experiment 783 in which all TCP control packets and retransmissions are ECN- 784 capable. 786 Pros: 788 Should work e2e: The ECN field generally works end-to-end across the 789 Internet. Unlike the DSCP, the setting of the ECN field is at 790 least forwarded unchanged by networks that do not support ECN, and 791 networks rarely clear it to zero; 793 Should work in tunnels: Unlike Diffserv, ECN is defined to always 794 work across tunnels. However, tunnels do not always implement ECN 795 processing as they should do, particularly because IPsec tunnels 796 were defined differently for a few years. 798 Could migrate to one codepoint: If all classic ECN senders 799 eventually evolve to use the L4S service, the ECT(0) codepoint 800 could be reused for some future purpose, but only once use of 801 ECT(0) packets had reduced to zero, or near-zero, which might 802 never happen. 804 A.2. ECN Plus a Diffserv Codepoint (DSCP) 806 Definition: 808 For packets with a defined DSCP, all codepoints of the ECN field 809 (except Not-ECT) would signify alternative L4S semantics to those 810 for classic ECN [RFC3168], specifically: 812 * The L4S DSCP would signifiy that the packet came from an L4S- 813 capable sender; 815 * ECT(0) and ECT(1) would both signify that the packet was 816 travelling between transport endpoints that were both ECN- 817 capable; 819 * CE would signify that the packet had been marked by an AQM 820 implementing the L4S service. 822 Use of a DSCP is the only approach for alternative ECN semantics 823 given as an example in [RFC4774]. However, it was perhaps considered 824 more for controlled environments than new end-to-end services; 826 Cons: 828 Consumes DSCP pairs: A DSCP is obviously not orthogonal to Diffserv. 829 Therefore, wherever the L4S service is applied to multiple 830 Diffserv scheduling behaviours, it would be necessary to replace 831 each DSCP with a pair of DSCPs. 833 Uses critical lower-layer header space: The resulting increased 834 number of DSCPs might be hard to support for some lower layer 835 technologies, e.g. 802.1p and MPLS both offer only 3-bits for a 836 maximum of 8 traffic class identifiers. Although L4S should 837 reduce and possibly remove the need for some DSCPs intended for 838 differentiated queuing delay, it will not remove the need for 839 Diffserv entirely, because Diffserv is also used to allocate 840 bandwidth, e.g. by prioritising some classes of traffic over 841 others when traffic exceeds available capacity. 843 Not end-to-end (host-network): Very few networks honour a DSCP set 844 by a host. Typically a network will zero (bleach) the Diffserv 845 field from all hosts. Sometimes networks will attempt to identify 846 applications by some form of packet inspection and, based on 847 network policy, they will set the DSCP considered appropriate for 848 the identified application. Network-based application 849 identification might use some combination of protocol ID, port 850 numbers(s), application layer protocol headers, IP address(es), 851 VLAN ID(s) and even packet timing. 853 Not end-to-end (network-network): Very few networks honour a DSCP 854 received from a neighbouring network. Typically a network will 855 zero (bleach) the Diffserv field from all neighbouring networks at 856 an interconnection point. Sometimes bilateral arrangements are 857 made between networks, such that the receiving network remarks 858 some DSCPs to those it uses for roughly equivalent services. The 859 likelihood that a DSCP will be bleached or ignored depends on the 860 type of DSCP: 862 Local-use DSCP: These tend to be used to implement application- 863 specific network policies, but a bilateral arrangement to 864 remark certain DSCPs is often applied to DSCPs in the local-use 865 range simply because it is easier not to change all of a 866 network's internal configurations when a new arrangement is 867 made with a neighbour; 869 Global-use DSCP: These do not tend to be honoured across network 870 interconnections more than local-use DSCPs. However, if two 871 networks decide to honour certain of each other's DSCPs, the 872 reconfiguration is a little easier if both of their globally 873 recognised services are already represented by the relevant 874 global-use DSCPs. 876 Note that today a global-use DSCP gives little more assurance 877 of end-to-end service than a local-use DSCP. In future the 878 global-use range might give more assurance of end-to-end 879 service than local-use, but it is unlikely that either 880 assurance will be high, particularly given the hosts are 881 included in the end-to-end path. 883 Not all tunnels: Diffserv codepoints are often not propagated to the 884 outer header when a packet is encapsulated by a tunnel header. 885 DSCPs are propagated to the outer of uniform mode tunnels, but not 886 pipe mode [RFC2983], and pipe mode is fairly common. 888 ECN hard in some lower layers:: Because this approach uses both the 889 Diffserv and ECN fields, an AQM wil only work at a lower layer if 890 both can be supported. If individual network operators wished to 891 deploy an AQM at a lower layer, they would usually propagate an IP 892 Diffserv codepoint to the lower layer, using for example IEEE 893 802.1p. However, the ECN capability is harder to propagate down 894 to lower layers because few lower layers support it. 896 Pros: 898 Could migrate to e2e: If all usage of classic ECN migrates to usage 899 of L4S, the DSCP would become redundant, and the ECN capability 900 alone could eventually identify L4S packets without the 901 interconnection problems of Diffserv detailed above, and without 902 having permanently consumed more than one codepoint in the IP 903 header. Although the DSCP does not generally function as an end- 904 to-end identifier (see above), it could be used initially by 905 individual ISPs to introduce the L4S service for their own locally 906 generated traffic; 908 A.3. ECN capability alone 910 Definition: 912 This approach uses ECN capability alone as the L4S identifier. It 913 is only feasible if classic ECN is not widely deployed. The 914 specific definition of codepoints would be: 916 * Any ECN codepoint other than Not-ECT would signify an L4S- 917 capable sender; 919 * ECN codepoints would not be used for classic [RFC3168] ECN, and 920 the classic network service would only be used for Not-ECT 921 packets. 923 This approach would only be feasible if 925 A. it was generally agreed that there was little chance of any 926 classic [RFC3168] ECN deployment in any network nodes; 928 B. it was generally agreed that there was little chance of any 929 client devices being deployed with classic [RFC3168] TCP-ECN 930 on by default (note that classic TCP-ECN is already on-by- 931 default on many servers); 933 C. for TCP connections, developers of client OSs would all have 934 to agree not to encourage further deployment of classic ECN. 935 Specifically, at the start of a TCP connection classic ECN 936 could be disabled during negotation of the ECN capability: 938 + an L4S-capable host would have to disable ECN if the 939 corresponding host did not support accurate ECN feedback 940 [RFC7560], which is a prerequisite for the L4S service; 942 + developers of operating systems for user devices would only 943 enable ECN by default for TCP once the stack implemented 944 L4S and accurate ECN feedback [RFC7560] including 945 requesting accurate ECN feedback by default. 947 Cons: 949 Near-infeasible deployment constraints: The constraints for 950 deployment above represent a highly unlikely, but not completely 951 impossible, set of circumstances. If, despite the above measures, 952 a pair of hosts did negotiate to use classic ECN, their packets 953 would be classified into the same queue as L4S traffic, and if 954 they had to compete with a long-running L4S flow they would get a 955 very small capacity share; 957 ECN hard in some lower layers: See the same issue with "ECT(1) and 958 CE codepoints" (Appendix A.1); 960 Non-L4S service for control packets: See the same issue with "ECT(1) 961 and CE codepoints" (Appendix A.1). 963 Pros: 965 Consumes no additional codepoints: The ECT(1) codepoint and all 966 spare Diffserv codepoints would remain available for future use; 968 Should work e2e: As with "ECT(1) and CE codepoints" (Appendix A.1); 970 Should work in tunnels: As with "ECT(1) and CE codepoints" 971 (Appendix A.1). 973 A.4. Protocol ID 975 It has been suggested that a new ID in the IPv4 Protocol field or the 976 IPv6 Next Header field could identify L4S packets. However this 977 approach is ruled out by numerous problems: 979 o A new protocol ID would need to be paired with the old one for 980 each transport (TCP, SCTP, UDP, etc.); 982 o In IPv6, there can be a sequence of Next Header fields, and it 983 would not be obvious which one would be expected to identify a 984 network service like L4S; 986 o A new protocol ID would rarely provide an end-to-end service, 987 because It is well-known that new protocol IDs are often blocked 988 by numerous types of middlebox; 990 o The approach is not a solution for AQMs below the IP layer; 992 A.5. Source or destination addressing 994 Locally, a network operator could arrange for L4S service to be 995 applied based on source or destination addressing, e.g. packets from 996 its own data centre and/or CDN hosts, packets to its business 997 customers, etc. It could use addressing at any layer, e.g. IP 998 addresses, MAC addresses, VLAN IDs, etc. Although addressing might 999 be a useful tactical approach for a single ISP, it would not be a 1000 feasible approach to identify an end-to-end service like L4S. Even 1001 for a single ISP, it would require packet classifiers in buffers to 1002 be dependent on changing topology and address allocation decisions 1003 elsewhere in the network. Therefore this approach is not a feasible 1004 solution. 1006 A.6. Summary: Merits of Alternative Identifiers 1008 Table 1 provides a very high level summary of the pros and cons 1009 detailed against the schemes described respectively in Appendix A.2, 1010 Appendix A.3 and Appendix A.1, for six issues that set them apart. 1012 +--------------+--------------------+---------+--------------------+ 1013 | Issue | DSCP + ECN | ECN | ECT(1) + CE | 1014 +--------------+--------------------+---------+--------------------+ 1015 | | initial eventual | initial | initial eventual | 1016 | | | | | 1017 | end-to-end | N . . . ? . | . . Y | . . Y . . Y | 1018 | tunnels | . O . . O . | . . ? | . . ? . . Y | 1019 | lower layers | N . . . ? . | . O . | . O . . . ? | 1020 | codepoints | N . . . . ? | . . Y | N . . . . ? | 1021 | reordering | . . Y . . Y | . . Y | . O . . . ? | 1022 | ctrl pkts | . . Y . . Y | . O . | . O . . . ? | 1023 | | | | | 1024 | | | Note 1 | | 1025 +--------------+--------------------+---------+--------------------+ 1027 Note 1: Only feasible if classic ECN is obsolete. 1029 Table 1: Comparison of the Merits of Three Alternative Identifiers 1031 The schemes are scored based on both their capabilities now 1032 ('initial') and in the long term ('eventual'). The 'ECN' scheme 1033 shares the 'eventual' scores of the 'ECT(1) + CE' scheme. The scores 1034 are one of 'N, O, Y', meaning 'Poor', 'Ordinary', 'Good' 1035 respectively. The same scores are aligned vertically to aid the eye. 1036 A score of "?" in one of the positions means that this approach might 1037 optimisitically become this good, given sufficient effort. The table 1038 summarises the text and is not meant to be understandable without 1039 having read the text. 1041 Appendix B. Potential Competing Uses for the ECT(1) Codepoint 1043 The ECT(1) codepoint of the ECN field has already been assigned once 1044 for experimental use as the ECN nonce [RFC3540]. ECN is probably the 1045 only remaining field in the Internet Protocol that is common to IPv4 1046 and IPv6 and still has potential to work end-to-end, with tunnels and 1047 with lower layers. Therefore, ECT(1) should not be reassigned to a 1048 different experimental use without carefully assessing competing 1049 potential uses. These fall into the following categories: 1051 B.1. Integrity of Congestion Feedback 1053 Receiving hosts can fool a sender into downloading faster by 1054 suppressing feedback of ECN marks (or of losses if retransmissions 1055 are not necessary or available otherwise). [RFC3540] proposes that a 1056 TCP sender could set either of ECT(0) or ECT(1) in each packet of a 1057 flow and remember the sequence it had set, termed the ECN nonce. If 1058 any packet is lost or congestion marked, the receiver will miss that 1059 bit of the sequence. An ECN Nonce receiver has to feed back the 1060 least significant bit of the sum, so it cannot suppress feedback of a 1061 loss or mark without a 50-50 chance of guessing the sum incorrectly. 1063 As far as is known, the ECN Nonce has never been deployed, and it was 1064 only implemented for a couple of testbed evaluations. It would be 1065 nearly impossible to deploy now, because any misbehaving receiver can 1066 simply opt-out, which would be unremarkable given all receivers 1067 currently opt-out. 1069 Other ways to protect TCP feedback integrity have since been 1070 developed that do not consume any extra codepoints in the base IP 1071 header. For instance: 1073 o the sender can test the integrity of the receiver's feedback by 1074 occasionally setting the IP-ECN field to a value normally only set 1075 by the network. Then it can test whether the receiver's feedback 1076 faithfully reports what it expects [I-D.moncaster-tcpm-rcv-cheat]. 1077 This works for loss and it will work for the accurate ECN feedback 1078 [RFC7560] intended for L4S; 1080 o A network can enforce a congestion response to its ECN markings 1081 (or packet losses) by auditing congestion exposure (ConEx) 1082 [RFC7713]. Whether the receiver or a downstream network is 1083 suppressing congestion feedback or the sender is unresponsive to 1084 the feedback, or both, ConEx audit can neutralise any advantage 1085 that any of these three parties would otherwise gain. 1087 ECN in RTP [RFC6679] is defined so that the receiver can ask the 1088 sender to send all ECT(0); all ECT(1); or both randomly. It 1089 recommends that the receiver asks for ECT(0), which is the default. 1090 The sender can choose to ignore the receiver's request. A rather 1091 complex but optional nonce mechaism was included in early drafts of 1092 RFC 6679, but it was replaced with a statement that a nonce mechanism 1093 is not specified, explaining that misbehaving receivers could opt-out 1094 anyway. RFC 6679 as published gives no rationale for why ECT(1) or 1095 'random' might be needed, but it warns that 'random' would make 1096 header compression highly inefficient. The possibility of using 1097 ECT(1) may have been left in the RFC to allow a nonce mechanism to be 1098 added later. 1100 Therefore, it seems unlikely that anyone has implemented the optional 1101 use of ECT(1) for RTP. Even if they have, it seems even less likely 1102 that any deployment actually uses it. However these assumptions will 1103 need to be verified. 1105 B.2. Notification of Less Severe Congestion than CE 1107 Various researchers have proposed to use ECT(1) as a less severe 1108 congestion notification than CE, particularly to enable flows to fill 1109 available capacity more quickly after an idle period, when another 1110 flow departs or when a flow starts, e.g. VCP [VCP], Queue View (QV) 1111 [QV] {ToDo: consider Jonathan Morton's Explicit Load Regulation (ELR) 1112 if relevant, once the promised write-up appears}. 1114 Before assigning ECT(1) as an identifer for L4S, we must carefully 1115 consider whether it might be better to hold ECT(1) in reserve for 1116 future standardisation of rapid flow acceleration, which is an 1117 important and enduring problem [RFC6077]. 1119 Pre-Congestion Notification (PCN) is another scheme that assigns 1120 alternative semantics to the ECN field. It uses ECT(1) to signify a 1121 less severe level of pre-congestion notification than CE [RFC6660]. 1122 However, the ECN field only takes on the PCN semantics if packets 1123 carry a Diffserv codepoint defined to indicate PCN marking within a 1124 controlled environment. PCN is required to be applied solely to the 1125 outer header of a tunnel across the controlled region in order not to 1126 interfere with any end-to-end use of the ECN field. Therefore a PCN 1127 region on the path would not interfere with any of the L4S service 1128 identifiers proposed in Appendix A. 1130 Authors' Addresses 1131 Koen De Schepper 1132 Nokia Bell Labs 1133 Antwerp 1134 Belgium 1136 Email: koen.de_schepper@nokia.com 1137 URI: https://www.bell-labs.com/usr/koen.de_schepper 1139 Bob Briscoe (editor) 1140 Simula Research Lab 1142 Email: ietf@bobbriscoe.net 1143 URI: http://bobbriscoe.net/ 1145 Ing-jyh Tsang 1146 Nokia Bell Labs 1147 Antwerp 1148 Belgium 1150 Email: ing-jyh.tsang@nokia.com