draft-ietf-tsvwg-l4s-arch-05.txt   draft-ietf-tsvwg-l4s-arch-06.txt 
Transport Area Working Group B. Briscoe, Ed. Transport Area Working Group B. Briscoe, Ed.
Internet-Draft Independent Internet-Draft Independent
Intended status: Informational K. De Schepper Intended status: Informational K. De Schepper
Expires: August 23, 2020 Nokia Bell Labs Expires: September 10, 2020 Nokia Bell Labs
M. Bagnulo Braun M. Bagnulo Braun
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
G. White G. White
CableLabs CableLabs
February 20, 2020 March 9, 2020
Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service:
Architecture Architecture
draft-ietf-tsvwg-l4s-arch-05 draft-ietf-tsvwg-l4s-arch-06
Abstract Abstract
This document describes the L4S architecture, which enables Internet This document describes the L4S architecture, which enables Internet
applications to achieve Low Latency, Low Loss, and Scalable applications to achieve Low Latency, Low Loss, and Scalable
throughput (L4S), while coexisting on shared network bottlenecks with throughput (L4S). The insight on which L4S is based is that the root
existing Internet applications that are not built to take advantage cause of queuing delay is in the congestion controllers of senders,
of this new technology. not in the queue itself. The L4S architecture is intended to enable
*all* Internet applications to transition away from congestion
In traditional bottleneck links that utilize a single, shared egress control algorithms that cause queuing delay, to a new class of
queue, a variety of application traffic flows can share the congestion controls that utilize explicit congestion signaling
bottleneck queue simultaneously. As a result, each sender's behavior provided by the network. This new class of congestion control can
and its response to the congestion signals (delay, packet drop, ECN provide low latency for capacity-seeking flows, so applications can
marking) provided by the queue can impact the performance of all achieve both high bandwidth and low latency.
other applications that share the link. Furthermore, it is
considered important that new protocols coexist in a reasonably fair
manner with existing protocols (most notably TCP and QUIC). As a
result, senders tend to normalize on behaviors that are not
significantly different than those in use by the majority of the
existing senders. For many years, the majority of traffic on the
Internet has used either the Reno AIMD congestion controller or the
Cubic algorithm, and as a result any newly proposed congestion
controller needs to demonstrate that it provides reasonable fairness
when sharing a bottleneck with flows that use Reno or Cubic. This
has led to an ossification in congestion control, where improved
congestion controllers cannot easily be deployed on the Internet.
It is well known that the common existing congestion controllers
(e.g. Reno and Cubic) increase their congestion window (the amount
of data in flight) until they induce congestion, and they respond to
the congestion signals of packet loss (or equivalently ECN marks) by
significantly reducing their congestion window. This leads to a
large sawtooth of the congestion window that manifests itself as a
combination of queue delay and/or link underutilization.
Meanwhile, in closed network environments, such as data centres, new
congestion controllers (e.g. DCTCP [RFC8257]) have been deployed
that significantly outperform Reno and Cubic in terms of queue delay
and link utilization across a much wider range of network conditions.
The L4S architecture provides an approach that allows for the The architecture primarily concerns incremental deployment. It
deployment of next generation congestion controllers while preserving defines mechanisms that allow both classes of congestion control to
reasonably fair coexistence with Reno and Cubic. coexist in a shared network. These mechanisms aim to ensure that the
latency and throughput performance using an L4S-compliant congestion
controller is usually much better (and never worse) than the
performance would have been using a 'Classic' congestion controller,
and that competing flows continuing to use 'Classic' controllers are
typically not impacted by the presence of L4S. These characteristics
are important to encourage adoption of L4S congestion control
algorithms and L4S compliant network elements.
The L4S architecture consists of three components: network support to The L4S architecture consists of three components: network support to
isolate L4S traffic from other traffic and to provide appropriate isolate L4S traffic from classic traffic and to provide appropriate
congestion signaling to both types; protocol features that allow congestion signaling to both types; protocol features that allow
network elements to identify L4S traffic and allow for communication network elements to identify L4S traffic and allow for communication
of congestion signaling; and host support for immediate congestion of congestion signaling; and host support for immediate congestion
signaling and an appropriate congestion response that enables signaling with an appropriate congestion response that enables
scalable performance. scalable performance.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 23, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. L4S Architecture Overview . . . . . . . . . . . . . . . . . . 5 2. L4S Architecture Overview . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. L4S Architecture Components . . . . . . . . . . . . . . . . . 8 4. L4S Architecture Components . . . . . . . . . . . . . . . . . 8
5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Why These Primary Components? . . . . . . . . . . . . . . 11 5.1. Why These Primary Components? . . . . . . . . . . . . . . 11
5.2. Why Not Alternative Approaches? . . . . . . . . . . . . . 13 5.2. Why Not Alternative Approaches? . . . . . . . . . . . . . 13
6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Applications . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Applications . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 17
6.3. Deployment Considerations . . . . . . . . . . . . . . . . 18 6.3. Deployment Considerations . . . . . . . . . . . . . . . . 18
6.3.1. Deployment Topology . . . . . . . . . . . . . . . . . 19 6.3.1. Deployment Topology . . . . . . . . . . . . . . . . . 19
6.3.2. Deployment Sequences . . . . . . . . . . . . . . . . 20 6.3.2. Deployment Sequences . . . . . . . . . . . . . . . . 20
6.3.3. L4S Flow but Non-L4S Bottleneck . . . . . . . . . . . 22 6.3.3. L4S Flow but Non-L4S Bottleneck . . . . . . . . . . . 22
6.3.4. Other Potential Deployment Issues . . . . . . . . . . 23 6.3.4. Other Potential Deployment Issues . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8.1. Traffic (Non-)Policing . . . . . . . . . . . . . . . . . 23 8.1. Traffic (Non-)Policing . . . . . . . . . . . . . . . . . 23
8.2. 'Latency Friendliness' . . . . . . . . . . . . . . . . . 24 8.2. 'Latency Friendliness' . . . . . . . . . . . . . . . . . 24
8.3. Interaction between Rate Policing and L4S . . . . . . . . 25 8.3. Interaction between Rate Policing and L4S . . . . . . . . 25
8.4. ECN Integrity . . . . . . . . . . . . . . . . . . . . . . 26 8.4. ECN Integrity . . . . . . . . . . . . . . . . . . . . . . 26
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Standardization items . . . . . . . . . . . . . . . 33 Appendix A. Standardization items . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
It is increasingly common for _all_ of a user's applications at any It is increasingly common for _all_ of a user's applications at any
one time to require low delay: interactive Web, Web services, voice, one time to require low delay: interactive Web, Web services, voice,
conversational video, interactive video, interactive remote presence, conversational video, interactive video, interactive remote presence,
instant messaging, online gaming, remote desktop, cloud-based instant messaging, online gaming, remote desktop, cloud-based
skipping to change at page 4, line 38 skipping to change at page 4, line 21
performance improvement from L4S must be sufficient that network performance improvement from L4S must be sufficient that network
operators will be motivated to deploy it. operators will be motivated to deploy it.
Active Queue Management (AQM) is part of the solution to queuing Active Queue Management (AQM) is part of the solution to queuing
under load. AQM improves performance for all traffic, but there is a under load. AQM improves performance for all traffic, but there is a
limit to how much queuing delay can be reduced by solely changing the limit to how much queuing delay can be reduced by solely changing the
network; without addressing the root of the problem. network; without addressing the root of the problem.
The root of the problem is the presence of standard TCP congestion The root of the problem is the presence of standard TCP congestion
control (Reno [RFC5681]) or compatible variants (e.g. TCP Cubic control (Reno [RFC5681]) or compatible variants (e.g. TCP Cubic
[RFC8312]). We shall use the term 'Classic' for these Reno-Friendly [RFC8312]). We shall use the term 'Classic' for these Reno-friendly
congestion controls. It has been demonstrated that if the sending congestion controls. It has been demonstrated that if the sending
host replaces a Classic congestion control with a 'Scalable' host replaces a Classic congestion control with a 'Scalable'
alternative, when a suitable AQM is deployed in the network the alternative, when a suitable AQM is deployed in the network the
performance under load of all the above interactive applications can performance under load of all the above interactive applications can
be significantly improved. For instance, queuing delay under heavy be significantly improved. For instance, queuing delay under heavy
load with the example DCTCP/DualQ solution cited below is roughly 1 load with the example DCTCP/DualQ solution cited below is roughly 1
millisecond (1 to 2 ms) at the 99th percentile without losing link millisecond (1 to 2 ms) at the 99th percentile without losing link
utilization. This compares with 5 to 20 ms on _average_ with a utilization. This compares with 5 to 20 ms on _average_ with a
Classic congestion control and current state-of-the-art AQMs such as Classic congestion control and current state-of-the-art AQMs such as
fq_CoDel [RFC8290] or PIE [RFC8033] and about 20-30 ms at the 99th fq_CoDel [RFC8290] or PIE [RFC8033] and about 20-30 ms at the 99th
skipping to change at page 5, line 39 skipping to change at page 5, line 22
inspecting how many flows at any one time are using each. And inspecting how many flows at any one time are using each. And
capacity in access networks is too costly to arbitrarily partition capacity in access networks is too costly to arbitrarily partition
into two. The Dual Queue Coupled AQM was developed as a minimal into two. The Dual Queue Coupled AQM was developed as a minimal
complexity solution to this problem. It acts like a 'semi- complexity solution to this problem. It acts like a 'semi-
permeable' membrane that partitions latency but not bandwidth. permeable' membrane that partitions latency but not bandwidth.
Note that there is no bandwidth priority between the two queues Note that there is no bandwidth priority between the two queues
because they are for transition from Classic to L4S behaviour, not because they are for transition from Classic to L4S behaviour, not
prioritization. Section 4 gives a high level explanation of how prioritization. Section 4 gives a high level explanation of how
FQ and DualQ solutions work, and FQ and DualQ solutions work, and
[I-D.ietf-tsvwg-aqm-dualq-coupled] gives a full explanation of the [I-D.ietf-tsvwg-aqm-dualq-coupled] gives a full explanation of the
Coupled DualQ. DualQ Coupled AQM framework.
2) Protocol: A host needs to distinguish L4S and Classic packets 2) Protocol: A host needs to distinguish L4S and Classic packets
with an identifier so that the network can classify them into with an identifier so that the network can classify them into
their separate treatments. [I-D.ietf-tsvwg-ecn-l4s-id] considers their separate treatments. [I-D.ietf-tsvwg-ecn-l4s-id] considers
various alternative identifiers, and concludes that all various alternative identifiers, and concludes that all
alternatives involve compromises, but the ECT(1) and CE codepoints alternatives involve compromises, but the ECT(1) and CE codepoints
of the ECN field represent a workable solution. of the ECN field represent a workable solution.
3) Host: Scalable congestion controls already exist. They solve the 3) Host: Scalable congestion controls already exist. They solve the
scaling problem with Reno congestion control that was explained in scaling problem with Reno congestion control that was explained in
skipping to change at page 6, line 46 skipping to change at page 6, line 34
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. In this document are to be interpreted as described in [RFC2119]. In this
document, these words will appear with that interpretation only when document, these words will appear with that interpretation only when
in ALL CAPS. Lower case uses of these words are not to be in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance. COMMENT: Since this interpreted as carrying RFC-2119 significance. COMMENT: Since this
will be an information document, This should be removed. will be an information document, This should be removed.
Classic Congestion Control: A congestion control behaviour that can Classic Congestion Control: A congestion control behaviour that can
co-exist with standard TCP Reno [RFC5681] without causing flow co-exist with standard TCP Reno [RFC5681] without causing
rate starvation. With Classic congestion controls, as flow rate significantly negative impact on its flow rate [RFC5033]. With
scales, the number of round trips between congestion signals Classic congestion controls, as flow rate scales, the number of
(losses or ECN marks) rises with the flow rate. So it takes round trips between congestion signals (losses or ECN marks) rises
longer and longer to recover after each congestion event. with the flow rate. So it takes longer and longer to recover
after each congestion event. Therefore control of queuing and
Therefore control of queuing and utilization becomes very slack, utilization becomes very slack, and the slightest disturbance
and the slightest disturbance prevents a high rate from being prevents a high rate from being attained [RFC3649].
attained [RFC3649].
For instance, with 1500 byte packets and an end-to-end round trip For instance, with 1500 byte packets and an end-to-end round trip
time (RTT) of 36 ms, over the years, as Reno flow rate scales from time (RTT) of 36 ms, over the years, as Reno flow rate scales from
2 to 100 Mb/s the number of round trips taken to recover from a 2 to 100 Mb/s the number of round trips taken to recover from a
congestion event rises proportionately, from 4 to 200. Cubic was congestion event rises proportionately, from 4 to 200. Cubic
developed to be less unscalable, but it is approaching its scaling [RFC8312] was developed to be less unscalable, but it is
limit; with the same RTT of 36ms, at 100Mb/s it takes over 300 approaching its scaling limit; with the same RTT of 36ms, at
round trips to recover, and at 800 Mb/s its recovery time doubles 100Mb/s it takes about 106 round trips to recover, and at 800 Mb/s
to over 600 round trips, or more than 20 seconds. its recovery time triples to over 340 round trips, or still more
than 12 seconds (Reno would take 57 seconds).
Scalable Congestion Control: A congestion control where the average Scalable Congestion Control: A congestion control where the average
time from one congestion signal to the next (the recovery time) time from one congestion signal to the next (the recovery time)
remains invariant as the flow rate scales, all other factors being remains invariant as the flow rate scales, all other factors being
equal. This maintains the same degree of control over queueing equal. This maintains the same degree of control over queueing
and utilization whatever the flow rate, as well as ensuring that and utilization whatever the flow rate, as well as ensuring that
high throughput is robust to disturbances. For instance, DCTCP high throughput is robust to disturbances. For instance, DCTCP
averages 2 congestion signals per round-trip whatever the flow averages 2 congestion signals per round-trip whatever the flow
rate. See Section 4.3 of [I-D.ietf-tsvwg-ecn-l4s-id] for more rate. See Section 4.3 of [I-D.ietf-tsvwg-ecn-l4s-id] for more
explanation. explanation.
Classic service: The Classic service is intended for all the Classic service: The Classic service is intended for all the
congestion control behaviours that co-exist with Reno [RFC5681] congestion control behaviours that co-exist with Reno [RFC5681]
(e.g. Reno itself, Cubic [RFC8312], Compound (e.g. Reno itself, Cubic [RFC8312], Compound
[I-D.sridharan-tcpm-ctcp], TFRC [RFC5348]). [I-D.sridharan-tcpm-ctcp], TFRC [RFC5348]). The term 'Classic
queue' means a queue providing the Classic service.
Low-Latency, Low-Loss Scalable throughput (L4S) service: The 'L4S' Low-Latency, Low-Loss Scalable throughput (L4S) service: The 'L4S'
service is intended for traffic from scalable congestion control service is intended for traffic from scalable congestion control
algorithms, such as Data Center TCP [RFC8257]. The L4S service is algorithms, such as Data Center TCP [RFC8257]. The L4S service is
for more general traffic than just DCTCP--it allows the set of for more general traffic than just DCTCP--it allows the set of
congestion controls with similar scaling properties to DCTCP to congestion controls with similar scaling properties to DCTCP to
evolve (e.g. Relentless TCP [Mathis09], TCP Prague [LinuxPrague] evolve (e.g. Relentless TCP [Mathis09], TCP Prague [PragueLinux]
and the L4S variant of SCREAM for real-time media [RFC8298]). and the L4S variant of SCREAM for real-time media [RFC8298]). The
term 'L4S queue' means a queue providing the L4S service.
The terms Classic or L4S can also qualify other nouns, such as
'queue', 'codepoint', 'identifier', 'classification', 'packet',
'flow'. For example: an L4S packet means a packet with an L4S
identifier sent from an L4S congestion control.
Both Classic and L4S services can cope with a proportion of Both Classic and L4S services can cope with a proportion of
unresponsive or less-responsive traffic as well, as long as it unresponsive or less-responsive traffic as well, as long as it
does not build a queue (e.g. DNS, VoIP, game sync datagrams, does not build a queue (e.g. DNS, VoIP, game sync datagrams,
etc). etc).
The terms Classic or L4S can also qualify other nouns, such Reno-friendly: The subset of Classic traffic that excludes
'queue', 'codepoint', 'identifier', 'classification', 'packet', unresponsive traffic and excludes experimental congestion controls
'flow'. For example: a 'Classic queue', means a queue providing intended to coexist with Reno but without always being strictly
the Classic service; an L4S packet means a packet with an L4S friendly to it (as allowed by [RFC5033]). Reno-friendly is used
identifier sent from an L4S congestion control. in place of 'TCP-friendly', given that the TCP protocol is used
with many different congestion control behaviours.
Classic ECN: The original Explicit Congestion Notification (ECN) Classic ECN: The original Explicit Congestion Notification (ECN)
protocol [RFC3168], which requires ECN signals to be treated the protocol [RFC3168], which requires ECN signals to be treated the
same as drops, both when generated in the network and when same as drops, both when generated in the network and when
responded to by the sender. The names used for the four responded to by the sender.
codepoints of the 2-bit IP-ECN field are as defined in [RFC3168]:
Not ECT, ECT(0), ECT(1) and CE, where ECT stands for ECN-Capable The names used for the four codepoints of the 2-bit IP-ECN field
Transport and CE stands for Congestion Experienced. are as defined in [RFC3168]: Not ECT, ECT(0), ECT(1) and CE, where
ECT stands for ECN-Capable Transport and CE stands for Congestion
Experienced.
Site: A home, mobile device, small enterprise or campus, where the Site: A home, mobile device, small enterprise or campus, where the
network bottleneck is typically the access link to the site. Not network bottleneck is typically the access link to the site. Not
all network arrangements fit this model but it is a useful, widely all network arrangements fit this model but it is a useful, widely
applicable generalisation. applicable generalization.
4. L4S Architecture Components 4. L4S Architecture Components
The L4S architecture is composed of the following elements. The L4S architecture is composed of the following elements.
Protocols:The L4S architecture encompasses the two identifier changes Protocols:The L4S architecture encompasses the two identifier changes
(an unassignment and an assignment) and optional further identifiers: (an unassignment and an assignment) and optional further identifiers:
a. An essential aspect of a scalable congestion control is the use a. An essential aspect of a scalable congestion control is the use
of explicit congestion signals rather than losses, because the of explicit congestion signals rather than losses, because the
skipping to change at page 9, line 32 skipping to change at page 9, line 27
[I-D.white-tsvwg-nqb]), or operator-specific identifiers. [I-D.white-tsvwg-nqb]), or operator-specific identifiers.
Network components: The L4S architecture encompasses either dual- Network components: The L4S architecture encompasses either dual-
queue or per-flow queue solutions: queue or per-flow queue solutions:
a. The Coupled Dual Queue AQM achieves the 'semi-permeable' membrane a. The Coupled Dual Queue AQM achieves the 'semi-permeable' membrane
property mentioned earlier as follows. The obvious part is that property mentioned earlier as follows. The obvious part is that
using two separate queues isolates the queuing delay of one from using two separate queues isolates the queuing delay of one from
the other. The less obvious part is how the two queues act as if the other. The less obvious part is how the two queues act as if
they are a single pool of bandwidth without the scheduler needing they are a single pool of bandwidth without the scheduler needing
to decide between them. This is achieved by making the Classic to decide between them. This is achieved by having the Classic
traffic appear as if it is an equivalent amount of traffic in the AQM provide a congestion signal to both queues in a manner that
L4S queue, by coupling across the drop probability of the Classic ensures a consistent response from the two types of congestion
AQM to drive the ECN marking level applied to L4S traffic. This control. In other words, the Classic AQM generates a drop/mark
makes the L4S flows slow down to leave just enough capacity for probability based on congestion in the Classic queue, uses this
the Classic traffic (as they would if they were the same type of probability to drop/mark packets in that queue, and also uses
traffic sharing the same queue). Then the scheduler can serve this probability to affect the marking probability in the L4S
the L4S queue with priority, because the L4S traffic isn't queue. This coupling of the congestion signaling between the two
offering up enough traffic to use all the priority that it is queues makes the L4S flows slow down to leave the right amount of
given. Therefore, on short time-scales (sub-round-trip) the capacity for the Classic traffic (as they would if they were the
same type of traffic sharing the same queue). Then the scheduler
can serve the L4S queue with priority, because the L4S traffic
isn't offering up enough traffic to use all the priority that it
is given. Therefore, on short time-scales (sub-round-trip) the
prioritization of the L4S queue protects its low latency by prioritization of the L4S queue protects its low latency by
allowing bursts to dissipate quickly; but on longer time-scales allowing bursts to dissipate quickly; but on longer time-scales
(round-trip and longer) the Classic queue creates an equal and (round-trip and longer) the Classic queue creates an equal and
opposite pressure against the L4S traffic to ensure that neither opposite pressure against the L4S traffic to ensure that neither
has priority when it comes to bandwidth. The tension between has priority when it comes to bandwidth. The tension between
prioritizing L4S and coupling marking from Classic results in prioritizing L4S and coupling marking from Classic results in
per-flow fairness. To protect against unresponsive traffic in per-flow fairness. To protect against unresponsive traffic in
the L4S queue taking advantage of the prioritization and starving the L4S queue taking advantage of the prioritization and starving
the Classic queue, it is advisable not to use strict priority, the Classic queue, it is advisable not to use strict priority,
but instead to use a weighted scheduler. but instead to use a weighted scheduler.
When there is no Classic traffic, the L4S queue's AQM comes into When there is no Classic traffic, the L4S queue's AQM comes into
play, and it sets an appropriate marking rate to maintain ultra- play, and it sets an appropriate marking rate to maintain ultra-
low queuing delay. low queuing delay.
The Coupled Dual Queue AQM has been specified as generically as The Coupled Dual Queue AQM has been specified as generically as
possible [I-D.ietf-tsvwg-aqm-dualq-coupled] without specifying possible [I-D.ietf-tsvwg-aqm-dualq-coupled] without specifying
the particular AQMs to use in the two queues so that designers the particular AQMs to use in the two queues so that designers
are free to implement diverse ideas. Then informational are free to implement diverse ideas. Informational appendices in
appendices give pseudocode examples of different specific AQM that draft give pseudocode examples of two different specific AQM
approaches. Initially a zero-config variant of RED called Curvy approaches: a variant of PIE called DualPI2 (pronounced Dual PI
RED was implemented, tested and documented. Then, a variant of Squared) [DualPI2Linux], and a zero-config variant of RED called
PIE called DualPI2 (pronounced Dual PI Squared) [DualPI2Linux] Curvy RED. A DualQ Coupled AQM variant based on PIE has also
was implemented and found to perform better than Curvy RED over a been specified and implemented for Low Latency DOCSIS
wide range of conditions, so it was documented in another [DOCSIS3.1].
appendix of [I-D.ietf-tsvwg-aqm-dualq-coupled]. A Coupled DualQ
variant based on PIE has also been specified and implemented for
Low Latency DOCSIS [DOCSIS3.1].
b. A scheduler with per-flow queues can be used for L4S. It is b. A scheduler with per-flow queues can be used for L4S. It is
simple to modify an existing design such as FQ-CoDel or FQ-PIE. simple to modify an existing design such as FQ-CoDel or FQ-PIE.
For instance within each queue of an FQ_CoDel system, as well as For instance within each queue of an FQ_CoDel system, as well as
a CoDel AQM, immediate (unsmoothed) shallow threshold ECN marking a CoDel AQM, immediate (unsmoothed) shallow threshold ECN marking
has been added. Then the Classic AQM such as CoDel or PIE is has been added. Then the Classic AQM such as CoDel or PIE is
applied to non-ECN or ECT(0) packets, while the shallow threshold applied to non-ECN or ECT(0) packets, while the shallow threshold
is applied to ECT(1) packets, to give sub-millisecond average is applied to ECT(1) packets, to give sub-millisecond average
queue delay. queue delay.
skipping to change at page 13, line 14 skipping to change at page 13, line 14
Low loss: Latency is not the only concern of L4S. The 'Low Loss" Low loss: Latency is not the only concern of L4S. The 'Low Loss"
part of the name denotes that L4S generally achieves zero part of the name denotes that L4S generally achieves zero
congestion loss due to its use of ECN. Otherwise, loss would congestion loss due to its use of ECN. Otherwise, loss would
itself cause delay, particularly for short flows, due to itself cause delay, particularly for short flows, due to
retransmission delay [RFC2884]. retransmission delay [RFC2884].
Scalable throughput: The "Scalable throughput" part of the name Scalable throughput: The "Scalable throughput" part of the name
denotes that the per-flow throughput of scalable congestion denotes that the per-flow throughput of scalable congestion
controls should scale indefinitely, avoiding the imminent scaling controls should scale indefinitely, avoiding the imminent scaling
problems with Reno-Friendly congestion control algorithms problems with Reno-friendly congestion control algorithms
[RFC3649]. It was known when TCP congestion avoidance was first [RFC3649]. It was known when TCP congestion avoidance was first
developed that it would not scale to high bandwidth-delay products developed that it would not scale to high bandwidth-delay products
(see footnote 6 in [TCP-CA]). Today, regular broadband bit-rates (see footnote 6 in [TCP-CA]). Today, regular broadband bit-rates
over WAN distances are already beyond the scaling range of Classic over WAN distances are already beyond the scaling range of Classic
Reno congestion control. So `less unscalable' Cubic [RFC8312] and Reno congestion control. So `less unscalable' Cubic [RFC8312] and
Compound [I-D.sridharan-tcpm-ctcp] variants of TCP have been Compound [I-D.sridharan-tcpm-ctcp] variants of TCP have been
successfully deployed. However, these are now approaching their successfully deployed. However, these are now approaching their
scaling limits. For instance, at 800Mb/s with a 20ms round trip, scaling limits. For instance, at 800Mb/s with a 20ms round trip,
Cubic induces a congestion signal only every 500 round trips or 10 Cubic induces a congestion signal only every 500 round trips or 10
seconds, which makes its dynamic control very sloppy. In contrast seconds, which makes its dynamic control very sloppy. In contrast
skipping to change at page 17, line 31 skipping to change at page 17, line 31
The following use-cases for L4S are being considered by various The following use-cases for L4S are being considered by various
interested parties: interested parties:
o Where the bottleneck is one of various types of access network: o Where the bottleneck is one of various types of access network:
DSL, cable, mobile, satellite DSL, cable, mobile, satellite
* Radio links (cellular, WiFi, satellite) that are distant from * Radio links (cellular, WiFi, satellite) that are distant from
the source are particularly challenging. The radio link the source are particularly challenging. The radio link
capacity can vary rapidly by orders of magnitude, so it is capacity can vary rapidly by orders of magnitude, so it is
often desirable to hold a buffer to utilise sudden increases of often desirable to hold a buffer to utilize sudden increases of
capacity; capacity;
* cellular networks are further complicated by a perceived need * cellular networks are further complicated by a perceived need
to buffer in order to make hand-overs imperceptible; to buffer in order to make hand-overs imperceptible;
* Satellite networks generally have a very large base RTT, so * Satellite networks generally have a very large base RTT, so
even with minimal queuing, overall delay can never be extremely even with minimal queuing, overall delay can never be extremely
low; low;
* Nonetheless, it is certainly desirable not to hold a buffer * Nonetheless, it is certainly desirable not to hold a buffer
skipping to change at page 22, line 25 skipping to change at page 22, line 25
Note that other deployment sequences might occur. For instance: the Note that other deployment sequences might occur. For instance: the
upstream might be deployed first; a non-TCP protocol might be used upstream might be deployed first; a non-TCP protocol might be used
end-to-end, e.g. QUIC, RMCAT; a body such as the 3GPP might require end-to-end, e.g. QUIC, RMCAT; a body such as the 3GPP might require
L4S to be implemented in 5G user equipment, or other random acts of L4S to be implemented in 5G user equipment, or other random acts of
kindness. kindness.
6.3.3. L4S Flow but Non-L4S Bottleneck 6.3.3. L4S Flow but Non-L4S Bottleneck
If L4S is enabled between two hosts but there is no L4S AQM at the If L4S is enabled between two hosts but there is no L4S AQM at the
bottleneck, any drop from the bottleneck will trigger the L4S sender bottleneck, any drop from the bottleneck will trigger the L4S sender
to fall back to a classic ('Reno-Friendly') behaviour (see to fall back to a classic ('Reno-friendly') behaviour (see
Appendix A.1.3 of [I-D.ietf-tsvwg-ecn-l4s-id]). Appendix A.1.3 of [I-D.ietf-tsvwg-ecn-l4s-id]).
Unfortunately, as well as protecting legacy traffic, this rule Unfortunately, as well as protecting legacy traffic, this rule
degrades the L4S service whenever there is a loss, even if the loss degrades the L4S service whenever there is a loss, even if the loss
was not from a non-DualQ bottleneck (false negative). And was not from a non-DualQ bottleneck (false negative). And
unfortunately, prevalent drop can be due to other causes, e.g.: unfortunately, prevalent drop can be due to other causes, e.g.:
o congestion loss at other transient bottlenecks, e.g. due to bursts o congestion loss at other transient bottlenecks, e.g. due to bursts
in shallower queues; in shallower queues;
skipping to change at page 23, line 5 skipping to change at page 23, line 5
unlikely to be due to congestion (using some ideas from BBR unlikely to be due to congestion (using some ideas from BBR
[I-D.cardwell-iccrg-bbr-congestion-control] but with no need to [I-D.cardwell-iccrg-bbr-congestion-control] but with no need to
ignore nearly all losses). This could mask any of the above types ignore nearly all losses). This could mask any of the above types
of loss (requires consensus on how to safely interoperate with of loss (requires consensus on how to safely interoperate with
drop-based congestion controls). drop-based congestion controls).
o A combination of RACK, reconfigured link retransmission and L4S o A combination of RACK, reconfigured link retransmission and L4S
could address transmission errors [UnorderedLTE], could address transmission errors [UnorderedLTE],
[I-D.ietf-tsvwg-ecn-l4s-id]; [I-D.ietf-tsvwg-ecn-l4s-id];
o Hybrid ECN/drop policers (see Section 8.3). o Hybrid ECN/drop rate policers (see Section 8.3).
L4S deployment scenarios that minimize these issues (e.g. over L4S deployment scenarios that minimize these issues (e.g. over
wireline networks) can proceed in parallel to this research, in the wireline networks) can proceed in parallel to this research, in the
expectation that research success could continually widen L4S expectation that research success could continually widen L4S
applicability. applicability.
Classic ECN support is starting to materialize on the Internet as an Classic ECN support is starting to materialize on the Internet as an
increased level of CE marking. Given some of this Classic ECN might increased level of CE marking. Given some of this Classic ECN might
be due to single-queue ECN deployment, an L4S sender will have to be due to single-queue ECN deployment, an L4S sender will have to
fall back to a classic ('Reno-Friendly') behaviour if it detects that fall back to a classic ('Reno-friendly') behaviour if it detects that
ECN marking is accompanied by greater queuing delay or greater delay ECN marking is accompanied by greater queuing delay or greater delay
variation than would be expected with L4S (see Appendix A.1.4 of variation than would be expected with L4S (see Appendix A.1.4 of
[I-D.ietf-tsvwg-ecn-l4s-id]). It is hard to detect whether this is [I-D.ietf-tsvwg-ecn-l4s-id]). It is hard to detect whether this is
all due to the addition of support for ECN in the Linux all due to the addition of support for ECN in the Linux
implementation of FQ-CoDel, which would not require fall-back to implementation of FQ-CoDel, which would not require fall-back to
Classic behaviour, because FQ inherently forces the throughput of Classic behaviour, because FQ inherently forces the throughput of
each flow to be equal irrespective of its aggressiveness. each flow to be equal irrespective of its aggressiveness.
6.3.4. Other Potential Deployment Issues 6.3.4. Other Potential Deployment Issues
skipping to change at page 23, line 44 skipping to change at page 23, line 44
This specification contains no IANA considerations. This specification contains no IANA considerations.
8. Security Considerations 8. Security Considerations
8.1. Traffic (Non-)Policing 8.1. Traffic (Non-)Policing
Because the L4S service can serve all traffic that is using the Because the L4S service can serve all traffic that is using the
capacity of a link, it should not be necessary to police access to capacity of a link, it should not be necessary to police access to
the L4S service. In contrast, Diffserv only works if some packets the L4S service. In contrast, Diffserv only works if some packets
get less favourable treatment than others. So Diffserv has to use get less favourable treatment than others. So Diffserv has to use
traffic policers to limit how much traffic can be favoured. In turn, traffic rate policers to limit how much traffic can be favoured. In
traffic policers require traffic contracts between users and networks turn, traffic policers require traffic contracts between users and
as well as pairwise between networks. Because L4S will lack all this networks as well as pairwise between networks. Because L4S will lack
management complexity, it is more likely to work end-to-end. all this management complexity, it is more likely to work end-to-end.
During early deployment (and perhaps always), some networks will not During early deployment (and perhaps always), some networks will not
offer the L4S service. These networks do not need to police or re- offer the L4S service. These networks do not need to police or re-
mark L4S traffic - they just forward it unchanged as best efforts mark L4S traffic - they just forward it unchanged as best efforts
traffic, as they already forward traffic with ECT(1) today. At a traffic, as they already forward traffic with ECT(1) today. At a
bottleneck, such networks will introduce some queuing and dropping. bottleneck, such networks will introduce some queuing and dropping.
When a scalable congestion control detects a drop it will have to When a scalable congestion control detects a drop it will have to
respond as if it is a Classic congestion control (as required in respond as if it is a Classic congestion control (as required in
Section 2.3 of [I-D.ietf-tsvwg-ecn-l4s-id]). This will ensure safe Section 2.3 of [I-D.ietf-tsvwg-ecn-l4s-id]). This will ensure safe
interworking with other traffic at the 'legacy' bottleneck, but it interworking with other traffic at the 'legacy' bottleneck, but it
skipping to change at page 24, line 31 skipping to change at page 24, line 31
[I-D.ietf-tsvwg-ecn-l4s-id]) is intended to remove any tendency to [I-D.ietf-tsvwg-ecn-l4s-id]) is intended to remove any tendency to
bleach the L4S identifier. Then at least the L4S ECN identifier will bleach the L4S identifier. Then at least the L4S ECN identifier will
be more likely to survive end-to-end even though the service may not be more likely to survive end-to-end even though the service may not
be supported at every hop. Such arrangements would only require be supported at every hop. Such arrangements would only require
simple registered/not-registered packet classification, rather than simple registered/not-registered packet classification, rather than
the managed, application-specific traffic policing against customer- the managed, application-specific traffic policing against customer-
specific traffic contracts that Diffserv uses. specific traffic contracts that Diffserv uses.
8.2. 'Latency Friendliness' 8.2. 'Latency Friendliness'
The L4S service does rely on self-constraint - not in terms of Like the Classic service, the L4S service relies on self-constraint -
limiting rate, but in terms of limiting latency (burstiness). It is limiting rate in response to congestion. In addition, the L4S
hoped that self-interest and standardisation of dynamic behaviour service requires self-constraint in terms of limiting latency
(especially flow start-up) will be sufficient to prevent transports (burstiness). It is hoped that self-interest and standardization of
from sending excessive bursts of L4S traffic, given the application's dynamic behaviour (especially flow start-up) will be sufficient to
own latency will suffer most from such behaviour. prevent transports from sending excessive bursts of L4S traffic,
given the application's own latency will suffer most from such
behaviour.
Whether burst policing becomes necessary remains to be seen. Without Whether burst policing becomes necessary remains to be seen. Without
it, there will be potential for attacks on the low latency of the L4S it, there will be potential for attacks on the low latency of the L4S
service. However it may only be necessary to apply such policing service. However it may only be necessary to apply such policing
reactively, e.g. punitively targeted at any deployments of new bursty reactively, e.g. punitively targeted at any deployments of new bursty
malware. malware.
A per-flow (5-tuple) queue protection function A per-flow (5-tuple) queue protection function
[I-D.briscoe-docsis-q-protection] has been developed for the low [I-D.briscoe-docsis-q-protection] has been developed for the low
latency queue in DOCSIS, which has adopted the DualQ L4S latency queue in DOCSIS, which has adopted the DualQ L4S
skipping to change at page 25, line 38 skipping to change at page 25, line 40
usually also giving a burst allowance (variants exist where the usually also giving a burst allowance (variants exist where the
policer re-marks non-compliant traffic to a discard-eligible Diffserv policer re-marks non-compliant traffic to a discard-eligible Diffserv
codepoint, so they may be dropped elsewhere during contention). codepoint, so they may be dropped elsewhere during contention).
Whenever L4S traffic encounters one of these rate policers, it will Whenever L4S traffic encounters one of these rate policers, it will
experience drops and the source has to fall back to a Classic experience drops and the source has to fall back to a Classic
congestion control, thus losing the benefits of L4S. So, in networks congestion control, thus losing the benefits of L4S. So, in networks
that already use rate policers and plan to deploy L4S, it will be that already use rate policers and plan to deploy L4S, it will be
preferable to redesign these rate policers to be more friendly to the preferable to redesign these rate policers to be more friendly to the
L4S service. L4S service.
This is currently a research area. It might be achieved by setting a L4S-friendly rate policing is currently a research area (note that
threshold where ECN marking is introduced, such that it is just under this is not the same as latency policing). It might be achieved by
the policed rate or just under the burst allowance where drop is setting a threshold where ECN marking is introduced, such that it is
introduced. This could be applied to various types of policer, e.g. just under the policed rate or just under the burst allowance where
[RFC2697], [RFC2698] or the 'local' (non-ConEx) variant of the ConEx drop is introduced. This could be applied to various types of rate
congestion policer [I-D.briscoe-conex-policing]. It might also be policer, e.g. [RFC2697], [RFC2698] or the 'local' (non-ConEx)
possible to design scalable congestion controls to respond less variant of the ConEx congestion policer [I-D.briscoe-conex-policing].
catastrophically to loss that has not been preceded by a period of It might also be possible to design scalable congestion controls to
increasing delay. respond less catastrophically to loss that has not been preceded by a
period of increasing delay.
The design of L4S-friendly rate policers will require a separate The design of L4S-friendly rate policers will require a separate
dedicated document. For further discussion of the interaction dedicated document. For further discussion of the interaction
between L4S and Diffserv, see [I-D.briscoe-tsvwg-l4s-diffserv]. between L4S and Diffserv, see [I-D.briscoe-tsvwg-l4s-diffserv].
8.4. ECN Integrity 8.4. ECN Integrity
Receiving hosts can fool a sender into downloading faster by Receiving hosts can fool a sender into downloading faster by
suppressing feedback of ECN marks (or of losses if retransmissions suppressing feedback of ECN marks (or of losses if retransmissions
are not necessary or available otherwise). Various ways to protect are not necessary or available otherwise). Various ways to protect
skipping to change at page 28, line 12 skipping to change at page 28, line 18
draft-briscoe-tsvwg-l4s-diffserv-02 (work in progress), draft-briscoe-tsvwg-l4s-diffserv-02 (work in progress),
November 2018. November 2018.
[I-D.cardwell-iccrg-bbr-congestion-control] [I-D.cardwell-iccrg-bbr-congestion-control]
Cardwell, N., Cheng, Y., Yeganeh, S., and V. Jacobson, Cardwell, N., Cheng, Y., Yeganeh, S., and V. Jacobson,
"BBR Congestion Control", draft-cardwell-iccrg-bbr- "BBR Congestion Control", draft-cardwell-iccrg-bbr-
congestion-control-00 (work in progress), July 2017. congestion-control-00 (work in progress), July 2017.
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-25 (work and Secure Transport", draft-ietf-quic-transport-27 (work
in progress), January 2020. in progress), February 2020.
[I-D.ietf-tcpm-accurate-ecn] [I-D.ietf-tcpm-accurate-ecn]
Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More
Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate- Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate-
ecn-09 (work in progress), July 2019. ecn-11 (work in progress), March 2020.
[I-D.ietf-tcpm-generalized-ecn] [I-D.ietf-tcpm-generalized-ecn]
Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit
Congestion Notification (ECN) to TCP Control Packets", Congestion Notification (ECN) to TCP Control Packets",
draft-ietf-tcpm-generalized-ecn-05 (work in progress), draft-ietf-tcpm-generalized-ecn-05 (work in progress),
November 2019. November 2019.
[I-D.ietf-tsvwg-aqm-dualq-coupled] [I-D.ietf-tsvwg-aqm-dualq-coupled]
Schepper, K., Briscoe, B., and G. White, "DualQ Coupled Schepper, K., Briscoe, B., and G. White, "DualQ Coupled
AQMs for Low Latency, Low Loss and Scalable Throughput AQMs for Low Latency, Low Loss and Scalable Throughput
skipping to change at page 28, line 42 skipping to change at page 28, line 48
[I-D.ietf-tsvwg-ecn-encap-guidelines] [I-D.ietf-tsvwg-ecn-encap-guidelines]
Briscoe, B., Kaippallimalil, J., and P. Thaler, Briscoe, B., Kaippallimalil, J., and P. Thaler,
"Guidelines for Adding Congestion Notification to "Guidelines for Adding Congestion Notification to
Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn-
encap-guidelines-13 (work in progress), May 2019. encap-guidelines-13 (work in progress), May 2019.
[I-D.ietf-tsvwg-ecn-l4s-id] [I-D.ietf-tsvwg-ecn-l4s-id]
Schepper, K. and B. Briscoe, "Identifying Modified Schepper, K. and B. Briscoe, "Identifying Modified
Explicit Congestion Notification (ECN) Semantics for Explicit Congestion Notification (ECN) Semantics for
Ultra-Low Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s- Ultra-Low Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s-
id-08 (work in progress), November 2019. id-09 (work in progress), February 2020.
[I-D.smith-encrypted-traffic-management] [I-D.smith-encrypted-traffic-management]
Smith, K., "Network management of encrypted traffic", Smith, K., "Network management of encrypted traffic",
draft-smith-encrypted-traffic-management-05 (work in draft-smith-encrypted-traffic-management-05 (work in
progress), May 2016. progress), May 2016.
[I-D.sridharan-tcpm-ctcp] [I-D.sridharan-tcpm-ctcp]
Sridharan, M., Tan, K., Bansal, D., and D. Thaler, Sridharan, M., Tan, K., Bansal, D., and D. Thaler,
"Compound TCP: A New TCP Congestion Control for High-Speed "Compound TCP: A New TCP Congestion Control for High-Speed
and Long Distance Networks", draft-sridharan-tcpm-ctcp-02 and Long Distance Networks", draft-sridharan-tcpm-ctcp-02
skipping to change at page 29, line 29 skipping to change at page 29, line 34
tsvwg-nqb-02 (work in progress), June 2019. tsvwg-nqb-02 (work in progress), June 2019.
[L4Sdemo16] [L4Sdemo16]
Bondarenko, O., De Schepper, K., Tsang, I., and B. Bondarenko, O., De Schepper, K., Tsang, I., and B.
Briscoe, "orderedUltra-Low Delay for All: Live Experience, Briscoe, "orderedUltra-Low Delay for All: Live Experience,
Live Analysis", Proc. MMSYS'16 pp33:1--33:4, May 2016, Live Analysis", Proc. MMSYS'16 pp33:1--33:4, May 2016,
<http://dl.acm.org/citation.cfm?doid=2910017.2910633 <http://dl.acm.org/citation.cfm?doid=2910017.2910633
(videos of demos: (videos of demos:
https://riteproject.eu/dctth/#1511dispatchwg )>. https://riteproject.eu/dctth/#1511dispatchwg )>.
[LinuxPrague]
Briscoe, B., De Schepper, K., Albisser, O., Misund, J.,
Tilmans, O., Kuehlewind, M., and A. Ahmed, "Implementing
the `TCP Prague' Requirements for Low Latency Low Loss
Scalable Throughput (L4S)", Proc. Linux Netdev 0x13 ,
March 2019, <https://www.netdevconf.org/0x13/
session.html?talk-tcp-prague-l4s>.
[Mathis09] [Mathis09]
Mathis, M., "Relentless Congestion Control", PFLDNeT'09 , Mathis, M., "Relentless Congestion Control", PFLDNeT'09 ,
May 2009, <https://www.gdt.id.au/~gdt/ May 2009, <https://www.gdt.id.au/~gdt/
presentations/2010-07-06-questnet-tcp/reference- presentations/2010-07-06-questnet-tcp/reference-
materials/papers/mathis-relentless-congestion- materials/papers/mathis-relentless-congestion-
control.pdf>. control.pdf>.
[NewCC_Proc] [NewCC_Proc]
Eggert, L., "Experimental Specification of New Congestion Eggert, L., "Experimental Specification of New Congestion
Control Algorithms", IETF Operational Note ion-tsv-alt-cc, Control Algorithms", IETF Operational Note ion-tsv-alt-cc,
skipping to change at page 31, line 14 skipping to change at page 31, line 5
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the [RFC4774] Floyd, S., "Specifying Alternate Semantics for the
Explicit Congestion Notification (ECN) Field", BCP 124, Explicit Congestion Notification (ECN) Field", BCP 124,
RFC 4774, DOI 10.17487/RFC4774, November 2006, RFC 4774, DOI 10.17487/RFC4774, November 2006,
<https://www.rfc-editor.org/info/rfc4774>. <https://www.rfc-editor.org/info/rfc4774>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>. <https://www.rfc-editor.org/info/rfc4960>.
[RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion
Control Algorithms", BCP 133, RFC 5033,
DOI 10.17487/RFC5033, August 2007,
<https://www.rfc-editor.org/info/rfc5033>.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, DOI 10.17487/RFC5348, September 2008, RFC 5348, DOI 10.17487/RFC5348, September 2008,
<https://www.rfc-editor.org/info/rfc5348>. <https://www.rfc-editor.org/info/rfc5348>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>. <https://www.rfc-editor.org/info/rfc5681>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
 End of changes. 34 change blocks. 
131 lines changed or deleted 124 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/