idnits 2.17.1 draft-ietf-tsvwg-l4s-arch-13.txt: -(1658): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 6 instances of lines with non-ascii characters in the document. 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 -- The document date (7 November 2021) is 901 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-briscoe-docsis-q-protection-00 == Outdated reference: A later version (-03) exists of draft-briscoe-iccrg-prague-congestion-control-00 == Outdated reference: A later version (-02) exists of draft-cardwell-iccrg-bbr-congestion-control-00 == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-accurate-ecn-15 == Outdated reference: A later version (-15) exists of draft-ietf-tcpm-generalized-ecn-08 == Outdated reference: A later version (-25) exists of draft-ietf-tsvwg-aqm-dualq-coupled-18 == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-ecn-encap-guidelines-16 == Outdated reference: A later version (-29) exists of draft-ietf-tsvwg-ecn-l4s-id-19 == Outdated reference: A later version (-06) exists of draft-ietf-tsvwg-l4sops-01 == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-nqb-07 == Outdated reference: A later version (-23) exists of draft-ietf-tsvwg-rfc6040update-shim-14 == Outdated reference: A later version (-07) exists of draft-stewart-tsvwg-sctpecn-05 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) -- Obsolete informational reference (is this intentional?): RFC 8312 (Obsoleted by RFC 9438) Summary: 0 errors (**), 0 flaws (~~), 14 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group B. Briscoe, Ed. 3 Internet-Draft Independent 4 Intended status: Informational K. De Schepper 5 Expires: 11 May 2022 Nokia Bell Labs 6 M. Bagnulo Braun 7 Universidad Carlos III de Madrid 8 G. White 9 CableLabs 10 7 November 2021 12 Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: 13 Architecture 14 draft-ietf-tsvwg-l4s-arch-13 16 Abstract 18 This document describes the L4S architecture, which enables Internet 19 applications to achieve Low queuing Latency, Low Loss, and Scalable 20 throughput (L4S). The insight on which L4S is based is that the root 21 cause of queuing delay is in the congestion controllers of senders, 22 not in the queue itself. With the L4S architecture all Internet 23 applications could (but do not have to) transition away from 24 congestion control algorithms that cause substantial queuing delay, 25 to a new class of congestion controls that induce very little 26 queuing, aided by explicit congestion signalling from the network. 27 This new class of congestion controls can provide low latency for 28 capacity-seeking flows, so applications can achieve both high 29 bandwidth and low latency. 31 The architecture primarily concerns incremental deployment. It 32 defines mechanisms that allow the new class of L4S congestion 33 controls to coexist with 'Classic' congestion controls in a shared 34 network. These mechanisms aim to ensure that the latency and 35 throughput performance using an L4S-compliant congestion controller 36 is usually much better (and rarely worse) than performance would have 37 been using a 'Classic' congestion controller, and that competing 38 flows continuing to use 'Classic' controllers are typically not 39 impacted by the presence of L4S. These characteristics are important 40 to encourage adoption of L4S congestion control algorithms and L4S 41 compliant network elements. 43 The L4S architecture consists of three components: network support to 44 isolate L4S traffic from classic traffic; protocol features that 45 allow network elements to identify L4S traffic; and host support for 46 L4S congestion controls. 48 Status of This Memo 50 This Internet-Draft is submitted in full conformance with the 51 provisions of BCP 78 and BCP 79. 53 Internet-Drafts are working documents of the Internet Engineering 54 Task Force (IETF). Note that other groups may also distribute 55 working documents as Internet-Drafts. The list of current Internet- 56 Drafts is at https://datatracker.ietf.org/drafts/current/. 58 Internet-Drafts are draft documents valid for a maximum of six months 59 and may be updated, replaced, or obsoleted by other documents at any 60 time. It is inappropriate to use Internet-Drafts as reference 61 material or to cite them other than as "work in progress." 63 This Internet-Draft will expire on 11 May 2022. 65 Copyright Notice 67 Copyright (c) 2021 IETF Trust and the persons identified as the 68 document authors. All rights reserved. 70 This document is subject to BCP 78 and the IETF Trust's Legal 71 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 72 license-info) in effect on the date of publication of this document. 73 Please review these documents carefully, as they describe your rights 74 and restrictions with respect to this document. Code Components 75 extracted from this document must include Simplified BSD License text 76 as described in Section 4.e of the Trust Legal Provisions and are 77 provided without warranty as described in the Simplified BSD License. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 82 1.1. Document Roadmap . . . . . . . . . . . . . . . . . . . . 5 83 2. L4S Architecture Overview . . . . . . . . . . . . . . . . . . 5 84 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 85 4. L4S Architecture Components . . . . . . . . . . . . . . . . . 9 86 4.1. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 9 87 4.2. Network Components . . . . . . . . . . . . . . . . . . . 10 88 4.3. Host Mechanisms . . . . . . . . . . . . . . . . . . . . . 13 89 5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 5.1. Why These Primary Components? . . . . . . . . . . . . . . 14 91 5.2. What L4S adds to Existing Approaches . . . . . . . . . . 18 92 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 21 93 6.1. Applications . . . . . . . . . . . . . . . . . . . . . . 21 94 6.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 22 95 6.3. Applicability with Specific Link Technologies . . . . . . 23 96 6.4. Deployment Considerations . . . . . . . . . . . . . . . . 24 97 6.4.1. Deployment Topology . . . . . . . . . . . . . . . . . 24 98 6.4.2. Deployment Sequences . . . . . . . . . . . . . . . . 26 99 6.4.3. L4S Flow but Non-ECN Bottleneck . . . . . . . . . . . 28 100 6.4.4. L4S Flow but Classic ECN Bottleneck . . . . . . . . . 29 101 6.4.5. L4S AQM Deployment within Tunnels . . . . . . . . . . 30 102 7. IANA Considerations (to be removed by RFC Editor) . . . . . . 30 103 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 104 8.1. Traffic Rate (Non-)Policing . . . . . . . . . . . . . . . 30 105 8.2. 'Latency Friendliness' . . . . . . . . . . . . . . . . . 31 106 8.3. Interaction between Rate Policing and L4S . . . . . . . . 33 107 8.4. ECN Integrity . . . . . . . . . . . . . . . . . . . . . . 34 108 8.5. Privacy Considerations . . . . . . . . . . . . . . . . . 34 109 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 110 10. Informative References . . . . . . . . . . . . . . . . . . . 35 111 Appendix A. Standardization items . . . . . . . . . . . . . . . 45 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 114 1. Introduction 116 At any one time, it is increasingly common for all of the traffic in 117 a bottleneck link (e.g. a household's Internet access) to come from 118 applications that prefer low delay: interactive Web, Web services, 119 voice, conversational video, interactive video, interactive remote 120 presence, instant messaging, online gaming, remote desktop, cloud- 121 based applications and video-assisted remote control of machinery and 122 industrial processes. In the last decade or so, much has been done 123 to reduce propagation delay by placing caches or servers closer to 124 users. However, queuing remains a major, albeit intermittent, 125 component of latency. For instance spikes of hundreds of 126 milliseconds are not uncommon, even with state-of-the-art active 127 queue management (AQM) [COBALT], [DOCSIS3AQM]. Queuing in access 128 network bottlenecks is typically configured to cause overall network 129 delay to roughly double during a long-running flow, relative to 130 expected base (unloaded) path delay [BufferSize]. Low loss is also 131 important because, for interactive applications, losses translate 132 into even longer retransmission delays. 134 It has been demonstrated that, once access network bit rates reach 135 levels now common in the developed world, increasing capacity offers 136 diminishing returns if latency (delay) is not addressed 137 [Dukkipati15], [Rajiullah15]. Therefore, the goal is an Internet 138 service with very Low queueing Latency, very Low Loss and Scalable 139 throughput (L4S). Very low queuing latency means less than 140 1 millisecond (ms) on average and less than about 2 ms at the 99th 141 percentile. This document describes the L4S architecture for 142 achieving these goals. 144 Differentiated services (Diffserv) offers Expedited Forwarding 145 (EF [RFC3246]) for some packets at the expense of others, but this 146 makes no difference when all (or most) of the traffic at a bottleneck 147 at any one time requires low latency. In contrast, L4S still works 148 well when all traffic is L4S - a service that gives without taking 149 needs none of the configuration or management baggage (traffic 150 policing, traffic contracts) associated with favouring some traffic 151 flows over others. 153 Queuing delay degrades performance intermittently [Hohlfeld14]. It 154 occurs when a large enough capacity-seeking (e.g. TCP) flow is 155 running alongside the user's traffic in the bottleneck link, which is 156 typically in the access network. Or when the low latency application 157 is itself a large capacity-seeking or adaptive rate (e.g. interactive 158 video) flow. At these times, the performance improvement from L4S 159 must be sufficient that network operators will be motivated to deploy 160 it. 162 Active Queue Management (AQM) is part of the solution to queuing 163 under load. AQM improves performance for all traffic, but there is a 164 limit to how much queuing delay can be reduced by solely changing the 165 network; without addressing the root of the problem. 167 The root of the problem is the presence of standard TCP congestion 168 control (Reno [RFC5681]) or compatible variants (e.g. TCP 169 Cubic [RFC8312]). We shall use the term 'Classic' for these Reno- 170 friendly congestion controls. Classic congestion controls induce 171 relatively large saw-tooth-shaped excursions up the queue and down 172 again, which have been growing as flow rate scales [RFC3649]. So if 173 a network operator naively attempts to reduce queuing delay by 174 configuring an AQM to operate at a shallower queue, a Classic 175 congestion control will significantly underutilize the link at the 176 bottom of every saw-tooth. 178 It has been demonstrated that if the sending host replaces a Classic 179 congestion control with a 'Scalable' alternative, when a suitable AQM 180 is deployed in the network the performance under load of all the 181 above interactive applications can be significantly improved. For 182 instance, queuing delay under heavy load with the example DCTCP/DualQ 183 solution cited below on a DSL or Ethernet link is roughly 1 to 2 184 milliseconds at the 99th percentile without losing link 185 utilization [DualPI2Linux], [DCttH19] (for other link types, see 186 Section 6.3). This compares with 5-20 ms on _average_ with a Classic 187 congestion control and current state-of-the-art AQMs such as FQ- 188 CoDel [RFC8290], PIE [RFC8033] or DOCSIS PIE [RFC8034] and about 189 20-30 ms at the 99th percentile [DualPI2Linux]. 191 L4S is designed for incremental deployment. It is possible to deploy 192 the L4S service at a bottleneck link alongside the existing best 193 efforts service [DualPI2Linux] so that unmodified applications can 194 start using it as soon as the sender's stack is updated. Access 195 networks are typically designed with one link as the bottleneck for 196 each site (which might be a home, small enterprise or mobile device), 197 so deployment at either or both ends of this link should give nearly 198 all the benefit in the respective direction. With some transport 199 protocols, namely TCP and SCTP, the sender has to check for suitably 200 updated receiver feedback, whereas with more recent transport 201 protocols such as QUIC and DCCP, all receivers have always been 202 suitable. 204 This document presents the L4S architecture, by describing and 205 justifying the component parts and how they interact to provide the 206 scalable, low latency, low loss Internet service. It also details 207 the approach to incremental deployment, as briefly summarized above. 209 1.1. Document Roadmap 211 This document describes the L4S architecture in three passes. First 212 this brief overview gives the very high level idea and states the 213 main components with minimal rationale. This is only intended to 214 give some context for the terminology definitions that follow in 215 Section 3, and to explain the structure of the rest of the document. 216 Then Section 4 goes into more detail on each component with some 217 rationale, but still mostly stating what the architecture is, rather 218 than why. Finally Section 5 justifies why each element of the 219 solution was chosen (Section 5.1) and why these choices were 220 different from other solutions (Section 5.2). 222 Having described the architecture, Section 6 clarifies its 223 applicability; that is, the applications and use-cases that motivated 224 the design, the challenges applying the architecture to various link 225 technologies, and various incremental deployment models: including 226 the two main deployment topologies, different sequences for 227 incremental deployment and various interactions with pre-existing 228 approaches. The document ends with the usual tail pieces, including 229 extensive discussion of traffic policing and other security 230 considerations Section 8. 232 2. L4S Architecture Overview 234 Below we outline the three main components to the L4S architecture; 235 1) the scalable congestion control on the sending host; 2) the AQM at 236 the network bottleneck; and 3) the protocol between them. 238 But first, the main point to grasp is that low latency is not 239 provided by the network - low latency results from the careful 240 behaviour of the scalable congestion controllers used by L4S senders. 241 The network does have a role - primarily to isolate the low latency 242 of the carefully behaving L4S traffic from the higher queuing delay 243 needed by traffic with pre-existing Classic behaviour. The network 244 also alters the way it signals queue growth to the transport - It 245 uses the Explicit Congestion Notification (ECN) protocol, but it 246 signals the very start of queue growth - immediately without the 247 smoothing delay typical of Classic AQMs. Because ECN support is 248 essential for L4S, senders use the ECN field as the protocol to 249 identify to the network which packets are L4S and which are Classic. 251 1) Host: Scalable congestion controls already exist. They solve the 252 scaling problem with Classic congestion controls, such as Reno or 253 Cubic. Because flow rate has scaled since TCP congestion control 254 was first designed in 1988, assuming the flow lasts long enough, 255 it now takes hundreds of round trips (and growing) to recover 256 after a congestion signal (whether a loss or an ECN mark) as shown 257 in the examples in Section 5.1 and [RFC3649]. Therefore control 258 of queuing and utilization becomes very slack, and the slightest 259 disturbances (e.g. from new flows starting) prevent a high rate 260 from being attained. 262 With a scalable congestion control, the average time from one 263 congestion signal to the next (the recovery time) remains 264 invariant as the flow rate scales, all other factors being equal. 265 This maintains the same degree of control over queueing and 266 utilization whatever the flow rate, as well as ensuring that high 267 throughput is more robust to disturbances. The scalable control 268 used most widely (in controlled environments) is Data Center TCP 269 (DCTCP [RFC8257]), which has been implemented and deployed in 270 Windows Server Editions (since 2012), in Linux and in FreeBSD. 271 Although DCTCP as-is functions well over wide-area round trip 272 times, most implementations lack certain safety features that 273 would be necessary for use outside controlled environments like 274 data centres (see Section 6.4.3 and Appendix A). So scalable 275 congestion control needs to be implemented in TCP and other 276 transport protocols (QUIC, SCTP, RTP/RTCP, RMCAT, etc.). Indeed, 277 between the present document being drafted and published, the 278 following scalable congestion controls were implemented: TCP 279 Prague [PragueLinux], QUIC Prague, an L4S variant of the RMCAT 280 SCReAM controller [SCReAM] and the L4S ECN part of BBRv2 [BBRv2] 281 intended for TCP and QUIC transports. 283 2) Network: L4S traffic needs to be isolated from the queuing 284 latency of Classic traffic. One queue per application flow (FQ) 285 is one way to achieve this, e.g. FQ-CoDel [RFC8290]. However, 286 just two queues is sufficient and does not require inspection of 287 transport layer headers in the network, which is not always 288 possible (see Section 5.2). With just two queues, it might seem 289 impossible to know how much capacity to schedule for each queue 290 without inspecting how many flows at any one time are using each. 291 And it would be undesirable to arbitrarily divide access network 292 capacity into two partitions. The Dual Queue Coupled AQM was 293 developed as a minimal complexity solution to this problem. It 294 acts like a 'semi-permeable' membrane that partitions latency but 295 not bandwidth. As such, the two queues are for transition from 296 Classic to L4S behaviour, not bandwidth prioritization. 298 Section 4 gives a high level explanation of how the per-flow-queue 299 (FQ) and DualQ variants of L4S work, and 300 [I-D.ietf-tsvwg-aqm-dualq-coupled] gives a full explanation of the 301 DualQ Coupled AQM framework. A specific marking algorithm is not 302 mandated for L4S AQMs. Appendices of 303 [I-D.ietf-tsvwg-aqm-dualq-coupled] give non-normative examples 304 that have been implemented and evaluated, and give recommended 305 default parameter settings. It is expected that L4S experiments 306 will improve knowledge of parameter settings and whether the set 307 of marking algorithms needs to be limited. 309 3) Protocol: A host needs to distinguish L4S and Classic packets 310 with an identifier so that the network can classify them into 311 their separate treatments. [I-D.ietf-tsvwg-ecn-l4s-id] concludes 312 that all alternatives involve compromises, but the ECT(1) and CE 313 codepoints of the ECN field represent a workable solution. As 314 already explained, the network also uses ECN to immediately signal 315 the very start of queue growth to the transport. 317 3. Terminology 319 Classic Congestion Control: A congestion control behaviour that can 320 co-exist with standard Reno [RFC5681] without causing 321 significantly negative impact on its flow rate [RFC5033]. The 322 scaling problem with Classic congestion control is explained, with 323 examples, in Section 5.1 and in [RFC3649]. 325 Scalable Congestion Control: A congestion control where the average 326 time from one congestion signal to the next (the recovery time) 327 remains invariant as the flow rate scales, all other factors being 328 equal. For instance, DCTCP averages 2 congestion signals per 329 round-trip whatever the flow rate, as do other recently developed 330 scalable congestion controls, e.g. Relentless TCP [Mathis09], TCP 331 Prague [I-D.briscoe-iccrg-prague-congestion-control], 332 [PragueLinux], BBRv2 [BBRv2] and the L4S variant of SCReAM for 333 real-time media [SCReAM], [RFC8298]). See Section 4.3 of 334 [I-D.ietf-tsvwg-ecn-l4s-id] for more explanation. 336 Classic service: The Classic service is intended for all the 337 congestion control behaviours that co-exist with Reno [RFC5681] 338 (e.g. Reno itself, Cubic [RFC8312], 339 Compound [I-D.sridharan-tcpm-ctcp], TFRC [RFC5348]). The term 340 'Classic queue' means a queue providing the Classic service. 342 Low-Latency, Low-Loss Scalable throughput (L4S) service: The 'L4S' 343 service is intended for traffic from scalable congestion control 344 algorithms, such as the Prague congestion 345 control [I-D.briscoe-iccrg-prague-congestion-control], which was 346 derived from DCTCP [RFC8257]. The L4S service is for more 347 general traffic than just TCP Prague--it allows the set of 348 congestion controls with similar scaling properties to Prague to 349 evolve, such as the examples listed above (Relentless, SCReAM). 350 The term 'L4S queue' means a queue providing the L4S service. 352 The terms Classic or L4S can also qualify other nouns, such as 353 'queue', 'codepoint', 'identifier', 'classification', 'packet', 354 'flow'. For example: an L4S packet means a packet with an L4S 355 identifier sent from an L4S congestion control. 357 Both Classic and L4S services can cope with a proportion of 358 unresponsive or less-responsive traffic as well, but in the L4S 359 case its rate has to be smooth enough or low enough not build a 360 queue (e.g. DNS, VoIP, game sync datagrams, etc). 362 Reno-friendly: The subset of Classic traffic that is friendly to the 363 standard Reno congestion control defined for TCP in [RFC5681]. 364 Reno-friendly is used in place of 'TCP-friendly', given the latter 365 has become imprecise, because the TCP protocol is now used with so 366 many different congestion control behaviours, and Reno is used in 367 non-TCP transports such as QUIC [RFC9000]. 369 Classic ECN: The original Explicit Congestion Notification (ECN) 370 protocol [RFC3168], which requires ECN signals to be treated as 371 equivalent to drops, both when generated in the network and when 372 responded to by the sender. 374 L4S uses the ECN field as an identifier 375 [I-D.ietf-tsvwg-ecn-l4s-id] with the names for the four codepoints 376 of the 2-bit IP-ECN field unchanged from those defined in 377 [RFC3168]: Not ECT, ECT(0), ECT(1) and CE, where ECT stands for 378 ECN-Capable Transport and CE stands for Congestion Experienced. A 379 packet marked with the CE codepoint is termed 'ECN-marked' or 380 sometimes just 'marked' where the context makes ECN obvious. 382 Site: A home, mobile device, small enterprise or campus, where the 383 network bottleneck is typically the access link to the site. Not 384 all network arrangements fit this model but it is a useful, widely 385 applicable generalization. 387 4. L4S Architecture Components 389 The L4S architecture is composed of the elements in the following 390 three subsections. 392 4.1. Protocol Mechanisms 394 The L4S architecture involves: a) unassignment of an identifier; b) 395 reassignment of the same identifier; and c) optional further 396 identifiers: 398 a. An essential aspect of a scalable congestion control is the use 399 of explicit congestion signals. 'Classic' ECN [RFC3168] requires 400 an ECN signal to be treated as equivalent to drop, both when it 401 is generated in the network and when it is responded to by hosts. 402 L4S needs networks and hosts to support a more fine-grained 403 meaning for each ECN signal that is less severe than a drop, so 404 that the L4S signals: 406 * can be much more frequent; 408 * can be signalled immediately, without the significant delay 409 required to smooth out fluctuations in the queue. 411 To enable L4S, the standards track [RFC3168] has had to be 412 updated to allow L4S packets to depart from the 'equivalent to 413 drop' constraint. [RFC8311] is a standards track update to relax 414 specific requirements in RFC 3168 (and certain other standards 415 track RFCs), which clears the way for the experimental changes 416 proposed for L4S. [RFC8311] also reclassifies the original 417 experimental assignment of the ECT(1) codepoint as an ECN 418 nonce [RFC3540] as historic. 420 b. [I-D.ietf-tsvwg-ecn-l4s-id] specifies that ECT(1) is used as the 421 identifier to classify L4S packets into a separate treatment from 422 Classic packets. This satisfies the requirement for identifying 423 an alternative ECN treatment in [RFC4774]. 425 The CE codepoint is used to indicate Congestion Experienced by 426 both L4S and Classic treatments. This raises the concern that a 427 Classic AQM earlier on the path might have marked some ECT(0) 428 packets as CE. Then these packets will be erroneously classified 429 into the L4S queue. Appendix B of [I-D.ietf-tsvwg-ecn-l4s-id] 430 explains why five unlikely eventualities all have to coincide for 431 this to have any detrimental effect, which even then would only 432 involve a vanishingly small likelihood of a spurious 433 retransmission. 435 c. A network operator might wish to include certain unresponsive, 436 non-L4S traffic in the L4S queue if it is deemed to be smoothly 437 enough paced and low enough rate not to build a queue. For 438 instance, VoIP, low rate datagrams to sync online games, 439 relatively low rate application-limited traffic, DNS, LDAP, etc. 440 This traffic would need to be tagged with specific identifiers, 441 e.g. a low latency Diffserv Codepoint such as Expedited 442 Forwarding (EF [RFC3246]), Non-Queue-Building 443 (NQB [I-D.ietf-tsvwg-nqb]), or operator-specific identifiers. 445 4.2. Network Components 447 The L4S architecture aims to provide low latency without the _need_ 448 for per-flow operations in network components. Nonetheless, the 449 architecture does not preclude per-flow solutions. The following 450 bullets describe the known arrangements: a) the DualQ Coupled AQM 451 with an L4S AQM in one queue coupled from a Classic AQM in the other; 452 b) Per-Flow Queues with an instance of a Classic and an L4S AQM in 453 each queue; c) Dual queues with per-flow AQMs, but no per-flow 454 queues: 456 a. The Dual Queue Coupled AQM (illustrated in Figure 1) achieves the 457 'semi-permeable' membrane property mentioned earlier as follows: 459 * Latency isolation: Two separate queues are used to isolate L4S 460 queuing delay from the larger queue that Classic traffic needs 461 to maintain full utilization. 463 * Bandwidth pooling: The two queues act as if they are a single 464 pool of bandwidth in which flows of either type get roughly 465 equal throughput without the scheduler needing to identify any 466 flows. This is achieved by having an AQM in each queue, but 467 the Classic AQM provides a congestion signal to both queues in 468 a manner that ensures a consistent response from the two 469 classes of congestion control. Specifically, the Classic AQM 470 generates a drop/mark probability based on congestion in its 471 own queue, which it uses both to drop/mark packets in its own 472 queue and to affect the marking probability in the L4S queue. 473 The strength of the coupling of the congestion signalling 474 between the two queues is enough to make the L4S flows slow 475 down to leave the right amount of capacity for the Classic 476 flows (as they would if they were the same type of traffic 477 sharing the same queue). 479 Then the scheduler can serve the L4S queue with priority (denoted 480 by the '1' on the higher priority input), because the L4S traffic 481 isn't offering up enough traffic to use all the priority that it 482 is given. Therefore: 484 * for latency isolation on short time-scales (sub-round-trip) 485 the prioritization of the L4S queue protects its low latency 486 by allowing bursts to dissipate quickly; 488 * but for bandwidth pooling on longer time-scales (round-trip 489 and longer) the Classic queue creates an equal and opposite 490 pressure against the L4S traffic to ensure that neither has 491 priority when it comes to bandwidth - the tension between 492 prioritizing L4S and coupling the marking from the Classic AQM 493 results in approximate per-flow fairness. 495 To protect against unresponsive traffic taking advantage of the 496 prioritization of the L4S queue and starving the Classic queue, 497 it is advisable for the priority to be conditional, not strict 498 (see Appendix A of [I-D.ietf-tsvwg-aqm-dualq-coupled]). 500 When there is no Classic traffic, the L4S queue's own AQM comes 501 into play. It starts congestion marking with a very shallow 502 queue, so L4S traffic maintains very low queuing delay. 504 If either queue becomes persistently overloaded, ECN marking is 505 disabled, as recommended in Section 7 of [RFC3168] and 506 Section 4.2.1 of [RFC7567]. Then both queues introduce the same 507 level of drop (not shown in the figure). 509 The Dual Queue Coupled AQM has been specified as generically as 510 possible [I-D.ietf-tsvwg-aqm-dualq-coupled] without specifying 511 the particular AQMs to use in the two queues so that designers 512 are free to implement diverse ideas. Informational appendices in 513 that draft give pseudocode examples of two different specific AQM 514 approaches: one called DualPI2 (pronounced Dual PI 515 Squared) [DualPI2Linux] that uses the PI2 variant of PIE, and a 516 zero-config variant of RED called Curvy RED. A DualQ Coupled AQM 517 based on PIE has also been specified and implemented for Low 518 Latency DOCSIS [DOCSIS3.1]. 520 (3) (2) 521 .-------^------. .--------------^-------------------. 522 ,-(1)-----. ______ 523 ; ________ : L4S --------. | | 524 :|Scalable| : _\ ||___\_| mark | 525 :| sender | : __________ / / || / |______|\ _________ 526 :|________|\; | |/ --------' ^ \1|condit'nl| 527 `---------'\_| IP-ECN | Coupling : \|priority |_\ 528 ________ / |Classifier| : /|scheduler| / 529 |Classic |/ |__________|\ --------. ___:__ / |_________| 530 | sender | \_\ || | |||___\_| mark/|/ 531 |________| / || | ||| / | drop | 532 Classic --------' |______| 534 Figure 1: Components of an L4S DualQ Coupled AQM Solution: 1) 535 Scalable Sending Host; 2) Isolation in separate network 536 queues; and 3) Packet Identification Protocol 538 b. Per-Flow Queues and AQMs: A scheduler with per-flow queues such 539 as FQ-CoDel or FQ-PIE can be used for L4S. For instance within 540 each queue of an FQ-CoDel system, as well as a CoDel AQM, there 541 is typically also the option of ECN marking at an immediate 542 (unsmoothed) shallow threshold to support use in data centres 543 (see Sec.5.2.7 of [RFC8290]). In Linux, this has been modified 544 so that the shallow threshold can be solely applied to ECT(1) 545 packets [FQ_CoDel_Thresh]. Then if there is a flow of non-ECN or 546 ECT(0) packets in the per-flow-queue, the Classic AQM (e.g. 547 CoDel) is applied; while if there is a flow of ECT(1) packets in 548 the queue, the shallower (typically sub-millisecond) threshold is 549 applied. In addition, ECT(0) and not-ECT packets could 550 potentially be classified into a separate flow-queue from ECT(1) 551 and CE packets to avoid them mixing if they share a common flow- 552 identifier (e.g. in a VPN). 554 c. Dual-queues, but per-flow AQMs: It should also be possible to use 555 dual queues for isolation, but with per-flow marking to control 556 flow-rates (instead of the coupled per-queue marking of the Dual 557 Queue Coupled AQM). One of the two queues would be for isolating 558 L4S packets, which would be classified by the ECN codepoint. 559 Flow rates could be controlled by flow-specific marking. The 560 policy goal of the marking could be to differentiate flow rates 561 (e.g. [Nadas20], which requires additional signalling of a per- 562 flow 'value'), or to equalize flow-rates (perhaps in a similar 563 way to Approx Fair CoDel [AFCD], 564 [I-D.morton-tsvwg-codel-approx-fair], but with two queues not 565 one). 567 Note that whenever the term 'DualQ' is used loosely without 568 saying whether marking is per-queue or per-flow, it means a dual 569 queue AQM with per-queue marking. 571 4.3. Host Mechanisms 573 The L4S architecture includes two main mechanisms in the end host 574 that we enumerate next: 576 a. Scalable Congestion Control at the sender: Section 2 defines a 577 scalable congestion control as one where the average time from 578 one congestion signal to the next (the recovery time) remains 579 invariant as the flow rate scales, all other factors being equal. 580 Data Center TCP is the most widely used example. It has been 581 documented as an informational record of the protocol currently 582 in use in controlled environments [RFC8257]. A draft list of 583 safety and performance improvements for a scalable congestion 584 control to be usable on the public Internet has been drawn up 585 (the so-called 'Prague L4S requirements' in Appendix A of 586 [I-D.ietf-tsvwg-ecn-l4s-id]). The subset that involve risk of 587 harm to others have been captured as normative requirements in 588 Section 4 of [I-D.ietf-tsvwg-ecn-l4s-id]. TCP 589 Prague [I-D.briscoe-iccrg-prague-congestion-control] has been 590 implemented in Linux as a reference implementation to address 591 these requirements [PragueLinux]. 593 Transport protocols other than TCP use various congestion 594 controls that are designed to be friendly with Reno. Before they 595 can use the L4S service, they will need to be updated to 596 implement a scalable congestion response, which they will have to 597 indicate by using the ECT(1) codepoint. Scalable variants are 598 under consideration for more recent transport protocols, 599 e.g. QUIC, and the L4S ECN part of BBRv2 [BBRv2] is a scalable 600 congestion control intended for the TCP and QUIC transports, 601 amongst others. Also an L4S variant of the RMCAT SCReAM 602 controller [RFC8298] has been implemented [SCReAM] for media 603 transported over RTP. 605 Section 4.3 of [I-D.ietf-tsvwg-ecn-l4s-id] defines scalable 606 congestion control in more detail, and specifies that 607 requirements that an L4S scalable congestion control has to 608 comply with. 610 b. The ECN feedback in some transport protocols is already 611 sufficiently fine-grained for L4S (specifically DCCP [RFC4340] 612 and QUIC [RFC9000]). But others either require update or are in 613 the process of being updated: 615 * For the case of TCP, the feedback protocol for ECN embeds the 616 assumption from Classic ECN [RFC3168] that an ECN mark is 617 equivalent to a drop, making it unusable for a scalable TCP. 618 Therefore, the implementation of TCP receivers will have to be 619 upgraded [RFC7560]. Work to standardize and implement more 620 accurate ECN feedback for TCP (AccECN) is in 621 progress [I-D.ietf-tcpm-accurate-ecn], [PragueLinux]. 623 * ECN feedback is only roughly sketched in an appendix of the 624 SCTP specification [RFC4960]. A fuller specification has been 625 proposed in a long-expired draft [I-D.stewart-tsvwg-sctpecn], 626 which would need to be implemented and deployed before SCTCP 627 could support L4S. 629 * For RTP, sufficient ECN feedback was defined in [RFC6679], but 630 [RFC8888] defines the latest standards track improvements. 632 5. Rationale 634 5.1. Why These Primary Components? 636 Explicit congestion signalling (protocol): Explicit congestion 637 signalling is a key part of the L4S approach. In contrast, use of 638 drop as a congestion signal creates a tension because drop is both 639 an impairment (less would be better) and a useful signal (more 640 would be better): 642 * Explicit congestion signals can be used many times per round 643 trip, to keep tight control, without any impairment. Under 644 heavy load, even more explicit signals can be applied so the 645 queue can be kept short whatever the load. In contrast, 646 Classic AQMs have to introduce very high packet drop at high 647 load to keep the queue short. By using ECN, an L4S congestion 648 control's sawtooth reduction can be smaller and therefore 649 return to the operating point more often, without worrying that 650 more sawteeth will cause more signals. The consequent smaller 651 amplitude sawteeth fit between an empty queue and a very 652 shallow marking threshold (~1 ms in the public Internet), so 653 queue delay variation can be very low, without risk of under- 654 utilization. 656 * Explicit congestion signals can be emitted immediately to track 657 fluctuations of the queue. L4S shifts smoothing from the 658 network to the host. The network doesn't know the round trip 659 times of any of the flows. So if the network is responsible 660 for smoothing (as in the Classic approach), it has to assume a 661 worst case RTT, otherwise long RTT flows would become unstable. 662 This delays Classic congestion signals by 100-200 ms. In 663 contrast, each host knows its own round trip time. So, in the 664 L4S approach, the host can smooth each flow over its own RTT, 665 introducing no more soothing delay than strictly necessary 666 (usually only a few milliseconds). A host can also choose not 667 to introduce any smoothing delay if appropriate, e.g. during 668 flow start-up. 670 Neither of the above are feasible if explicit congestion 671 signalling has to be considered 'equivalent to drop' (as was 672 required with Classic ECN [RFC3168]), because drop is an 673 impairment as well as a signal. So drop cannot be excessively 674 frequent, and drop cannot be immediate, otherwise too many drops 675 would turn out to have been due to only a transient fluctuation in 676 the queue that would not have warranted dropping a packet in 677 hindsight. Therefore, in an L4S AQM, the L4S queue uses a new L4S 678 variant of ECN that is not equivalent to drop (see section 5.2 of 679 [I-D.ietf-tsvwg-ecn-l4s-id]), while the Classic queue uses either 680 Classic ECN [RFC3168] or drop, which are equivalent to each other. 682 Before Classic ECN was standardized, there were various proposals 683 to give an ECN mark a different meaning from drop. However, there 684 was no particular reason to agree on any one of the alternative 685 meanings, so 'equivalent to drop' was the only compromise that 686 could be reached. RFC 3168 contains a statement that: 688 "An environment where all end nodes were ECN-Capable could 689 allow new criteria to be developed for setting the CE 690 codepoint, and new congestion control mechanisms for end-node 691 reaction to CE packets. However, this is a research issue, and 692 as such is not addressed in this document." 694 Latency isolation (network): L4S congestion controls keep queue 695 delay low whereas Classic congestion controls need a queue of the 696 order of the RTT to avoid under-utilization. One queue cannot 697 have two lengths, therefore L4S traffic needs to be isolated in a 698 separate queue (e.g. DualQ) or queues (e.g. FQ). 700 Coupled congestion notification: Coupling the congestion 701 notification between two queues as in the DualQ Coupled AQM is not 702 necessarily essential, but it is a simple way to allow senders to 703 determine their rate, packet by packet, rather than be overridden 704 by a network scheduler. An alternative is for a network scheduler 705 to control the rate of each application flow (see discussion in 706 Section 5.2). 708 L4S packet identifier (protocol): Once there are at least two 709 treatments in the network, hosts need an identifier at the IP 710 layer to distinguish which treatment they intend to use. 712 Scalable congestion notification: A scalable congestion control in 713 the host keeps the signalling frequency from the network high 714 whatever the flow rate, so that queue delay variations can be 715 small when conditions are stable, and rate can track variations in 716 available capacity as rapidly as possible otherwise. 718 Low loss: Latency is not the only concern of L4S. The 'Low Loss' 719 part of the name denotes that L4S generally achieves zero 720 congestion loss due to its use of ECN. Otherwise, loss would 721 itself cause delay, particularly for short flows, due to 722 retransmission delay [RFC2884]. 724 Scalable throughput: The "Scalable throughput" part of the name 725 denotes that the per-flow throughput of scalable congestion 726 controls should scale indefinitely, avoiding the imminent scaling 727 problems with Reno-friendly congestion control 728 algorithms [RFC3649]. It was known when TCP congestion avoidance 729 was first developed in 1988 that it would not scale to high 730 bandwidth-delay products (see footnote 6 in [TCP-CA]). Today, 731 regular broadband flow rates over WAN distances are already beyond 732 the scaling range of Classic Reno congestion control. So `less 733 unscalable' Cubic [RFC8312] and Compound [I-D.sridharan-tcpm-ctcp] 734 variants of TCP have been successfully deployed. However, these 735 are now approaching their scaling limits. 737 For instance, we will consider a scenario with a maximum RTT of 738 30 ms at the peak of each sawtooth. As Reno packet rate scales 8x 739 from 1,250 to 10,000 packet/s (from 15 to 120 Mb/s with 1500 B 740 packets), the time to recover from a congestion event rises 741 proportionately by 8x as well, from 422 ms to 3.38 s. It is 742 clearly problematic for a congestion control to take multiple 743 seconds to recover from each congestion event. Cubic [RFC8312] 744 was developed to be less unscalable, but it is approaching its 745 scaling limit; with the same max RTT of 30 ms, at 120 Mb/s Cubic 746 is still fully in its Reno-friendly mode, so it takes about 4.3 s 747 to recover. However, once the flow rate scales by 8x again to 748 960 Mb/s it enters true Cubic mode, with a recovery time of 749 12.2 s. From then on, each further scaling by 8x doubles Cubic's 750 recovery time (because the cube root of 8 is 2), e.g. at 7.68 Gb/s 751 the recovery time is 24.3 s. In contrast a scalable congestion 752 control like DCTCP or TCP Prague induces 2 congestion signals per 753 round trip on average, which remains invariant for any flow rate, 754 keeping dynamic control very tight. 756 For a feel of where the global average lone-flow download sits on 757 this scale at the time of writing (2021), according to [BDPdata] 758 globally averaged fixed access capacity was 103 Mb/s in 2020 and 759 averaged base RTT to a CDN was 25-34ms in 2019. Averaging of per- 760 country data was weighted by Internet user population (data 761 collected globally is necessarily of variable quality, but the 762 paper does double-check that the outcome compares well against a 763 second source). So a lone CUBIC flow would at best take about 200 764 round trips (5 s) to recover from each of its sawtooth reductions, 765 if the flow even lasted that long. This is described as 'at best' 766 because it assume everyone uses an AQM, whereas in reality most 767 users still have a (probably bloated) tail-drop buffer. In the 768 tail-drop case, likely average recovery time would be at least 4x 769 5 s, if not more, because RTT under load would be at least double 770 that of an AQM, and recovery time depends on the square of RTT. 772 Although work on scaling congestion controls tends to start with 773 TCP as the transport, the above is not intended to exclude other 774 transports (e.g. SCTP, QUIC) or less elastic algorithms 775 (e.g. RMCAT), which all tend to adopt the same or similar 776 developments. 778 5.2. What L4S adds to Existing Approaches 780 All the following approaches address some part of the same problem 781 space as L4S. In each case, it is shown that L4S complements them or 782 improves on them, rather than being a mutually exclusive alternative: 784 Diffserv: Diffserv addresses the problem of bandwidth apportionment 785 for important traffic as well as queuing latency for delay- 786 sensitive traffic. Of these, L4S solely addresses the problem of 787 queuing latency. Diffserv will still be necessary where important 788 traffic requires priority (e.g. for commercial reasons, or for 789 protection of critical infrastructure traffic) - see 790 [I-D.briscoe-tsvwg-l4s-diffserv]. Nonetheless, the L4S approach 791 can provide low latency for all traffic within each Diffserv class 792 (including the case where there is only the one default Diffserv 793 class). 795 Also, Diffserv can only provide a latency benefit if a small 796 subset of the traffic on a bottleneck link requests low latency. 797 As already explained, it has no effect when all the applications 798 in use at one time at a single site (home, small business or 799 mobile device) require low latency. In contrast, because L4S 800 works for all traffic, it needs none of the management baggage 801 (traffic policing, traffic contracts) associated with favouring 802 some packets over others. This lack of management baggage ought 803 to give L4S a better chance of end-to-end deployment. 805 In particular, because networks tend not to trust end systems to 806 identify which packets should be favoured over others, where 807 networks assign packets to Diffserv classes they tend to use 808 packet inspection of application flow identifiers or deeper 809 inspection of application signatures. Thus, nowadays, Diffserv 810 doesn't always sit well with encryption of the layers above IP 811 [RFC8404]. So users have to choose between privacy and QoS. 813 As with Diffserv, the L4S identifier is in the IP header. But, in 814 contrast to Diffserv, the L4S identifier does not convey a want or 815 a need for a certain level of quality. Rather, it promises a 816 certain behaviour (scalable congestion response), which networks 817 can objectively verify if they need to. This is because low delay 818 depends on collective host behaviour, whereas bandwidth priority 819 depends on network behaviour. 821 State-of-the-art AQMs: AQMs such as PIE and FQ-CoDel give a 822 significant reduction in queuing delay relative to no AQM at all. 823 L4S is intended to complement these AQMs, and should not distract 824 from the need to deploy them as widely as possible. Nonetheless, 825 AQMs alone cannot reduce queuing delay too far without 826 significantly reducing link utilization, because the root cause of 827 the problem is on the host - where Classic congestion controls use 828 large saw-toothing rate variations. The L4S approach resolves 829 this tension between delay and utilization by enabling hosts to 830 minimize the amplitude of their sawteeth. A single-queue Classic 831 AQM is not sufficient to allow hosts to use small sawteeth for two 832 reasons: i) smaller sawteeth would not get lower delay in an AQM 833 designed for larger amplitude Classic sawteeth, because a queue 834 can only have one length at a time; and ii) much smaller sawteeth 835 implies much more frequent sawteeth, so L4S flows would drive a 836 Classic AQM into a high level of ECN-marking, which would appear 837 as heavy congestion to Classic flows, which in turn would greatly 838 reduce their rate as a result (see Section 6.4.4). 840 Per-flow queuing or marking: Similarly, per-flow approaches such as 841 FQ-CoDel or Approx Fair CoDel [AFCD] are not incompatible with the 842 L4S approach. However, per-flow queuing alone is not enough - it 843 only isolates the queuing of one flow from others; not from 844 itself. Per-flow implementations need to have support for 845 scalable congestion control added, which has already been done for 846 FQ-CoDel in Linux (see Sec.5.2.7 of [RFC8290] and 847 [FQ_CoDel_Thresh]). Without this simple modification, per-flow 848 AQMs like FQ-CoDel would still not be able to support applications 849 that need both very low delay and high bandwidth, e.g. video-based 850 control of remote procedures, or interactive cloud-based video 851 (see Note 1 below). 853 Although per-flow techniques are not incompatible with L4S, it is 854 important to have the DualQ alternative. This is because handling 855 end-to-end (layer 4) flows in the network (layer 3 or 2) precludes 856 some important end-to-end functions. For instance: 858 a. Per-flow forms of L4S like FQ-CoDel are incompatible with full 859 end-to-end encryption of transport layer identifiers for 860 privacy and confidentiality (e.g. IPSec or encrypted VPN 861 tunnels, as opposed to TLS over UDP), because they require 862 packet inspection to access the end-to-end transport flow 863 identifiers. 865 In contrast, the DualQ form of L4S requires no deeper 866 inspection than the IP layer. So, as long as operators take 867 the DualQ approach, their users can have both very low queuing 868 delay and full end-to-end encryption [RFC8404]. 870 b. With per-flow forms of L4S, the network takes over control of 871 the relative rates of each application flow. Some see it as 872 an advantage that the network will prevent some flows running 873 faster than others. Others consider it an inherent part of 874 the Internet's appeal that applications can control their rate 875 while taking account of the needs of others via congestion 876 signals. They maintain that this has allowed applications 877 with interesting rate behaviours to evolve, for instance, 878 variable bit-rate video that varies around an equal share 879 rather than being forced to remain equal at every instant, or 880 e2e scavenger behaviours [RFC6817] that use less than an equal 881 share of capacity [LEDBAT_AQM]. 883 The L4S architecture does not require the IETF to commit to 884 one approach over the other, because it supports both, so that 885 the 'market' can decide. Nonetheless, in the spirit of 'Do 886 one thing and do it well' [McIlroy78], the DualQ option 887 provides low delay without prejudging the issue of flow-rate 888 control. Then, flow rate policing can be added separately if 889 desired. This allows application control up to a point, but 890 the network can still choose to set the point at which it 891 intervenes to prevent one flow completely starving another. 893 Note: 895 1. It might seem that self-inflicted queuing delay within a per- 896 flow queue should not be counted, because if the delay wasn't 897 in the network it would just shift to the sender. However, 898 modern adaptive applications, e.g. HTTP/2 [RFC7540] or some 899 interactive media applications (see Section 6.1), can keep low 900 latency objects at the front of their local send queue by 901 shuffling priorities of other objects dependent on the 902 progress of other transfers. They cannot shuffle objects once 903 they have released them into the network. 905 Alternative Back-off ECN (ABE): Here again, L4S is not an 906 alternative to ABE but a complement that introduces much lower 907 queuing delay. ABE [RFC8511] alters the host behaviour in 908 response to ECN marking to utilize a link better and give ECN 909 flows faster throughput. It uses ECT(0) and assumes the network 910 still treats ECN and drop the same. Therefore ABE exploits any 911 lower queuing delay that AQMs can provide. But as explained 912 above, AQMs still cannot reduce queuing delay too far without 913 losing link utilization (to allow for other, non-ABE, flows). 915 BBR: Bottleneck Bandwidth and Round-trip propagation time 916 (BBR [I-D.cardwell-iccrg-bbr-congestion-control]) controls queuing 917 delay end-to-end without needing any special logic in the network, 918 such as an AQM. So it works pretty-much on any path (although it 919 has not been without problems, particularly capacity sharing in 920 BBRv1). BBR keeps queuing delay reasonably low, but perhaps not 921 quite as low as with state-of-the-art AQMs such as PIE or FQ- 922 CoDel, and certainly nowhere near as low as with L4S. Queuing 923 delay is also not consistently low, due to BBR's regular bandwidth 924 probing spikes and its aggressive flow start-up phase. 926 L4S complements BBR. Indeed BBRv2 [BBRv2] can use L4S ECN where 927 available and a scalable L4S congestion control behaviour in 928 response to any ECN signalling from the path. The L4S ECN signal 929 complements the delay based congestion control aspects of BBR with 930 an explicit indication that hosts can use, both to converge on a 931 fair rate and to keep below a shallow queue target set by the 932 network. Without L4S ECN, both these aspects need to be assumed 933 or estimated. 935 6. Applicability 937 6.1. Applications 939 A transport layer that solves the current latency issues will provide 940 new service, product and application opportunities. 942 With the L4S approach, the following existing applications also 943 experience significantly better quality of experience under load: 945 * Gaming, including cloud based gaming; 947 * VoIP; 949 * Video conferencing; 951 * Web browsing; 953 * (Adaptive) video streaming; 955 * Instant messaging. 957 The significantly lower queuing latency also enables some interactive 958 application functions to be offloaded to the cloud that would hardly 959 even be usable today: 961 * Cloud based interactive video; 963 * Cloud based virtual and augmented reality. 965 The above two applications have been successfully demonstrated with 966 L4S, both running together over a 40 Mb/s broadband access link 967 loaded up with the numerous other latency sensitive applications in 968 the previous list as well as numerous downloads - all sharing the 969 same bottleneck queue simultaneously [L4Sdemo16]. For the former, a 970 panoramic video of a football stadium could be swiped and pinched so 971 that, on the fly, a proxy in the cloud could generate a sub-window of 972 the match video under the finger-gesture control of each user. For 973 the latter, a virtual reality headset displayed a viewport taken from 974 a 360 degree camera in a racing car. The user's head movements 975 controlled the viewport extracted by a cloud-based proxy. In both 976 cases, with 7 ms end-to-end base delay, the additional queuing delay 977 of roughly 1 ms was so low that it seemed the video was generated 978 locally. 980 Using a swiping finger gesture or head movement to pan a video are 981 extremely latency-demanding actions--far more demanding than VoIP. 982 Because human vision can detect extremely low delays of the order of 983 single milliseconds when delay is translated into a visual lag 984 between a video and a reference point (the finger or the orientation 985 of the head sensed by the balance system in the inner ear --- the 986 vestibular system). 988 Without the low queuing delay of L4S, cloud-based applications like 989 these would not be credible without significantly more access 990 bandwidth (to deliver all possible video that might be viewed) and 991 more local processing, which would increase the weight and power 992 consumption of head-mounted displays. When all interactive 993 processing can be done in the cloud, only the data to be rendered for 994 the end user needs to be sent. 996 Other low latency high bandwidth applications such as: 998 * Interactive remote presence; 1000 * Video-assisted remote control of machinery or industrial 1001 processes. 1003 are not credible at all without very low queuing delay. No amount of 1004 extra access bandwidth or local processing can make up for lost time. 1006 6.2. Use Cases 1008 The following use-cases for L4S are being considered by various 1009 interested parties: 1011 * Where the bottleneck is one of various types of access network: 1012 e.g. DSL, Passive Optical Networks (PON), DOCSIS cable, mobile, 1013 satellite (see Section 6.3 for some technology-specific details) 1015 * Private networks of heterogeneous data centres, where there is no 1016 single administrator that can arrange for all the simultaneous 1017 changes to senders, receivers and network needed to deploy DCTCP: 1019 - a set of private data centres interconnected over a wide area 1020 with separate administrations, but within the same company 1022 - a set of data centres operated by separate companies 1023 interconnected by a community of interest network (e.g. for the 1024 finance sector) 1026 - multi-tenant (cloud) data centres where tenants choose their 1027 operating system stack (Infrastructure as a Service - IaaS) 1029 * Different types of transport (or application) congestion control: 1031 - elastic (TCP/SCTP); 1033 - real-time (RTP, RMCAT); 1035 - query (DNS/LDAP). 1037 * Where low delay quality of service is required, but without 1038 inspecting or intervening above the IP layer [RFC8404]: 1040 - mobile and other networks have tended to inspect higher layers 1041 in order to guess application QoS requirements. However, with 1042 growing demand for support of privacy and encryption, L4S 1043 offers an alternative. There is no need to select which 1044 traffic to favour for queuing, when L4S can give favourable 1045 queuing to all traffic. 1047 * If queuing delay is minimized, applications with a fixed delay 1048 budget can communicate over longer distances, or via a longer 1049 chain of service functions [RFC7665] or onion routers. 1051 * If delay jitter is minimized, it is possible to reduce the 1052 dejitter buffers on the receive end of video streaming, which 1053 should improve the interactive experience 1055 6.3. Applicability with Specific Link Technologies 1057 Certain link technologies aggregate data from multiple packets into 1058 bursts, and buffer incoming packets while building each burst. WiFi, 1059 PON and cable all involve such packet aggregation, whereas fixed 1060 Ethernet and DSL do not. No sender, whether L4S or not, can do 1061 anything to reduce the buffering needed for packet aggregation. So 1062 an AQM should not count this buffering as part of the queue that it 1063 controls, given no amount of congestion signals will reduce it. 1065 Certain link technologies also add buffering for other reasons, 1066 specifically: 1068 * Radio links (cellular, WiFi, satellite) that are distant from the 1069 source are particularly challenging. The radio link capacity can 1070 vary rapidly by orders of magnitude, so it is considered desirable 1071 to hold a standing queue that can utilize sudden increases of 1072 capacity; 1074 * Cellular networks are further complicated by a perceived need to 1075 buffer in order to make hand-overs imperceptible; 1077 L4S cannot remove the need for all these different forms of 1078 buffering. However, by removing 'the longest pole in the tent' 1079 (buffering for the large sawteeth of Classic congestion controls), 1080 L4S exposes all these 'shorter poles' to greater scrutiny. 1082 Until now, the buffering needed for these additional reasons tended 1083 to be over-specified - with the excuse that none were 'the longest 1084 pole in the tent'. But having removed the 'longest pole', it becomes 1085 worthwhile to minimize them, for instance reducing packet aggregation 1086 burst sizes and MAC scheduling intervals. 1088 6.4. Deployment Considerations 1090 L4S AQMs, whether DualQ [I-D.ietf-tsvwg-aqm-dualq-coupled] or FQ, 1091 e.g. [RFC8290] are, in themselves, an incremental deployment 1092 mechanism for L4S - so that L4S traffic can coexist with existing 1093 Classic (Reno-friendly) traffic. Section 6.4.1 explains why only 1094 deploying an L4S AQM in one node at each end of the access link will 1095 realize nearly all the benefit of L4S. 1097 L4S involves both end systems and the network, so Section 6.4.2 1098 suggests some typical sequences to deploy each part, and why there 1099 will be an immediate and significant benefit after deploying just one 1100 part. 1102 Section 6.4.3 and Section 6.4.4 describe the converse incremental 1103 deployment case where there is no L4S AQM at the network bottleneck, 1104 so any L4S flow traversing this bottleneck has to take care in case 1105 it is competing with Classic traffic. 1107 6.4.1. Deployment Topology 1109 L4S AQMs will not have to be deployed throughout the Internet before 1110 L4S can benefit anyone. Operators of public Internet access networks 1111 typically design their networks so that the bottleneck will nearly 1112 always occur at one known (logical) link. This confines the cost of 1113 queue management technology to one place. 1115 The case of mesh networks is different and will be discussed later in 1116 this section. But the known bottleneck case is generally true for 1117 Internet access to all sorts of different 'sites', where the word 1118 'site' includes home networks, small- to medium-sized campus or 1119 enterprise networks and even cellular devices (Figure 2). Also, this 1120 known-bottleneck case tends to be applicable whatever the access link 1121 technology; whether xDSL, cable, PON, cellular, line of sight 1122 wireless or satellite. 1124 Therefore, the full benefit of the L4S service should be available in 1125 the downstream direction when an L4S AQM is deployed at the ingress 1126 to this bottleneck link. And similarly, the full upstream service 1127 will be available once an L4S AQM is deployed at the ingress into the 1128 upstream link. (Of course, multi-homed sites would only see the full 1129 benefit once all their access links were covered.) 1131 ______ 1132 ( ) 1133 __ __ ( ) 1134 |DQ\________/DQ|( enterprise ) 1135 ___ |__/ \__| ( /campus ) 1136 ( ) (______) 1137 ( ) ___||_ 1138 +----+ ( ) __ __ / \ 1139 | DC |-----( Core )|DQ\_______________/DQ|| home | 1140 +----+ ( ) |__/ \__||______| 1141 (_____) __ 1142 |DQ\__/\ __ ,===. 1143 |__/ \ ____/DQ||| ||mobile 1144 \/ \__|||_||device 1145 | o | 1146 `---' 1148 Figure 2: Likely location of DualQ (DQ) Deployments in common 1149 access topologies 1151 Deployment in mesh topologies depends on how overbooked the core is. 1152 If the core is non-blocking, or at least generously provisioned so 1153 that the edges are nearly always the bottlenecks, it would only be 1154 necessary to deploy an L4S AQM at the edge bottlenecks. For example, 1155 some data-centre networks are designed with the bottleneck in the 1156 hypervisor or host NICs, while others bottleneck at the top-of-rack 1157 switch (both the output ports facing hosts and those facing the 1158 core). 1160 An L4S AQM would often next be needed where the WiFi links in a home 1161 sometimes become the bottleneck. And an L4S AQM would eventually 1162 also need to be deployed at any other persistent bottlenecks such as 1163 network interconnections, e.g. some public Internet exchange points 1164 and the ingress and egress to WAN links interconnecting data-centres. 1166 6.4.2. Deployment Sequences 1168 For any one L4S flow to provide benefit, it requires 3 parts to have 1169 been deployed. This was the same deployment problem that ECN 1170 faced [RFC8170] so we have learned from that experience. 1172 Firstly, L4S deployment exploits the fact that DCTCP already exists 1173 on many Internet hosts (Windows, FreeBSD and Linux); both servers and 1174 clients. Therefore, an L4S AQM can be deployed at a network 1175 bottleneck to immediately give a working deployment of all the L4S 1176 parts for testing, as long as the ECT(0) codepoint is switched to 1177 ECT(1). DCTCP needs some safety concerns to be fixed for general use 1178 over the public Internet (see Section 4.3 of 1179 [I-D.ietf-tsvwg-ecn-l4s-id]), but DCTCP is not on by default, so 1180 these issues can be managed within controlled deployments or 1181 controlled trials. 1183 Secondly, the performance improvement with L4S is so significant that 1184 it enables new interactive services and products that were not 1185 previously possible. It is much easier for companies to initiate new 1186 work on deployment if there is budget for a new product trial. If, 1187 in contrast, there were only an incremental performance improvement 1188 (as with Classic ECN), spending on deployment tends to be much harder 1189 to justify. 1191 Thirdly, the L4S identifier is defined so that initially network 1192 operators can enable L4S exclusively for certain customers or certain 1193 applications. But this is carefully defined so that it does not 1194 compromise future evolution towards L4S as an Internet-wide service. 1195 This is because the L4S identifier is defined not only as the end-to- 1196 end ECN field, but it can also optionally be combined with any other 1197 packet header or some status of a customer or their access link (see 1198 section 5.4 of [I-D.ietf-tsvwg-ecn-l4s-id]). Operators could do this 1199 anyway, even if it were not blessed by the IETF. However, it is best 1200 for the IETF to specify that, if they use their own local identifier, 1201 it must be in combination with the IETF's identifier. Then, if an 1202 operator has opted for an exclusive local-use approach, later they 1203 only have to remove this extra rule to make the service work 1204 Internet-wide - it will already traverse middleboxes, peerings, etc. 1206 +-+--------------------+----------------------+---------------------+ 1207 | | Servers or proxies | Access link | Clients | 1208 +-+--------------------+----------------------+---------------------+ 1209 |0| DCTCP (existing) | | DCTCP (existing) | 1210 +-+--------------------+----------------------+---------------------+ 1211 |1| |Add L4S AQM downstream| | 1212 | | WORKS DOWNSTREAM FOR CONTROLLED DEPLOYMENTS/TRIALS | 1213 +-+--------------------+----------------------+---------------------+ 1214 |2| Upgrade DCTCP to | |Replace DCTCP feedb'k| 1215 | | TCP Prague | | with AccECN | 1216 | | FULLY WORKS DOWNSTREAM | 1217 +-+--------------------+----------------------+---------------------+ 1218 | | | | Upgrade DCTCP to | 1219 |3| | Add L4S AQM upstream | TCP Prague | 1220 | | | | | 1221 | | FULLY WORKS UPSTREAM AND DOWNSTREAM | 1222 +-+--------------------+----------------------+---------------------+ 1224 Figure 3: Example L4S Deployment Sequence 1226 Figure 3 illustrates some example sequences in which the parts of L4S 1227 might be deployed. It consists of the following stages: 1229 1. Here, the immediate benefit of a single AQM deployment can be 1230 seen, but limited to a controlled trial or controlled deployment. 1231 In this example downstream deployment is first, but in other 1232 scenarios the upstream might be deployed first. If no AQM at all 1233 was previously deployed for the downstream access, an L4S AQM 1234 greatly improves the Classic service (as well as adding the L4S 1235 service). If an AQM was already deployed, the Classic service 1236 will be unchanged (and L4S will add an improvement on top). 1238 2. In this stage, the name 'TCP 1239 Prague' [I-D.briscoe-iccrg-prague-congestion-control] is used to 1240 represent a variant of DCTCP that is designed to be used in a 1241 production Internet environment. If the application is primarily 1242 unidirectional, 'TCP Prague' at one end will provide all the 1243 benefit needed. For TCP transports, Accurate ECN feedback 1244 (AccECN) [I-D.ietf-tcpm-accurate-ecn] is needed at the other end, 1245 but it is a generic ECN feedback facility that is already planned 1246 to be deployed for other purposes, e.g. DCTCP, BBR. The two ends 1247 can be deployed in either order, because, in TCP, an L4S 1248 congestion control only enables itself if it has negotiated the 1249 use of AccECN feedback with the other end during the connection 1250 handshake. Thus, deployment of TCP Prague on a server enables 1251 L4S trials to move to a production service in one direction, 1252 wherever AccECN is deployed at the other end. This stage might 1253 be further motivated by the performance improvements of TCP 1254 Prague relative to DCTCP (see Appendix A.2 of 1255 [I-D.ietf-tsvwg-ecn-l4s-id]). 1257 Unlike TCP, from the outset, QUIC ECN feedback [RFC9000] has 1258 supported L4S. Therefore, if the transport is QUIC, one-ended 1259 deployment of a Prague congestion control at this stage is simple 1260 and sufficient. 1262 3. This is a two-move stage to enable L4S upstream. An L4S AQM or 1263 TCP Prague can be deployed in either order as already explained. 1264 To motivate the first of two independent moves, the deferred 1265 benefit of enabling new services after the second move has to be 1266 worth it to cover the first mover's investment risk. As 1267 explained already, the potential for new interactive services 1268 provides this motivation. An L4S AQM also improves the upstream 1269 Classic service - significantly if no other AQM has already been 1270 deployed. 1272 Note that other deployment sequences might occur. For instance: the 1273 upstream might be deployed first; a non-TCP protocol might be used 1274 end-to-end, e.g. QUIC, RTP; a body such as the 3GPP might require L4S 1275 to be implemented in 5G user equipment, or other random acts of 1276 kindness. 1278 6.4.3. L4S Flow but Non-ECN Bottleneck 1280 If L4S is enabled between two hosts, the L4S sender is required to 1281 coexist safely with Reno in response to any drop (see Section 4.3 of 1282 [I-D.ietf-tsvwg-ecn-l4s-id]). 1284 Unfortunately, as well as protecting Classic traffic, this rule 1285 degrades the L4S service whenever there is any loss, even if the 1286 cause is not persistent congestion at a bottleneck, e.g.: 1288 * congestion loss at other transient bottlenecks, e.g. due to bursts 1289 in shallower queues; 1291 * transmission errors, e.g. due to electrical interference; 1293 * rate policing. 1295 Three complementary approaches are in progress to address this issue, 1296 but they are all currently research: 1298 * In Prague congestion control, ignore certain losses deemed 1299 unlikely to be due to congestion (using some ideas from 1300 BBR [I-D.cardwell-iccrg-bbr-congestion-control] regarding isolated 1301 losses). This could mask any of the above types of loss while 1302 still coexisting with drop-based congestion controls. 1304 * A combination of RACK, L4S and link retransmission without 1305 resequencing could repair transmission errors without the head of 1306 line blocking delay usually associated with link-layer 1307 retransmission [UnorderedLTE], [I-D.ietf-tsvwg-ecn-l4s-id]; 1309 * Hybrid ECN/drop rate policers (see Section 8.3). 1311 L4S deployment scenarios that minimize these issues (e.g. over 1312 wireline networks) can proceed in parallel to this research, in the 1313 expectation that research success could continually widen L4S 1314 applicability. 1316 6.4.4. L4S Flow but Classic ECN Bottleneck 1318 Classic ECN support is starting to materialize on the Internet as an 1319 increased level of CE marking. It is hard to detect whether this is 1320 all due to the addition of support for ECN in implementations of FQ- 1321 CoDel and/or FQ-COBALT, which is not generally problematic, because 1322 flow-queue (FQ) scheduling inherently prevents a flow from exceeding 1323 the 'fair' rate irrespective of its aggressiveness. However, some of 1324 this Classic ECN marking might be due to single-queue ECN deployment. 1325 This case is discussed in Section 4.3 of [I-D.ietf-tsvwg-ecn-l4s-id]. 1327 6.4.5. L4S AQM Deployment within Tunnels 1329 An L4S AQM uses the ECN field to signal congestion. So, in common 1330 with Classic ECN, if the AQM is within a tunnel or at a lower layer, 1331 correct functioning of ECN signalling requires correct propagation of 1332 the ECN field up the layers [RFC6040], 1333 [I-D.ietf-tsvwg-rfc6040update-shim], 1334 [I-D.ietf-tsvwg-ecn-encap-guidelines]. 1336 7. IANA Considerations (to be removed by RFC Editor) 1338 This specification contains no IANA considerations. 1340 8. Security Considerations 1342 8.1. Traffic Rate (Non-)Policing 1344 In the current Internet, scheduling usually enforces separation 1345 between 'sites' (e.g. households, businesses or mobile users 1346 [RFC0970]) and various techniques like redirection to traffic 1347 scrubbing facilities deal with flooding attacks. However, there has 1348 never been a universal need to police the rate of individual 1349 application flows - the Internet has generally always relied on self- 1350 restraint of congestion controls at senders for sharing intra-'site' 1351 capacity. 1353 As explained in Section 5.2, the DualQ variant of L4S provides low 1354 delay without prejudging the issue of flow-rate control. Then, if 1355 flow-rate control is needed, per-flow-queuing (FQ) can be used 1356 instead, or flow rate policing can be added as a modular addition to 1357 a DualQ. 1359 Because the L4S service reduces delay without increasing the delay of 1360 Classic traffic, it should not be necessary to rate-police access to 1361 the L4S service. In contrast, Section 5.2 explains how Diffserv only 1362 makes a difference if some packets get less favourable treatment than 1363 others, which typically requires traffic rate policing, which can, in 1364 turn, lead to further complexity such as traffic contracts at trust 1365 boundaries. Because L4S avoids this management complexity, it is 1366 more likely to work end-to-end. 1368 During early deployment (and perhaps always), some networks will not 1369 offer the L4S service. In general, these networks should not need to 1370 police L4S traffic. They are required (by both [RFC3168] and 1371 [I-D.ietf-tsvwg-ecn-l4s-id]) not to change the L4S identifier, which 1372 would interfere with end-to-end congestion control. Instead they can 1373 merely treat L4S traffic as Not-ECT, as they might already treat all 1374 ECN traffic today. At a bottleneck, such networks will introduce 1375 some queuing and dropping. When a scalable congestion control 1376 detects a drop it will have to respond safely with respect to Classic 1377 congestion controls (as required in Section 4.3 of 1378 [I-D.ietf-tsvwg-ecn-l4s-id]). This will degrade the L4S service to 1379 be no better (but never worse) than Classic best efforts, whenever a 1380 non-ECN bottleneck is encountered on a path (see Section 6.4.3). 1382 In cases that are expected to be rare, networks that solely support 1383 Classic ECN [RFC3168] in a single queue bottleneck might opt to 1384 police L4S traffic so as to protect competing Classic ECN traffic 1385 (for instance, see Section 6.1.3 of [I-D.ietf-tsvwg-l4sops]). 1386 However, Section 4.3 of [I-D.ietf-tsvwg-ecn-l4s-id] recommends that 1387 the sender adapts its congestion response to properly coexist with 1388 Classic ECN flows, i.e. reverting to the self-restraint approach. 1390 Certain network operators might choose to restrict access to the L4S 1391 class, perhaps only to selected premium customers as a value-added 1392 service. Their packet classifier (item 2 in Figure 1) could identify 1393 such customers against some other field (e.g. source address range) 1394 as well as classifying on the ECN field. If only the ECN L4S 1395 identifier matched, but not the source address (say), the classifier 1396 could direct these packets (from non-premium customers) into the 1397 Classic queue. Explaining clearly how operators can use an 1398 additional local classifiers (see section 5.4 of 1399 [I-D.ietf-tsvwg-ecn-l4s-id]) is intended to remove any motivation to 1400 clear the L4S identifier. Then at least the L4S ECN identifier will 1401 be more likely to survive end-to-end even though the service may not 1402 be supported at every hop. Such local arrangements would only 1403 require simple registered/not-registered packet classification, 1404 rather than the managed, application-specific traffic policing 1405 against customer-specific traffic contracts that Diffserv uses. 1407 8.2. 'Latency Friendliness' 1409 Like the Classic service, the L4S service relies on self-constraint - 1410 limiting rate in response to congestion. In addition, the L4S 1411 service requires self-constraint in terms of limiting latency 1412 (burstiness). It is hoped that self-interest and guidance on dynamic 1413 behaviour (especially flow start-up, which might need to be 1414 standardized) will be sufficient to prevent transports from sending 1415 excessive bursts of L4S traffic, given the application's own latency 1416 will suffer most from such behaviour. 1418 Whether burst policing becomes necessary remains to be seen. Without 1419 it, there will be potential for attacks on the low latency of the L4S 1420 service. 1422 If needed, various arrangements could be used to address this 1423 concern: 1425 Local bottleneck queue protection: A per-flow (5-tuple) queue 1426 protection function [I-D.briscoe-docsis-q-protection] has been 1427 developed for the low latency queue in DOCSIS, which has adopted 1428 the DualQ L4S architecture. It protects the low latency service 1429 from any queue-building flows that accidentally or maliciously 1430 classify themselves into the low latency queue. It is designed to 1431 score flows based solely on their contribution to queuing (not 1432 flow rate in itself). Then, if the shared low latency queue is at 1433 risk of exceeding a threshold, the function redirects enough 1434 packets of the highest scoring flow(s) into the Classic queue to 1435 preserve low latency. 1437 Distributed traffic scrubbing: Rather than policing locally at each 1438 bottleneck, it may only be necessary to address problems 1439 reactively, e.g. punitively target any deployments of new bursty 1440 malware, in a similar way to how traffic from flooding attack 1441 sources is rerouted via scrubbing facilities. 1443 Local bottleneck per-flow scheduling: Per-flow scheduling should 1444 inherently isolate non-bursty flows from bursty (see Section 5.2 1445 for discussion of the merits of per-flow scheduling relative to 1446 per-flow policing). 1448 Distributed access subnet queue protection: Per-flow queue 1449 protection could be arranged for a queue structure distributed 1450 across a subnet inter-communicating using lower layer control 1451 messages (see Section 2.1.4 of [QDyn]). For instance, in a radio 1452 access network, user equipment already sends regular buffer status 1453 reports to a radio network controller, which could use this 1454 information to remotely police individual flows. 1456 Distributed Congestion Exposure to Ingress Policers: The Congestion 1457 Exposure (ConEx) architecture [RFC7713] which uses egress audit to 1458 motivate senders to truthfully signal path congestion in-band 1459 where it can be used by ingress policers. An edge-to-edge variant 1460 of this architecture is also possible. 1462 Distributed Domain-edge traffic conditioning: An architecture 1463 similar to Diffserv [RFC2475] may be preferred, where traffic is 1464 proactively conditioned on entry to a domain, rather than 1465 reactively policed only if it leads to queuing once combined with 1466 other traffic at a bottleneck. 1468 Distributed core network queue protection: The policing function 1469 could be divided between per-flow mechanisms at the network 1470 ingress that characterize the burstiness of each flow into a 1471 signal carried with the traffic, and per-class mechanisms at 1472 bottlenecks that act on these signals if queuing actually occurs 1473 once the traffic converges. This would be somewhat similar to 1474 [Nadas20], which is in turn similar to the idea behind core 1475 stateless fair queuing. 1477 None of these possible queue protection capabilities are considered a 1478 necessary part of the L4S architecture, which works without them (in 1479 a similar way to how the Internet works without per-flow rate 1480 policing). Indeed, even where latency policers are deployed, under 1481 normal circumstances they would not intervene, and if operators found 1482 they were not necessary they could disable them. Part of the L4S 1483 experiment will be to see whether such a function is necessary, and 1484 which arrangements are most appropriate to the size of the problem. 1486 8.3. Interaction between Rate Policing and L4S 1488 As mentioned in Section 5.2, L4S should remove the need for low 1489 latency Diffserv classes. However, those Diffserv classes that give 1490 certain applications or users priority over capacity, would still be 1491 applicable in certain scenarios (e.g. corporate networks). Then, 1492 within such Diffserv classes, L4S would often be applicable to give 1493 traffic low latency and low loss as well. Within such a Diffserv 1494 class, the bandwidth available to a user or application is often 1495 limited by a rate policer. Similarly, in the default Diffserv class, 1496 rate policers are used to partition shared capacity. 1498 A classic rate policer drops any packets exceeding a set rate, 1499 usually also giving a burst allowance (variants exist where the 1500 policer re-marks non-compliant traffic to a discard-eligible Diffserv 1501 codepoint, so they can be dropped elsewhere during contention). 1502 Whenever L4S traffic encounters one of these rate policers, it will 1503 experience drops and the source will have to fall back to a Classic 1504 congestion control, thus losing the benefits of L4S (Section 6.4.3). 1505 So, in networks that already use rate policers and plan to deploy 1506 L4S, it will be preferable to redesign these rate policers to be more 1507 friendly to the L4S service. 1509 L4S-friendly rate policing is currently a research area (note that 1510 this is not the same as latency policing). It might be achieved by 1511 setting a threshold where ECN marking is introduced, such that it is 1512 just under the policed rate or just under the burst allowance where 1513 drop is introduced. For instance the two-rate three-colour marker 1514 [RFC2698] or a PCN threshold and excess-rate marker [RFC5670] could 1515 mark ECN at the lower rate and drop at the higher. Or an existing 1516 rate policer could have congestion-rate policing added, e.g. using 1517 the 'local' (non-ConEx) variant of the ConEx aggregate congestion 1518 policer [I-D.briscoe-conex-policing]. It might also be possible to 1519 design scalable congestion controls to respond less catastrophically 1520 to loss that has not been preceded by a period of increasing delay. 1522 The design of L4S-friendly rate policers will require a separate 1523 dedicated document. For further discussion of the interaction 1524 between L4S and Diffserv, see [I-D.briscoe-tsvwg-l4s-diffserv]. 1526 8.4. ECN Integrity 1528 Receiving hosts can fool a sender into downloading faster by 1529 suppressing feedback of ECN marks (or of losses if retransmissions 1530 are not necessary or available otherwise). Various ways to protect 1531 transport feedback integrity have been developed. For instance: 1533 * The sender can test the integrity of the receiver's feedback by 1534 occasionally setting the IP-ECN field to the congestion 1535 experienced (CE) codepoint, which is normally only set by a 1536 congested link. Then the sender can test whether the receiver's 1537 feedback faithfully reports what it expects (see 2nd para of 1538 Section 20.2 of [RFC3168]). 1540 * A network can enforce a congestion response to its ECN markings 1541 (or packet losses) by auditing congestion exposure 1542 (ConEx) [RFC7713]. 1544 * Transport layer authentication such as the TCP authentication 1545 option (TCP-AO [RFC5925]) or QUIC's use of TLS [RFC9001] can 1546 detect any tampering with congestion feedback. 1548 * The ECN Nonce [RFC3540] was proposed to detect tampering with 1549 congestion feedback, but it has been reclassified as 1550 historic [RFC8311]. 1552 Appendix C.1 of [I-D.ietf-tsvwg-ecn-l4s-id] gives more details of 1553 these techniques including their applicability and pros and cons. 1555 8.5. Privacy Considerations 1557 As discussed in Section 5.2, the L4S architecture does not preclude 1558 approaches that inspect end-to-end transport layer identifiers. For 1559 instance, L4S support has been added to FQ-CoDel, which classifies by 1560 application flow ID in the network. However, the main innovation of 1561 L4S is the DualQ AQM framework that does not need to inspect any 1562 deeper than the outermost IP header, because the L4S identifier is in 1563 the IP-ECN field. 1565 Thus, the L4S architecture enables very low queuing delay without 1566 _requiring_ inspection of information above the IP layer. This means 1567 that users who want to encrypt application flow identifiers, e.g. in 1568 IPSec or other encrypted VPN tunnels, don't have to sacrifice low 1569 delay [RFC8404]. 1571 Because L4S can provide low delay for a broad set of applications 1572 that choose to use it, there is no need for individual applications 1573 or classes within that broad set to be distinguishable in any way 1574 while traversing networks. This removes much of the ability to 1575 correlate between the delay requirements of traffic and other 1576 identifying features [RFC6973]. There may be some types of traffic 1577 that prefer not to use L4S, but the coarse binary categorization of 1578 traffic reveals very little that could be exploited to compromise 1579 privacy. 1581 9. Acknowledgements 1583 Thanks to Richard Scheffenegger, Wes Eddy, Karen Nielsen, David 1584 Black, Jake Holland, Vidhi Goel, Ermin Sakic, Praveen 1585 Balasubramanian, Gorry Fairhurst, Mirja Kuehlewind, Philip Eardley, 1586 Neal Cardwell and Pete Heist for their useful review comments. 1588 Bob Briscoe and Koen De Schepper were part-funded by the European 1589 Community under its Seventh Framework Programme through the Reducing 1590 Internet Transport Latency (RITE) project (ICT-317700). Bob Briscoe 1591 was also part-funded by the Research Council of Norway through the 1592 TimeIn project, partly by CableLabs and partly by the Comcast 1593 Innovation Fund. The views expressed here are solely those of the 1594 authors. 1596 10. Informative References 1598 [AFCD] Xue, L., Kumar, S., Cui, C., Kondikoppa, P., Chiu, C-H., 1599 and S-J. Park, "Towards fair and low latency next 1600 generation high speed networks: AFCD queuing", Journal of 1601 Network and Computer Applications 70:183--193, July 2016, 1602 . 1604 [BBRv2] Cardwell, N., "TCP BBR v2 Alpha/Preview Release", github 1605 repository; Linux congestion control module, 1606 . 1608 [BDPdata] Briscoe, B., "PI2 Parameters", Technical Report TR-BB- 1609 2021-001 arXiv:2107.01003 [cs.NI], July 2021, 1610 . 1612 [BufferSize] 1613 Appenzeller, G., Keslassy, I., and N. McKeown, "Sizing 1614 Router Buffers", In Proc. SIGCOMM'04 34(4):281--292, 1615 September 2004, . 1617 [COBALT] Palmei, J., Gupta, S., Imputato, P., Morton, J., 1618 Tahiliani, M. P., Avallone, S., and D. Täht, "Design and 1619 Evaluation of COBALT Queue Discipline", In Proc. IEEE 1620 Int'l Symp. Local and Metropolitan Area Networks 1621 (LANMAN'19) 2019:1-6, July 2019, 1622 . 1624 [DCttH19] De Schepper, K., Bondarenko, O., Tilmans, O., and B. 1625 Briscoe, "`Data Centre to the Home': Ultra-Low Latency for 1626 All", Updated RITE project Technical Report , July 2019, 1627 . 1629 [DOCSIS3.1] 1630 CableLabs, "MAC and Upper Layer Protocols Interface 1631 (MULPI) Specification, CM-SP-MULPIv3.1", Data-Over-Cable 1632 Service Interface Specifications DOCSIS® 3.1 Version i17 1633 or later, 21 January 2019, . 1636 [DOCSIS3AQM] 1637 White, G., "Active Queue Management Algorithms for DOCSIS 1638 3.0; A Simulation Study of CoDel, SFQ-CoDel and PIE in 1639 DOCSIS 3.0 Networks", CableLabs Technical Report , April 1640 2013, <{http://www.cablelabs.com/wp- 1641 content/uploads/2013/11/ 1642 Active_Queue_Management_Algorithms_DOCSIS_3_0.pdf>. 1644 [DualPI2Linux] 1645 Albisser, O., De Schepper, K., Briscoe, B., Tilmans, O., 1646 and H. Steen, "DUALPI2 - Low Latency, Low Loss and 1647 Scalable (L4S) AQM", Proc. Linux Netdev 0x13 , March 2019, 1648 . 1651 [Dukkipati15] 1652 Dukkipati, N. and N. McKeown, "Why Flow-Completion Time is 1653 the Right Metric for Congestion Control", ACM CCR 1654 36(1):59--62, January 2006, 1655 . 1657 [FQ_CoDel_Thresh] 1658 Høiland-Jørgensen, T., "fq_codel: generalise ce_threshold 1659 marking for subset of traffic", Linux Patch Commit ID: 1661 dfcb63ce1de6b10b, 20 October 2021, 1662 . 1665 [Hohlfeld14] 1666 Hohlfeld, O., Pujol, E., Ciucu, F., Feldmann, A., and P. 1667 Barford, "A QoE Perspective on Sizing Network Buffers", 1668 Proc. ACM Internet Measurement Conf (IMC'14) hmm, November 1669 2014, . 1671 [I-D.briscoe-conex-policing] 1672 Briscoe, B., "Network Performance Isolation using 1673 Congestion Policing", Work in Progress, Internet-Draft, 1674 draft-briscoe-conex-policing-01, 14 February 2014, 1675 . 1678 [I-D.briscoe-docsis-q-protection] 1679 Briscoe, B. and G. White, "Queue Protection to Preserve 1680 Low Latency", Work in Progress, Internet-Draft, draft- 1681 briscoe-docsis-q-protection-00, 8 July 2019, 1682 . 1685 [I-D.briscoe-iccrg-prague-congestion-control] 1686 Schepper, K. D., Tilmans, O., and B. Briscoe, "Prague 1687 Congestion Control", Work in Progress, Internet-Draft, 1688 draft-briscoe-iccrg-prague-congestion-control-00, 9 March 1689 2021, . 1692 [I-D.briscoe-tsvwg-l4s-diffserv] 1693 Briscoe, B., "Interactions between Low Latency, Low Loss, 1694 Scalable Throughput (L4S) and Differentiated Services", 1695 Work in Progress, Internet-Draft, draft-briscoe-tsvwg-l4s- 1696 diffserv-02, 4 November 2018, 1697 . 1700 [I-D.cardwell-iccrg-bbr-congestion-control] 1701 Cardwell, N., Cheng, Y., Yeganeh, S. H., and V. Jacobson, 1702 "BBR Congestion Control", Work in Progress, Internet- 1703 Draft, draft-cardwell-iccrg-bbr-congestion-control-00, 3 1704 July 2017, . 1707 [I-D.ietf-tcpm-accurate-ecn] 1708 Briscoe, B., Kühlewind, M., and R. Scheffenegger, "More 1709 Accurate ECN Feedback in TCP", Work in Progress, Internet- 1710 Draft, draft-ietf-tcpm-accurate-ecn-15, 12 July 2021, 1711 . 1714 [I-D.ietf-tcpm-generalized-ecn] 1715 Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit 1716 Congestion Notification (ECN) to TCP Control Packets", 1717 Work in Progress, Internet-Draft, draft-ietf-tcpm- 1718 generalized-ecn-08, 2 August 2021, 1719 . 1722 [I-D.ietf-tsvwg-aqm-dualq-coupled] 1723 Schepper, K. D., Briscoe, B., and G. White, "DualQ Coupled 1724 AQMs for Low Latency, Low Loss and Scalable Throughput 1725 (L4S)", Work in Progress, Internet-Draft, draft-ietf- 1726 tsvwg-aqm-dualq-coupled-18, 25 October 2021, 1727 . 1730 [I-D.ietf-tsvwg-ecn-encap-guidelines] 1731 Briscoe, B. and J. Kaippallimalil, "Guidelines for Adding 1732 Congestion Notification to Protocols that Encapsulate IP", 1733 Work in Progress, Internet-Draft, draft-ietf-tsvwg-ecn- 1734 encap-guidelines-16, 25 May 2021, 1735 . 1738 [I-D.ietf-tsvwg-ecn-l4s-id] 1739 Schepper, K. D. and B. Briscoe, "Explicit Congestion 1740 Notification (ECN) Protocol for Very Low Queuing Delay 1741 (L4S)", Work in Progress, Internet-Draft, draft-ietf- 1742 tsvwg-ecn-l4s-id-19, 26 July 2021, 1743 . 1746 [I-D.ietf-tsvwg-l4sops] 1747 White, G., "Operational Guidance for Deployment of L4S in 1748 the Internet", Work in Progress, Internet-Draft, draft- 1749 ietf-tsvwg-l4sops-01, 12 July 2021, 1750 . 1753 [I-D.ietf-tsvwg-nqb] 1754 White, G. and T. Fossati, "A Non-Queue-Building Per-Hop 1755 Behavior (NQB PHB) for Differentiated Services", Work in 1756 Progress, Internet-Draft, draft-ietf-tsvwg-nqb-07, 28 July 1757 2021, . 1760 [I-D.ietf-tsvwg-rfc6040update-shim] 1761 Briscoe, B., "Propagating Explicit Congestion Notification 1762 Across IP Tunnel Headers Separated by a Shim", Work in 1763 Progress, Internet-Draft, draft-ietf-tsvwg-rfc6040update- 1764 shim-14, 25 May 2021, 1765 . 1768 [I-D.morton-tsvwg-codel-approx-fair] 1769 Morton, J. and P. G. Heist, "Controlled Delay Approximate 1770 Fairness AQM", Work in Progress, Internet-Draft, draft- 1771 morton-tsvwg-codel-approx-fair-01, 9 March 2020, 1772 . 1775 [I-D.sridharan-tcpm-ctcp] 1776 Sridharan, M., Tan, K., Bansal, D., and D. Thaler, 1777 "Compound TCP: A New TCP Congestion Control for High-Speed 1778 and Long Distance Networks", Work in Progress, Internet- 1779 Draft, draft-sridharan-tcpm-ctcp-02, 11 November 2008, 1780 . 1783 [I-D.stewart-tsvwg-sctpecn] 1784 Stewart, R. R., Tuexen, M., and X. Dong, "ECN for Stream 1785 Control Transmission Protocol (SCTP)", Work in Progress, 1786 Internet-Draft, draft-stewart-tsvwg-sctpecn-05, 15 January 1787 2014, . 1790 [L4Sdemo16] 1791 Bondarenko, O., De Schepper, K., Tsang, I., and B. 1792 Briscoe, "Ultra-Low Delay for All: Live Experience, Live 1793 Analysis", Proc. MMSYS'16 pp33:1--33:4, May 2016, 1794 . 1798 [LEDBAT_AQM] 1799 Al-Saadi, R., Armitage, G., and J. But, "Characterising 1800 LEDBAT Performance Through Bottlenecks Using PIE, FQ-CoDel 1801 and FQ-PIE Active Queue Management", Proc. IEEE 42nd 1802 Conference on Local Computer Networks (LCN) 278--285, 1803 2017, . 1805 [Mathis09] Mathis, M., "Relentless Congestion Control", PFLDNeT'09 , 1806 May 2009, . 1811 [McIlroy78] 1812 McIlroy, M.D., Pinson, E. N., and B. A. Tague, "UNIX Time- 1813 Sharing System: Foreword", The Bell System Technical 1814 Journal 57:6(1902--1903), July 1978, 1815 . 1817 [Nadas20] Nádas, S., Gombos, G., Fejes, F., and S. Laki, "A 1818 Congestion Control Independent L4S Scheduler", Proc. 1819 Applied Networking Research Workshop (ANRW '20) 45--51, 1820 July 2020, . 1822 [NewCC_Proc] 1823 Eggert, L., "Experimental Specification of New Congestion 1824 Control Algorithms", IETF Operational Note ion-tsv-alt-cc, 1825 July 2007, . 1828 [PragueLinux] 1829 Briscoe, B., De Schepper, K., Albisser, O., Misund, J., 1830 Tilmans, O., Kühlewind, M., and A.S. Ahmed, "Implementing 1831 the `TCP Prague' Requirements for Low Latency Low Loss 1832 Scalable Throughput (L4S)", Proc. Linux Netdev 0x13 , 1833 March 2019, . 1836 [QDyn] Briscoe, B., "Rapid Signalling of Queue Dynamics", 1837 bobbriscoe.net Technical Report TR-BB-2017-001; 1838 arXiv:1904.07044 [cs.NI], September 2017, 1839 . 1841 [Rajiullah15] 1842 Rajiullah, M., "Towards a Low Latency Internet: 1843 Understanding and Solutions", Masters Thesis; Karlstad 1844 Uni, Dept of Maths & CS 2015:41, 2015, . 1847 [RFC0970] Nagle, J., "On Packet Switches With Infinite Storage", 1848 RFC 970, DOI 10.17487/RFC0970, December 1985, 1849 . 1851 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1852 and W. Weiss, "An Architecture for Differentiated 1853 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 1854 . 1856 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 1857 Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, 1858 . 1860 [RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of 1861 Explicit Congestion Notification (ECN) in IP Networks", 1862 RFC 2884, DOI 10.17487/RFC2884, July 2000, 1863 . 1865 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1866 of Explicit Congestion Notification (ECN) to IP", 1867 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1868 . 1870 [RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le 1871 Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D. 1872 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 1873 Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, 1874 . 1876 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 1877 Congestion Notification (ECN) Signaling with Nonces", 1878 RFC 3540, DOI 10.17487/RFC3540, June 2003, 1879 . 1881 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", 1882 RFC 3649, DOI 10.17487/RFC3649, December 2003, 1883 . 1885 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1886 Congestion Control Protocol (DCCP)", RFC 4340, 1887 DOI 10.17487/RFC4340, March 2006, 1888 . 1890 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 1891 Explicit Congestion Notification (ECN) Field", BCP 124, 1892 RFC 4774, DOI 10.17487/RFC4774, November 2006, 1893 . 1895 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1896 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1897 . 1899 [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion 1900 Control Algorithms", BCP 133, RFC 5033, 1901 DOI 10.17487/RFC5033, August 2007, 1902 . 1904 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 1905 Friendly Rate Control (TFRC): Protocol Specification", 1906 RFC 5348, DOI 10.17487/RFC5348, September 2008, 1907 . 1909 [RFC5670] Eardley, P., Ed., "Metering and Marking Behaviour of PCN- 1910 Nodes", RFC 5670, DOI 10.17487/RFC5670, November 2009, 1911 . 1913 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 1914 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 1915 . 1917 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1918 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1919 June 2010, . 1921 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 1922 Notification", RFC 6040, DOI 10.17487/RFC6040, November 1923 2010, . 1925 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 1926 and K. Carlberg, "Explicit Congestion Notification (ECN) 1927 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 1928 2012, . 1930 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 1931 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 1932 DOI 10.17487/RFC6817, December 2012, 1933 . 1935 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1936 Morris, J., Hansen, M., and R. Smith, "Privacy 1937 Considerations for Internet Protocols", RFC 6973, 1938 DOI 10.17487/RFC6973, July 2013, 1939 . 1941 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1942 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1943 DOI 10.17487/RFC7540, May 2015, 1944 . 1946 [RFC7560] Kuehlewind, M., Ed., Scheffenegger, R., and B. Briscoe, 1947 "Problem Statement and Requirements for Increased Accuracy 1948 in Explicit Congestion Notification (ECN) Feedback", 1949 RFC 7560, DOI 10.17487/RFC7560, August 2015, 1950 . 1952 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 1953 Recommendations Regarding Active Queue Management", 1954 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 1955 . 1957 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1958 Chaining (SFC) Architecture", RFC 7665, 1959 DOI 10.17487/RFC7665, October 2015, 1960 . 1962 [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 1963 Concepts, Abstract Mechanism, and Requirements", RFC 7713, 1964 DOI 10.17487/RFC7713, December 2015, 1965 . 1967 [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, 1968 "Proportional Integral Controller Enhanced (PIE): A 1969 Lightweight Control Scheme to Address the Bufferbloat 1970 Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, 1971 . 1973 [RFC8034] White, G. and R. Pan, "Active Queue Management (AQM) Based 1974 on Proportional Integral Controller Enhanced PIE) for 1975 Data-Over-Cable Service Interface Specifications (DOCSIS) 1976 Cable Modems", RFC 8034, DOI 10.17487/RFC8034, February 1977 2017, . 1979 [RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and 1980 Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, 1981 May 2017, . 1983 [RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., 1984 and G. Judd, "Data Center TCP (DCTCP): TCP Congestion 1985 Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, 1986 October 2017, . 1988 [RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, 1989 J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler 1990 and Active Queue Management Algorithm", RFC 8290, 1991 DOI 10.17487/RFC8290, January 2018, 1992 . 1994 [RFC8298] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation 1995 for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December 1996 2017, . 1998 [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion 1999 Notification (ECN) Experimentation", RFC 8311, 2000 DOI 10.17487/RFC8311, January 2018, 2001 . 2003 [RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and 2004 R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", 2005 RFC 8312, DOI 10.17487/RFC8312, February 2018, 2006 . 2008 [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of 2009 Pervasive Encryption on Operators", RFC 8404, 2010 DOI 10.17487/RFC8404, July 2018, 2011 . 2013 [RFC8511] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 2014 "TCP Alternative Backoff with ECN (ABE)", RFC 8511, 2015 DOI 10.17487/RFC8511, December 2018, 2016 . 2018 [RFC8888] Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP 2019 Control Protocol (RTCP) Feedback for Congestion Control", 2020 RFC 8888, DOI 10.17487/RFC8888, January 2021, 2021 . 2023 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 2024 Multiplexed and Secure Transport", RFC 9000, 2025 DOI 10.17487/RFC9000, May 2021, 2026 . 2028 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 2029 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 2030 . 2032 [SCReAM] Johansson, I., "SCReAM", github repository; , 2033 . 2036 [TCP-CA] Jacobson, V. and M.J. Karels, "Congestion Avoidance and 2037 Control", Laurence Berkeley Labs Technical Report , 2038 November 1988, . 2040 [TCP-sub-mss-w] 2041 Briscoe, B. and K. De Schepper, "Scaling TCP's Congestion 2042 Window for Small Round Trip Times", BT Technical Report 2043 TR-TUB8-2015-002, May 2015, 2044 . 2047 [UnorderedLTE] 2048 Austrheim, M.V., "Implementing immediate forwarding for 4G 2049 in a network simulator", Masters Thesis, Uni Oslo , June 2050 2019. 2052 Appendix A. Standardization items 2054 The following table includes all the items that will need to be 2055 standardized to provide a full L4S architecture. 2057 The table is too wide for the ASCII draft format, so it has been 2058 split into two, with a common column of row index numbers on the 2059 left. 2061 The columns in the second part of the table have the following 2062 meanings: 2064 WG: The IETF WG most relevant to this requirement. The "tcpm/iccrg" 2065 combination refers to the procedure typically used for congestion 2066 control changes, where tcpm owns the approval decision, but uses 2067 the iccrg for expert review [NewCC_Proc]; 2069 TCP: Applicable to all forms of TCP congestion control; 2071 DCTCP: Applicable to Data Center TCP as currently used (in 2072 controlled environments); 2074 DCTCP bis: Applicable to any future Data Center TCP congestion 2075 control intended for controlled environments; 2077 XXX Prague: Applicable to a Scalable variant of XXX (TCP/SCTP/RMCAT) 2078 congestion control. 2080 +=====+========================+====================================+ 2081 | Req | Requirement | Reference | 2082 | # | | | 2083 +=====+========================+====================================+ 2084 | 0 | ARCHITECTURE | | 2085 +-----+------------------------+------------------------------------+ 2086 | 1 | L4S IDENTIFIER | [I-D.ietf-tsvwg-ecn-l4s-id] S.3 | 2087 +-----+------------------------+------------------------------------+ 2088 | 2 | DUAL QUEUE AQM | [I-D.ietf-tsvwg-aqm-dualq-coupled] | 2089 +-----+------------------------+------------------------------------+ 2090 | 3 | Suitable ECN | [I-D.ietf-tcpm-accurate-ecn] | 2091 | | Feedback | S.4.2, | 2092 | | | [I-D.stewart-tsvwg-sctpecn]. | 2093 +-----+------------------------+------------------------------------+ 2094 +-----+------------------------+------------------------------------+ 2095 | | SCALABLE TRANSPORT - | | 2096 | | SAFETY ADDITIONS | | 2097 +-----+------------------------+------------------------------------+ 2098 | 4-1 | Fall back to Reno/ | [I-D.ietf-tsvwg-ecn-l4s-id] S.4.3, | 2099 | | Cubic on loss | [RFC8257] | 2100 +-----+------------------------+------------------------------------+ 2101 | 4-2 | Fall back to Reno/ | [I-D.ietf-tsvwg-ecn-l4s-id] S.4.3 | 2102 | | Cubic if classic ECN | | 2103 | | bottleneck detected | | 2104 +-----+------------------------+------------------------------------+ 2105 +-----+------------------------+------------------------------------+ 2106 | 4-3 | Reduce RTT- | [I-D.ietf-tsvwg-ecn-l4s-id] S.4.3 | 2107 | | dependence | | 2108 +-----+------------------------+------------------------------------+ 2109 +-----+------------------------+------------------------------------+ 2110 | 4-4 | Scaling TCP's | [I-D.ietf-tsvwg-ecn-l4s-id] S.4.3, | 2111 | | Congestion Window | [TCP-sub-mss-w] | 2112 | | for Small Round Trip | | 2113 | | Times | | 2114 +-----+------------------------+------------------------------------+ 2115 | | SCALABLE TRANSPORT - | | 2116 | | PERFORMANCE | | 2117 | | ENHANCEMENTS | | 2118 +-----+------------------------+------------------------------------+ 2119 | 5-1 | Setting ECT in TCP | [I-D.ietf-tcpm-generalized-ecn] | 2120 | | Control Packets and | | 2121 | | Retransmissions | | 2122 +-----+------------------------+------------------------------------+ 2123 | 5-2 | Faster-than-additive | [I-D.ietf-tsvwg-ecn-l4s-id] (Appx | 2124 | | increase | A.2.2) | 2125 +-----+------------------------+------------------------------------+ 2126 | 5-3 | Faster Convergence | [I-D.ietf-tsvwg-ecn-l4s-id] (Appx | 2127 | | at Flow Start | A.2.2) | 2128 +-----+------------------------+------------------------------------+ 2130 Table 1 2132 +=====+========+=====+=======+===========+========+========+========+ 2133 | # | WG | TCP | DCTCP | DCTCP-bis | TCP | SCTP | RMCAT | 2134 | | | | | | Prague | Prague | Prague | 2135 +=====+========+=====+=======+===========+========+========+========+ 2136 | 0 | tsvwg | Y | Y | Y | Y | Y | Y | 2137 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2138 | 1 | tsvwg | | | Y | Y | Y | Y | 2139 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2140 | 2 | tsvwg | n/a | n/a | n/a | n/a | n/a | n/a | 2141 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2142 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2143 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2144 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2145 | 3 | tcpm | Y | Y | Y | Y | n/a | n/a | 2146 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2147 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2148 | 4-1 | tcpm | | Y | Y | Y | Y | Y | 2149 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2150 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2151 | 4-2 | tcpm/ | | | | Y | Y | ? | 2152 | | iccrg? | | | | | | | 2153 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2154 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2155 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2156 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2157 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2158 | 4-3 | tcpm/ | | | Y | Y | Y | ? | 2159 | | iccrg? | | | | | | | 2160 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2161 | 4-4 | tcpm | Y | Y | Y | Y | Y | ? | 2162 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2163 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2164 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2165 | 5-1 | tcpm | Y | Y | Y | Y | n/a | n/a | 2166 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2167 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2168 | 5-2 | tcpm/ | | | Y | Y | Y | ? | 2169 | | iccrg? | | | | | | | 2170 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2171 | 5-3 | tcpm/ | | | Y | Y | Y | ? | 2172 | | iccrg? | | | | | | | 2173 +-----+--------+-----+-------+-----------+--------+--------+--------+ 2175 Table 2 2177 Authors' Addresses 2179 Bob Briscoe (editor) 2180 Independent 2181 United Kingdom 2183 Email: ietf@bobbriscoe.net 2184 URI: http://bobbriscoe.net/ 2186 Koen De Schepper 2187 Nokia Bell Labs 2188 Antwerp 2189 Belgium 2191 Email: koen.de_schepper@nokia.com 2192 URI: https://www.bell-labs.com/usr/koen.de_schepper 2194 Marcelo Bagnulo 2195 Universidad Carlos III de Madrid 2196 Av. Universidad 30 2197 Leganes, Madrid 28911 2198 Spain 2200 Phone: 34 91 6249500 2201 Email: marcelo@it.uc3m.es 2202 URI: http://www.it.uc3m.es 2204 Greg White 2205 CableLabs 2206 United States of America 2208 Email: G.White@CableLabs.com