< draft-ietf-tsvwg-l4s-arch-20b.txt   draft-ietf-tsvwg-l4s-arch-20c.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: 26 February 2023 Nokia Bell Labs Expires: 28 February 2023 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
25 August 2022 27 August 2022
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-20 draft-ietf-tsvwg-l4s-arch-20
Abstract Abstract
This document describes the L4S architecture, which enables Internet This document describes the L4S architecture, which enables Internet
applications to achieve Low queuing Latency, Low Loss, and Scalable applications to achieve Low queuing Latency, Low Loss, and Scalable
throughput (L4S). L4S is based on the insight that the root cause of throughput (L4S). L4S is based on the insight that the root cause of
queuing delay is in the capacity-seeking congestion controllers of queuing delay is in the capacity-seeking congestion controllers of
senders, not in the queue itself. With the L4S architecture all senders, not in the queue itself. With the L4S architecture all
Internet applications could (but do not have to) transition away from Internet applications could (but do not have to) transition away from
congestion control algorithms that cause substantial queuing delay, congestion control algorithms that cause substantial queuing delay,
to a new class of congestion controls that can seek capacity with to a new class of congestion controls that can seek capacity with
very little queuing. These are aided by a modified form of explicit very little queuing. These are aided by a modified form of explicit
congestion notification from the network, which is defined separately congestion notification (ECN) from the network. With this new
as an experimental change to ECN. With this new architecture architecture, applications can have both low latency and high
applications can have both low latency and high throughput. throughput.
The architecture primarily concerns incremental deployment. It The architecture primarily concerns incremental deployment. It
defines mechanisms that allow the new class of L4S congestion defines mechanisms that allow the new class of L4S congestion
controls to coexist with 'Classic' congestion controls in a shared controls to coexist with 'Classic' congestion controls in a shared
network. The aim is for L4S latency and throughput to be usually network. The aim is for L4S latency and throughput to be usually
much better (and rarely worse), while typically not impacting Classic much better (and rarely worse), while typically not impacting Classic
performance. performance.
Status of This Memo Status of This Memo
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 26 February 2023. This Internet-Draft will expire on 28 February 2023.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 43 skipping to change at page 2, line 43
4.1. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 9 4.1. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 9
4.2. Network Components . . . . . . . . . . . . . . . . . . . 10 4.2. Network Components . . . . . . . . . . . . . . . . . . . 10
4.3. Host Mechanisms . . . . . . . . . . . . . . . . . . . . . 13 4.3. Host Mechanisms . . . . . . . . . . . . . . . . . . . . . 13
5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Why These Primary Components? . . . . . . . . . . . . . . 15 5.1. Why These Primary Components? . . . . . . . . . . . . . . 15
5.2. What L4S adds to Existing Approaches . . . . . . . . . . 18 5.2. What L4S adds to Existing Approaches . . . . . . . . . . 18
6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 21 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. Applications . . . . . . . . . . . . . . . . . . . . . . 21 6.1. Applications . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 22 6.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 22
6.3. Applicability with Specific Link Technologies . . . . . . 24 6.3. Applicability with Specific Link Technologies . . . . . . 24
6.4. Deployment Considerations . . . . . . . . . . . . . . . . 24 6.4. Deployment Considerations . . . . . . . . . . . . . . . . 25
6.4.1. Deployment Topology . . . . . . . . . . . . . . . . . 25 6.4.1. Deployment Topology . . . . . . . . . . . . . . . . . 25
6.4.2. Deployment Sequences . . . . . . . . . . . . . . . . 26 6.4.2. Deployment Sequences . . . . . . . . . . . . . . . . 26
6.4.3. L4S Flow but Non-ECN Bottleneck . . . . . . . . . . . 29 6.4.3. L4S Flow but Non-ECN Bottleneck . . . . . . . . . . . 29
6.4.4. L4S Flow but Classic ECN Bottleneck . . . . . . . . . 30 6.4.4. L4S Flow but Classic ECN Bottleneck . . . . . . . . . 30
6.4.5. L4S AQM Deployment within Tunnels . . . . . . . . . . 30 6.4.5. L4S AQM Deployment within Tunnels . . . . . . . . . . 30
7. IANA Considerations (to be removed by RFC Editor) . . . . . . 30 7. IANA Considerations (to be removed by RFC Editor) . . . . . . 30
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8.1. Traffic Rate (Non-)Policing . . . . . . . . . . . . . . . 30 8.1. Traffic Rate (Non-)Policing . . . . . . . . . . . . . . . 31
8.1.1. (Non-)Policing Rate per Flow . . . . . . . . . . . . 30 8.1.1. (Non-)Policing Rate per Flow . . . . . . . . . . . . 31
8.1.2. (Non-)Policing Rate per Class . . . . . . . . . . . . 31 8.1.2. (Non-)Policing L4S Service Rate . . . . . . . . . . . 31
8.2. 'Latency Friendliness' . . . . . . . . . . . . . . . . . 32 8.2. 'Latency Friendliness' . . . . . . . . . . . . . . . . . 32
8.3. Interaction between Rate Policing and L4S . . . . . . . . 34 8.3. Interaction between Rate Policing and L4S . . . . . . . . 34
8.4. ECN Integrity . . . . . . . . . . . . . . . . . . . . . . 35 8.4. ECN Integrity . . . . . . . . . . . . . . . . . . . . . . 35
8.5. Privacy Considerations . . . . . . . . . . . . . . . . . 35 8.5. Privacy Considerations . . . . . . . . . . . . . . . . . 35
9. Informative References . . . . . . . . . . . . . . . . . . . 36 9. Informative References . . . . . . . . . . . . . . . . . . . 36
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 45 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
skipping to change at page 4, line 22 skipping to change at page 4, line 22
is itself a large capacity-seeking or adaptive rate (e.g. interactive is itself a large capacity-seeking or adaptive rate (e.g. interactive
video) flow. At these times, the performance improvement from L4S video) flow. At these times, the performance improvement from L4S
must be sufficient that network operators will be motivated to deploy must be sufficient that network operators will be motivated to deploy
it. 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 congestion
control (Reno [RFC5681]) or compatible variants (e.g. TCP control (Reno [RFC5681]) or compatible variants
Cubic [RFC8312]). We shall use the term 'Classic' for these Reno- (e.g. CUBIC [RFC8312]) that are used in TCP and in other transports
friendly congestion controls. Classic congestion controls induce such as QUIC [RFC9000]. We shall use the term 'Classic' for these
relatively large saw-tooth-shaped excursions up the queue and down Reno-friendly congestion controls. Classic congestion controls
again, which have been growing as flow rate scales [RFC3649]. So if induce relatively large saw-tooth-shaped excursions up the queue and
a network operator naively attempts to reduce queuing delay by down again, which have been growing as flow rate scales [RFC3649].
So if a network operator naively attempts to reduce queuing delay by
configuring an AQM to operate at a shallower queue, a Classic configuring an AQM to operate at a shallower queue, a Classic
congestion control will significantly underutilize the link at the congestion control will significantly underutilize the link at the
bottom of every saw-tooth. bottom of every saw-tooth.
It has been demonstrated that if the sending host replaces a Classic It has been demonstrated that if the sending host replaces a Classic
congestion control with a 'Scalable' alternative, when a suitable AQM congestion control with a 'Scalable' alternative, when a suitable AQM
is deployed in the network the performance under load of all the is deployed in the network the performance under load of all the
above interactive applications can be significantly improved. For above interactive applications can be significantly improved. For
instance, queuing delay under heavy load with the example DCTCP/DualQ instance, queuing delay under heavy load with the example DCTCP/DualQ
solution cited below on a DSL or Ethernet link is roughly 1 to 2 solution cited below on a DSL or Ethernet link is roughly 1 to 2
skipping to change at page 5, line 11 skipping to change at page 5, line 12
start using it as soon as the sender's stack is updated. Access start using it as soon as the sender's stack is updated. Access
networks are typically designed with one link as the bottleneck for networks are typically designed with one link as the bottleneck for
each site (which might be a home, small enterprise or mobile device), each site (which might be a home, small enterprise or mobile device),
so deployment at either or both ends of this link should give nearly so deployment at either or both ends of this link should give nearly
all the benefit in the respective direction. With some transport all the benefit in the respective direction. With some transport
protocols, namely TCP and SCTP, the sender has to check that the protocols, namely TCP and SCTP, the sender has to check that the
receiver has been suitably updated to give more accurate feedback, receiver has been suitably updated to give more accurate feedback,
whereas with more recent transport protocols such as QUIC and DCCP, whereas with more recent transport protocols such as QUIC and DCCP,
all receivers have always been suitable. all receivers have always been suitable.
This document presents the L4S architecture, by describing and This document presents the L4S architecture. It consists of three
justifying the component parts and how they interact to provide the components: network support to isolate L4S traffic from classic
scalable, low latency, low loss Internet service. It also details traffic; protocol features that allow network elements to identify
the approach to incremental deployment, as briefly summarized above. L4S traffic; and host support for L4S congestion controls. The
protocol is defined separately [I-D.ietf-tsvwg-ecn-l4s-id] as an
experimental change to Explicit Congestion Notification (ECN). This
document describes and justifies the component parts and how they
interact to provide the scalable, low latency, low loss Internet
service. It also details the approach to incremental deployment, as
briefly summarized above.
1.1. Document Roadmap 1.1. Document Roadmap
This document describes the L4S architecture in three passes. First This document describes the L4S architecture in three passes. First
this brief overview gives the very high level idea and states the this brief overview gives the very high level idea and states the
main components with minimal rationale. This is only intended to main components with minimal rationale. This is only intended to
give some context for the terminology definitions that follow in give some context for the terminology definitions that follow in
Section 3, and to explain the structure of the rest of the document. Section 3, and to explain the structure of the rest of the document.
Then Section 4 goes into more detail on each component with some Then Section 4 goes into more detail on each component with some
rationale, but still mostly stating what the architecture is, rather rationale, but still mostly stating what the architecture is, rather
skipping to change at page 7, line 21 skipping to change at page 7, line 29
(FQ) and DualQ variants of L4S work, and (FQ) and DualQ variants of L4S 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
DualQ Coupled AQM framework. A specific marking algorithm is not DualQ Coupled AQM framework. A specific marking algorithm is not
mandated for L4S AQMs. Appendices of mandated for L4S AQMs. Appendices of
[I-D.ietf-tsvwg-aqm-dualq-coupled] give non-normative examples [I-D.ietf-tsvwg-aqm-dualq-coupled] give non-normative examples
that have been implemented and evaluated, and give recommended that have been implemented and evaluated, and give recommended
default parameter settings. It is expected that L4S experiments default parameter settings. It is expected that L4S experiments
will improve knowledge of parameter settings and whether the set will improve knowledge of parameter settings and whether the set
of marking algorithms needs to be limited. of marking algorithms needs to be limited.
3) Protocol: A host needs to distinguish L4S and Classic packets 3) Protocol: A sending host needs to distinguish L4S and Classic
with an identifier so that the network can classify them into packets with an identifier so that the network can classify them
their separate treatments. The L4S identifier into their separate treatments. The L4S identifier
spec. [I-D.ietf-tsvwg-ecn-l4s-id] concludes that all alternatives spec. [I-D.ietf-tsvwg-ecn-l4s-id] concludes that all alternatives
involve compromises, but the ECT(1) and CE codepoints of the ECN involve compromises, but the ECT(1) and CE codepoints of the ECN
field represent a workable solution. As already explained, the field represent a workable solution. As already explained, the
network also uses ECN to immediately signal the very start of network also uses ECN to immediately signal the very start of
queue growth to the transport. queue growth to the transport.
3. Terminology 3. Terminology
Note: The following definitions are copied from the L4S ECN Note: The following definitions are copied from the L4S ECN
spec [I-D.ietf-tsvwg-ecn-l4s-id] for convenience. If there are spec [I-D.ietf-tsvwg-ecn-l4s-id] for convenience. If there are
skipping to change at page 9, line 37 skipping to change at page 9, line 37
latency policing, burst policing or queue protection in this latency policing, burst policing or queue protection in this
document. Otherwise the term rate policing is used. document. Otherwise the term rate policing is used.
4. L4S Architecture Components 4. L4S Architecture Components
The L4S architecture is composed of the elements in the following The L4S architecture is composed of the elements in the following
three subsections. three subsections.
4.1. Protocol Mechanisms 4.1. Protocol Mechanisms
The L4S architecture involves: a) unassignment of an identifier; b) The L4S architecture involves: a) unassignment of the previous use of
reassignment of the same identifier; and c) optional further the identifier; b) reassignment of the same identifier; and c)
identifiers: 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. 'Classic' ECN [RFC3168] requires of explicit congestion signals. 'Classic' ECN [RFC3168] requires
an ECN signal to be treated as equivalent to drop, both when it an ECN signal to be treated as equivalent to drop, both when it
is generated in the network and when it is responded to by hosts. is generated in the network and when it is responded to by hosts.
L4S needs networks and hosts to support a more fine-grained L4S needs networks and hosts to support a more fine-grained
meaning for each ECN signal that is less severe than a drop, so meaning for each ECN signal that is less severe than a drop, so
that the L4S signals: that the L4S signals:
* can be much more frequent; * can be much more frequent;
* can be signalled immediately, without the significant delay * can be signalled immediately, without the significant delay
required to smooth out fluctuations in the queue. required to smooth out fluctuations in the queue.
To enable L4S, the standards track Classic ECN spec. [RFC3168] To enable L4S, the standards track Classic ECN spec. [RFC3168]
has had to be updated to allow L4S packets to depart from the has had to be updated to allow L4S packets to depart from the
'equivalent to drop' constraint. [RFC8311] is a standards track 'equivalent to drop' constraint. [RFC8311] is a standards track
update to relax specific requirements in RFC 3168 (and certain update to relax specific requirements in RFC 3168 (and certain
other standards track RFCs), which clears the way for the other standards track RFCs), which clears the way for the
experimental changes proposed for L4S. [RFC8311] also experimental changes proposed for L4S. Also, the ECT(1)
reclassifies the original experimental assignment of the ECT(1) codepoint was previously assigned as the experimental ECN
codepoint as an ECN nonce [RFC3540] as historic. nonce [RFC3540], which RFC 8311 recategorizes as historic to make
the codepoint available again.
b. [I-D.ietf-tsvwg-ecn-l4s-id] specifies that ECT(1) is used as the b. [I-D.ietf-tsvwg-ecn-l4s-id] specifies that ECT(1) is used as the
identifier to classify L4S packets into a separate treatment from identifier to classify L4S packets into a separate treatment from
Classic packets. This satisfies the requirement for identifying Classic packets. This satisfies the requirement for identifying
an alternative ECN treatment in [RFC4774]. an alternative ECN treatment in [RFC4774].
The CE codepoint is used to indicate Congestion Experienced by The CE codepoint is used to indicate Congestion Experienced by
both L4S and Classic treatments. This raises the concern that a both L4S and Classic treatments. This raises the concern that a
Classic AQM earlier on the path might have marked some ECT(0) Classic AQM earlier on the path might have marked some ECT(0)
packets as CE. Then these packets will be erroneously classified packets as CE. Then these packets will be erroneously classified
skipping to change at page 14, line 43 skipping to change at page 14, line 43
the process of being updated: the process of being updated:
* For the case of TCP, the feedback protocol for ECN embeds the * For the case of TCP, the feedback protocol for ECN embeds the
assumption from Classic ECN [RFC3168] that an ECN mark is assumption from Classic ECN [RFC3168] that an ECN mark is
equivalent to a drop, making it unusable for a scalable TCP. equivalent to a drop, making it unusable for a scalable TCP.
Therefore, the implementation of TCP receivers will have to be Therefore, the implementation of TCP receivers will have to be
upgraded [RFC7560]. Work to standardize and implement more upgraded [RFC7560]. Work to standardize and implement more
accurate ECN feedback for TCP (AccECN) is in accurate ECN feedback for TCP (AccECN) is in
progress [I-D.ietf-tcpm-accurate-ecn], [PragueLinux]. progress [I-D.ietf-tcpm-accurate-ecn], [PragueLinux].
* ECN feedback is only roughly sketched in an appendix of the * ECN feedback was only roughly sketched in an appendix of the
SCTP specification [RFC4960]. A fuller specification has been now obsoleted second specification of SCTP [RFC4960], while a
proposed in a long-expired draft [I-D.stewart-tsvwg-sctpecn], fuller specification was proposed in a long-expired
which would need to be implemented and deployed before SCTP draft [I-D.stewart-tsvwg-sctpecn]. A new design would need to
could support L4S. be implemented and deployed before SCTP could support L4S.
* For RTP, sufficient ECN feedback was defined in [RFC6679], but * For RTP, sufficient ECN feedback was defined in [RFC6679], but
[RFC8888] defines the latest standards track improvements. [RFC8888] defines the latest standards track improvements.
5. Rationale 5. Rationale
5.1. Why These Primary Components? 5.1. Why These Primary Components?
Explicit congestion signalling (protocol): Explicit congestion Explicit congestion signalling (protocol): Explicit congestion
signalling is a key part of the L4S approach. In contrast, use of signalling is a key part of the L4S approach. In contrast, use of
skipping to change at page 20, line 33 skipping to change at page 20, line 33
control. Then, flow rate policing can be added separately if control. Then, flow rate policing can be added separately if
desired. This allows application control up to a point, but desired. This allows application control up to a point, but
the network can still choose to set the point at which it the network can still choose to set the point at which it
intervenes to prevent one flow completely starving another. intervenes to prevent one flow completely starving another.
Note: Note:
1. It might seem that self-inflicted queuing delay within a per- 1. It might seem that self-inflicted queuing delay within a per-
flow queue should not be counted, because if the delay wasn't flow queue should not be counted, because if the delay wasn't
in the network it would just shift to the sender. However, in the network it would just shift to the sender. However,
modern adaptive applications, e.g. HTTP/2 [RFC7540] or some modern adaptive applications, e.g. HTTP/2 [RFC9113] or some
interactive media applications (see Section 6.1), can keep low interactive media applications (see Section 6.1), can keep low
latency objects at the front of their local send queue by latency objects at the front of their local send queue by
shuffling priorities of other objects dependent on the shuffling priorities of other objects dependent on the
progress of other transfers (for example see [lowat]). They progress of other transfers (for example see [lowat]). They
cannot shuffle objects once they have released them into the cannot shuffle objects once they have released them into the
network. network.
Alternative Back-off ECN (ABE): Here again, L4S is not an Alternative Back-off ECN (ABE): Here again, L4S is not an
alternative to ABE but a complement that introduces much lower alternative to ABE but a complement that introduces much lower
queuing delay. ABE [RFC8511] alters the host behaviour in queuing delay. ABE [RFC8511] alters the host behaviour in
skipping to change at page 24, line 38 skipping to change at page 24, line 38
buffering. However, by removing 'the longest pole in the tent' buffering. However, by removing 'the longest pole in the tent'
(buffering for the large sawteeth of Classic congestion controls), (buffering for the large sawteeth of Classic congestion controls),
L4S exposes all these 'shorter poles' to greater scrutiny. L4S exposes all these 'shorter poles' to greater scrutiny.
Until now, the buffering needed for these additional reasons tended Until now, the buffering needed for these additional reasons tended
to be over-specified - with the excuse that none were 'the longest to be over-specified - with the excuse that none were 'the longest
pole in the tent'. But having removed the 'longest pole', it becomes pole in the tent'. But having removed the 'longest pole', it becomes
worthwhile to minimize them, for instance reducing packet aggregation worthwhile to minimize them, for instance reducing packet aggregation
burst sizes and MAC scheduling intervals. burst sizes and MAC scheduling intervals.
Also certain link types, particularly radio-based links, are far more
prone to transmission losses. Section 6.4.3 explains how an L4S
response to loss has to be as drastic as a Classic response.
Nonetheless, research referred to in the same section has
demonstrated potential for considerably more effective loss repair at
the link layer, due to the relaxed ordering constraints of L4S
packets.
6.4. Deployment Considerations 6.4. Deployment Considerations
L4S AQMs, whether DualQ [I-D.ietf-tsvwg-aqm-dualq-coupled] or FQ, L4S AQMs, whether DualQ [I-D.ietf-tsvwg-aqm-dualq-coupled] or FQ,
e.g. [RFC8290] are, in themselves, an incremental deployment e.g. [RFC8290] are, in themselves, an incremental deployment
mechanism for L4S - so that L4S traffic can coexist with existing mechanism for L4S - so that L4S traffic can coexist with existing
Classic (Reno-friendly) traffic. Section 6.4.1 explains why only Classic (Reno-friendly) traffic. Section 6.4.1 explains why only
deploying an L4S AQM in one node at each end of the access link will deploying an L4S AQM in one node at each end of the access link will
realize nearly all the benefit of L4S. realize nearly all the benefit of L4S.
L4S involves both end systems and the network, so Section 6.4.2 L4S involves both end systems and the network, so Section 6.4.2
skipping to change at page 31, line 5 skipping to change at page 31, line 21
In the current Internet, ISPs usually enforce separation between the In the current Internet, ISPs usually enforce separation between the
capacity of shared links assigned to different 'sites' capacity of shared links assigned to different 'sites'
(e.g. households, businesses or mobile users - see terminology in (e.g. households, businesses or mobile users - see terminology in
Section 3) using some form of scheduler [RFC0970]. And they use Section 3) using some form of scheduler [RFC0970]. And they use
various techniques like redirection to traffic scrubbing facilities various techniques like redirection to traffic scrubbing facilities
to deal with flooding attacks. However, there has never been a to deal with flooding attacks. However, there has never been a
universal need to police the rate of individual application flows - universal need to police the rate of individual application flows -
the Internet has generally always relied on self-restraint of the Internet has generally always relied on self-restraint of
congestion controls at senders for sharing intra-'site' capacity. congestion controls at senders for sharing intra-'site' capacity.
L4S has been designed not to upset this situation. If a DualQ is L4S has been designed not to upset this status quo. If a DualQ is
used to provide L4S service, section 4.2 of used to provide L4S service, section 4.2 of
[I-D.ietf-tsvwg-aqm-dualq-coupled] explains how it is designed to [I-D.ietf-tsvwg-aqm-dualq-coupled] explains how it is designed to
give no more rate advantage to unresponsive flows than a single-queue give no more rate advantage to unresponsive flows than a single-queue
AQM would, whether or not there is traffic overload. AQM would, whether or not there is traffic overload.
Also, in case per-flow rate policing is ever required, it can be Also, in case per-flow rate policing is ever required, it can be
added because it is orthogonal to the distinction between L4S and added because it is orthogonal to the distinction between L4S and
Classic. As explained in Section 5.2, the DualQ variant of L4S Classic. As explained in Section 5.2, the DualQ variant of L4S
provides low delay without prejudging the issue of flow-rate control. provides low delay without prejudging the issue of flow-rate control.
So, if flow-rate control is needed, per-flow-queuing (FQ) with L4S So, if flow-rate control is needed, per-flow-queuing (FQ) with L4S
support can be used instead, or flow rate policing can be added as a support can be used instead, or flow rate policing can be added as a
modular addition to a DualQ. However, an active attacker will just modular addition to a DualQ. However, per-flow rate control is not
shard its traffic over more flow IDs if the rate of each is usually deployed as a security mechanism, because an active attacker
restricted, which is why per-flow rate control is typically intended can just shard its traffic over more flow IDs if the rate of each is
for latency isolation rather than rate control _per se_. restricted.
8.1.2. (Non-)Policing Rate per Class 8.1.2. (Non-)Policing L4S Service Rate
Section 5.2 explains how Diffserv only makes a difference if some Section 5.2 explains how Diffserv only makes a difference if some
packets get less favourable treatment than others, which typically packets get less favourable treatment than others, which typically
requires traffic rate policing, which can, in turn, lead to further requires traffic rate policing for a low latency class. In contrast,
management complexity such as traffic contracts at trust boundaries. it should not be necessary to rate-police access to the L4S service
In contrast, it should not be necessary to rate-police access to the to protect the Classic service, because L4S is designed to reduce
L4S service, because L4S is designed to reduce delay without harming delay without harming the delay or rate of any Classic traffic.
the delay or rate of any Classic traffic. As an aside, because L4S
avoids 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. In general, these networks should not need to offer the L4S service. In general, these networks should not need to
police L4S traffic. They are required (by both the ECN police L4S traffic. They are required (by both the ECN
spec [RFC3168] and the L4S ECN spec [I-D.ietf-tsvwg-ecn-l4s-id]) not spec [RFC3168] and the L4S ECN spec [I-D.ietf-tsvwg-ecn-l4s-id]) not
to change the L4S identifier, which would interfere with end-to-end to change the L4S identifier, which would interfere with end-to-end
congestion control. If they already treat ECN traffic as Not-ECT, congestion control. If they already treat ECN traffic as Not-ECT,
they can merely treat L4S traffic as Not-ECT too. At a bottleneck, they can merely treat L4S traffic as Not-ECT too. At a bottleneck,
such networks will introduce some queuing and dropping. When a such networks will introduce some queuing and dropping. When a
scalable congestion control detects a drop it will have to respond scalable congestion control detects a drop it will have to respond
skipping to change at page 32, line 10 skipping to change at page 32, line 24
In cases that are expected to be rare, networks that solely support In cases that are expected to be rare, networks that solely support
Classic ECN [RFC3168] in a single queue bottleneck might opt to Classic ECN [RFC3168] in a single queue bottleneck might opt to
police L4S traffic so as to protect competing Classic ECN traffic police L4S traffic so as to protect competing Classic ECN traffic
(for instance, see Section 6.1.3 of the L4S operational (for instance, see Section 6.1.3 of the L4S operational
guidance [I-D.ietf-tsvwg-l4sops]). However, Section 4.3 of the L4S guidance [I-D.ietf-tsvwg-l4sops]). However, Section 4.3 of the L4S
ECN spec [I-D.ietf-tsvwg-ecn-l4s-id] recommends that the sender ECN spec [I-D.ietf-tsvwg-ecn-l4s-id] recommends that the sender
adapts its congestion response to properly coexist with Classic ECN adapts its congestion response to properly coexist with Classic ECN
flows, i.e. reverting to the self-restraint approach. flows, i.e. reverting to the self-restraint approach.
Certain network operators might choose to restrict access to the L4S Certain network operators might choose to restrict access to the L4S
class, perhaps only to selected premium customers as a value-added service, perhaps only to selected premium customers as a value-added
service. Their packet classifier (item 2 in Figure 1) could identify service. Their packet classifier (item 2 in Figure 1) could identify
such customers against some other field (e.g. source address range) such customers against some other field (e.g. source address range)
as well as classifying on the ECN field. If only the ECN L4S as well as classifying on the ECN field. If only the ECN L4S
identifier matched, but not the source address (say), the classifier identifier matched, but not the source address (say), the classifier
could direct these packets (from non-premium customers) into the could direct these packets (from non-premium customers) into the
Classic queue. Explaining clearly how operators can use an Classic queue. Explaining clearly how operators can use an
additional local classifiers (see section 5.4 of the L4S ECN additional local classifiers (see section 5.4 of the L4S ECN
spec [I-D.ietf-tsvwg-ecn-l4s-id]) is intended to remove any spec [I-D.ietf-tsvwg-ecn-l4s-id]) is intended to remove any
motivation to clear the L4S identifier. Then at least the L4S ECN motivation to clear the L4S identifier. Then at least the L4S ECN
identifier will be more likely to survive end-to-end even though the identifier will be more likely to survive end-to-end even though the
skipping to change at page 34, line 25 skipping to change at page 34, line 38
8.3. Interaction between Rate Policing and L4S 8.3. Interaction between Rate Policing and L4S
As mentioned in Section 5.2, L4S should remove the need for low As mentioned in Section 5.2, L4S should remove the need for low
latency Diffserv classes. However, those Diffserv classes that give latency Diffserv classes. However, those Diffserv classes that give
certain applications or users priority over capacity, would still be certain applications or users priority over capacity, would still be
applicable in certain scenarios (e.g. corporate networks). Then, applicable in certain scenarios (e.g. corporate networks). Then,
within such Diffserv classes, L4S would often be applicable to give within such Diffserv classes, L4S would often be applicable to give
traffic low latency and low loss as well. Within such a Diffserv traffic low latency and low loss as well. Within such a Diffserv
class, the bandwidth available to a user or application is often class, the bandwidth available to a user or application is often
limited by a rate policer. Similarly, in the default Diffserv class, limited by a rate policer. Similarly, in the default Diffserv class,
rate policers are sometimes used to partition shared capacity (e.g. rate policers are sometimes used to partition shared capacity.
for some passive optical networks).
A classic rate policer drops any packets exceeding a set rate, A classic rate policer drops any packets exceeding a set rate,
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 can be dropped elsewhere during contention). codepoint, so they can 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 will have to fall back to a Classic experience drops and the source will have to fall back to a Classic
congestion control, thus losing the benefits of L4S (Section 6.4.3). congestion control, thus losing the benefits of L4S (Section 6.4.3).
So, in networks that already use rate policers and plan to deploy So, in networks that already use rate policers and plan to deploy
L4S, it will be preferable to redesign these rate policers to be more L4S, it will be preferable to redesign these rate policers to be more
skipping to change at page 35, line 11 skipping to change at page 35, line 25
possible to design scalable congestion controls to respond less possible to design scalable congestion controls to respond less
catastrophically to loss that has not been preceded by a period of catastrophically to loss that has not been preceded by a period of
increasing delay. 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 Various ways have been developed to protect the integrity of the
suppressing feedback of ECN marks (or of losses if retransmissions congestion feedback loop (whether signalled by loss, Classic ECN or
are not necessary or available otherwise). Various ways to protect L4S ECN) against misbehaviour by the receiver, sender or network (or
transport feedback integrity have been developed. For instance: all three). Brief details of each including applicability, pros and
cons is given in Appendix C.1 of the L4S ECN
* The sender can test the integrity of the receiver's feedback by spec [I-D.ietf-tsvwg-ecn-l4s-id].
occasionally setting the IP-ECN field to the congestion
experienced (CE) codepoint, which is normally only set by a
congested link. Then the sender can test whether the receiver's
feedback faithfully reports what it expects (see 2nd para of
Section 20.2 of the Classic ECN spec [RFC3168]).
* A network can enforce a congestion response to its ECN markings
(or packet losses) by auditing congestion exposure
(ConEx) [RFC7713].
* Transport layer authentication such as the TCP authentication
option (TCP-AO [RFC5925]) or QUIC's use of TLS [RFC9001] can
detect any tampering with congestion feedback.
* The ECN Nonce [RFC3540] was proposed to detect tampering with
congestion feedback, but it has been reclassified as
historic [RFC8311].
Appendix C.1 of the L4S ECN spec [I-D.ietf-tsvwg-ecn-l4s-id] gives
more details of these techniques including their applicability and
pros and cons.
8.5. Privacy Considerations 8.5. Privacy Considerations
As discussed in Section 5.2, the L4S architecture does not preclude As discussed in Section 5.2, the L4S architecture does not preclude
approaches that inspect end-to-end transport layer identifiers. For approaches that inspect end-to-end transport layer identifiers. For
instance, L4S support has been added to FQ-CoDel, which classifies by instance, L4S support has been added to FQ-CoDel, which classifies by
application flow ID in the network. However, the main innovation of application flow ID in the network. However, the main innovation of
L4S is the DualQ AQM framework that does not need to inspect any L4S is the DualQ AQM framework that does not need to inspect any
deeper than the outermost IP header, because the L4S identifier is in deeper than the outermost IP header, because the L4S identifier is in
the IP-ECN field. the IP-ECN field.
skipping to change at page 38, line 9 skipping to change at page 37, line 46
Briscoe, B., "Network Performance Isolation using Briscoe, B., "Network Performance Isolation using
Congestion Policing", Work in Progress, Internet-Draft, Congestion Policing", Work in Progress, Internet-Draft,
draft-briscoe-conex-policing-01, 14 February 2014, draft-briscoe-conex-policing-01, 14 February 2014,
<https://www.ietf.org/archive/id/draft-briscoe-conex- <https://www.ietf.org/archive/id/draft-briscoe-conex-
policing-01.txt>. policing-01.txt>.
[I-D.briscoe-docsis-q-protection] [I-D.briscoe-docsis-q-protection]
Briscoe, B. and G. White, "The DOCSIS(r) Queue Protection Briscoe, B. and G. White, "The DOCSIS(r) Queue Protection
Algorithm to Preserve Low Latency", Work in Progress, Algorithm to Preserve Low Latency", Work in Progress,
Internet-Draft, draft-briscoe-docsis-q-protection-06, 13 Internet-Draft, draft-briscoe-docsis-q-protection-06, 13
May 2022, <https://www.ietf.org/archive/id/draft-briscoe- May 2022,
docsis-q-protection-06.txt>. <https://datatracker.ietf.org/api/v1/doc/document/draft-
briscoe-docsis-q-protection/>.
[I-D.briscoe-iccrg-prague-congestion-control] [I-D.briscoe-iccrg-prague-congestion-control]
Schepper, K. D., Tilmans, O., and B. Briscoe, "Prague Schepper, K. D., Tilmans, O., and B. Briscoe, "Prague
Congestion Control", Work in Progress, Internet-Draft, Congestion Control", Work in Progress, Internet-Draft,
draft-briscoe-iccrg-prague-congestion-control-01, 11 July draft-briscoe-iccrg-prague-congestion-control-01, 11 July
2022, <https://www.ietf.org/archive/id/draft-briscoe- 2022, <https://datatracker.ietf.org/api/v1/doc/document/
iccrg-prague-congestion-control-01.txt>. draft-briscoe-iccrg-prague-congestion-control/>.
[I-D.briscoe-tsvwg-l4s-diffserv] [I-D.briscoe-tsvwg-l4s-diffserv]
Briscoe, B., "Interactions between Low Latency, Low Loss, Briscoe, B., "Interactions between Low Latency, Low Loss,
Scalable Throughput (L4S) and Differentiated Services", Scalable Throughput (L4S) and Differentiated Services",
Work in Progress, Internet-Draft, draft-briscoe-tsvwg-l4s- Work in Progress, Internet-Draft, draft-briscoe-tsvwg-l4s-
diffserv-02, 4 November 2018, diffserv-02, 2 July 2018,
<https://www.ietf.org/archive/id/draft-briscoe-tsvwg-l4s- <https://datatracker.ietf.org/api/v1/doc/document/draft-
diffserv-02.txt>. briscoe-tsvwg-l4s-diffserv/>.
[I-D.cardwell-iccrg-bbr-congestion-control] [I-D.cardwell-iccrg-bbr-congestion-control]
Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V. Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V.
Jacobson, "BBR Congestion Control", Work in Progress, Jacobson, "BBR Congestion Control", Work in Progress,
Internet-Draft, draft-cardwell-iccrg-bbr-congestion- Internet-Draft, draft-cardwell-iccrg-bbr-congestion-
control-02, 7 March 2022, control-02, 7 March 2022,
<https://www.ietf.org/archive/id/draft-cardwell-iccrg-bbr- <https://datatracker.ietf.org/api/v1/doc/document/draft-
congestion-control-02.txt>. cardwell-iccrg-bbr-congestion-control/>.
[I-D.ietf-tcpm-accurate-ecn] [I-D.ietf-tcpm-accurate-ecn]
Briscoe, B., Kühlewind, M., and R. Scheffenegger, "More Briscoe, B., Kühlewind, M., and R. Scheffenegger, "More
Accurate ECN Feedback in TCP", Work in Progress, Internet- Accurate ECN Feedback in TCP", Work in Progress, Internet-
Draft, draft-ietf-tcpm-accurate-ecn-20, 25 July 2022, Draft, draft-ietf-tcpm-accurate-ecn-20, 25 July 2022,
<https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate- <https://datatracker.ietf.org/api/v1/doc/document/draft-
ecn-20.txt>. ietf-tcpm-accurate-ecn/>.
[I-D.ietf-tsvwg-aqm-dualq-coupled] [I-D.ietf-tsvwg-aqm-dualq-coupled]
Schepper, K. D., Briscoe, B., and G. White, "DualQ Coupled Schepper, K. D., 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
(L4S)", Work in Progress, Internet-Draft, draft-ietf- (L4S)", Work in Progress, Internet-Draft, draft-ietf-
tsvwg-aqm-dualq-coupled-24, 7 July 2022, tsvwg-aqm-dualq-coupled-24, 7 July 2022,
<https://www.ietf.org/archive/id/draft-ietf-tsvwg-aqm- <https://datatracker.ietf.org/api/v1/doc/document/draft-
dualq-coupled-24.txt>. ietf-tsvwg-aqm-dualq-coupled/>.
[I-D.ietf-tsvwg-ecn-encap-guidelines] [I-D.ietf-tsvwg-ecn-encap-guidelines]
Briscoe, B. and J. Kaippallimalil, "Guidelines for Adding Briscoe, B. and J. Kaippallimalil, "Guidelines for Adding
Congestion Notification to Protocols that Encapsulate IP", Congestion Notification to Protocols that Encapsulate IP",
Work in Progress, Internet-Draft, draft-ietf-tsvwg-ecn- Work in Progress, Internet-Draft, draft-ietf-tsvwg-ecn-
encap-guidelines-17, 11 July 2022, encap-guidelines-17, 11 July 2022,
<https://www.ietf.org/archive/id/draft-ietf-tsvwg-ecn- <https://datatracker.ietf.org/api/v1/doc/document/draft-
encap-guidelines-17.txt>. ietf-tsvwg-ecn-encap-guidelines/>.
[I-D.ietf-tsvwg-ecn-l4s-id] [I-D.ietf-tsvwg-ecn-l4s-id]
Schepper, K. D. and B. Briscoe, "Explicit Congestion Schepper, K. D. and B. Briscoe, "Explicit Congestion
Notification (ECN) Protocol for Very Low Queuing Delay Notification (ECN) Protocol for Very Low Queuing Delay
(L4S)", Work in Progress, Internet-Draft, draft-ietf- (L4S)", Work in Progress, Internet-Draft, draft-ietf-
tsvwg-ecn-l4s-id-28, 8 August 2022, tsvwg-ecn-l4s-id-28, 8 August 2022,
<https://www.ietf.org/archive/id/draft-ietf-tsvwg-ecn-l4s- <https://datatracker.ietf.org/api/v1/doc/document/draft-
id-28.txt>. ietf-tsvwg-ecn-l4s-id/>.
[I-D.ietf-tsvwg-l4sops] [I-D.ietf-tsvwg-l4sops]
White, G., "Operational Guidance for Deployment of L4S in White, G., "Operational Guidance for Deployment of L4S in
the Internet", Work in Progress, Internet-Draft, draft- the Internet", Work in Progress, Internet-Draft, draft-
ietf-tsvwg-l4sops-03, 28 April 2022, ietf-tsvwg-l4sops-03, 28 April 2022,
<https://www.ietf.org/archive/id/draft-ietf-tsvwg-l4sops- <https://datatracker.ietf.org/api/v1/doc/document/draft-
03.txt>. ietf-tsvwg-l4sops/>.
[I-D.ietf-tsvwg-nqb] [I-D.ietf-tsvwg-nqb]
White, G. and T. Fossati, "A Non-Queue-Building Per-Hop White, G. and T. Fossati, "A Non-Queue-Building Per-Hop
Behavior (NQB PHB) for Differentiated Services", Work in Behavior (NQB PHB) for Differentiated Services", Work in
Progress, Internet-Draft, draft-ietf-tsvwg-nqb-10, 4 March Progress, Internet-Draft, draft-ietf-tsvwg-nqb-10, 4 March
2022, <https://www.ietf.org/archive/id/draft-ietf-tsvwg- 2022, <https://datatracker.ietf.org/api/v1/doc/document/
nqb-10.txt>. draft-ietf-tsvwg-nqb/>.
[I-D.ietf-tsvwg-rfc6040update-shim] [I-D.ietf-tsvwg-rfc6040update-shim]
Briscoe, B., "Propagating Explicit Congestion Notification Briscoe, B., "Propagating Explicit Congestion Notification
Across IP Tunnel Headers Separated by a Shim", Work in Across IP Tunnel Headers Separated by a Shim", Work in
Progress, Internet-Draft, draft-ietf-tsvwg-rfc6040update- Progress, Internet-Draft, draft-ietf-tsvwg-rfc6040update-
shim-15, 11 July 2022, <https://www.ietf.org/archive/id/ shim-15, 11 July 2022,
draft-ietf-tsvwg-rfc6040update-shim-15.txt>. <https://datatracker.ietf.org/api/v1/doc/document/draft-
ietf-tsvwg-rfc6040update-shim/>.
[I-D.morton-tsvwg-codel-approx-fair] [I-D.morton-tsvwg-codel-approx-fair]
Morton, J. and P. G. Heist, "Controlled Delay Approximate Morton, J. and P. G. Heist, "Controlled Delay Approximate
Fairness AQM", Work in Progress, Internet-Draft, draft- Fairness AQM", Work in Progress, Internet-Draft, draft-
morton-tsvwg-codel-approx-fair-01, 9 March 2020, morton-tsvwg-codel-approx-fair-01, 9 March 2020,
<https://www.ietf.org/archive/id/draft-morton-tsvwg-codel- <https://www.ietf.org/archive/id/draft-morton-tsvwg-codel-
approx-fair-01.txt>. approx-fair-01.txt>.
[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", Work in Progress, Internet- and Long Distance Networks", Work in Progress, Internet-
Draft, draft-sridharan-tcpm-ctcp-02, 11 November 2008, Draft, draft-sridharan-tcpm-ctcp-02, 29 October 2007,
<https://www.ietf.org/archive/id/draft-sridharan-tcpm- <https://datatracker.ietf.org/api/v1/doc/document/draft-
ctcp-02.txt>. sridharan-tcpm-ctcp/>.
[I-D.stewart-tsvwg-sctpecn] [I-D.stewart-tsvwg-sctpecn]
Stewart, R. R., Tuexen, M., and X. Dong, "ECN for Stream Stewart, R. R., Tuexen, M., and X. Dong, "ECN for Stream
Control Transmission Protocol (SCTP)", Work in Progress, Control Transmission Protocol (SCTP)", Work in Progress,
Internet-Draft, draft-stewart-tsvwg-sctpecn-05, 15 January Internet-Draft, draft-stewart-tsvwg-sctpecn-05, 15 January
2014, <https://www.ietf.org/archive/id/draft-stewart- 2014, <https://www.ietf.org/archive/id/draft-stewart-
tsvwg-sctpecn-05.txt>. tsvwg-sctpecn-05.txt>.
[L4Sdemo16] [L4Sdemo16]
Bondarenko, O., De Schepper, K., Tsang, I., and B. Bondarenko, O., De Schepper, K., Tsang, I., and B.
skipping to change at page 42, line 10 skipping to change at page 42, line 5
[RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of [RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of
Explicit Congestion Notification (ECN) in IP Networks", Explicit Congestion Notification (ECN) in IP Networks",
RFC 2884, DOI 10.17487/RFC2884, July 2000, RFC 2884, DOI 10.17487/RFC2884, July 2000,
<https://www.rfc-editor.org/info/rfc2884>. <https://www.rfc-editor.org/info/rfc2884>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC3246] Davie, B., Charny, A., Bennet, J C R., Benson, K., Le [RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
Boudec, J Y., Courtney, W., Davari, S., Firoiu, V., and D. Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
<https://www.rfc-editor.org/info/rfc3246>. <https://www.rfc-editor.org/info/rfc3246>.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces", Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, DOI 10.17487/RFC3540, June 2003, RFC 3540, DOI 10.17487/RFC3540, June 2003,
<https://www.rfc-editor.org/info/rfc3540>. <https://www.rfc-editor.org/info/rfc3540>.
[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows",
skipping to change at page 43, line 33 skipping to change at page 43, line 29
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
DOI 10.17487/RFC6817, December 2012, DOI 10.17487/RFC6817, December 2012,
<https://www.rfc-editor.org/info/rfc6817>. <https://www.rfc-editor.org/info/rfc6817>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>.
[RFC7560] Kuehlewind, M., Ed., Scheffenegger, R., and B. Briscoe, [RFC7560] Kuehlewind, M., Ed., Scheffenegger, R., and B. Briscoe,
"Problem Statement and Requirements for Increased Accuracy "Problem Statement and Requirements for Increased Accuracy
in Explicit Congestion Notification (ECN) Feedback", in Explicit Congestion Notification (ECN) Feedback",
RFC 7560, DOI 10.17487/RFC7560, August 2015, RFC 7560, DOI 10.17487/RFC7560, August 2015,
<https://www.rfc-editor.org/info/rfc7560>. <https://www.rfc-editor.org/info/rfc7560>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management", Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/info/rfc7567>. <https://www.rfc-editor.org/info/rfc7567>.
skipping to change at page 45, line 29 skipping to change at page 45, line 24
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>. <https://www.rfc-editor.org/info/rfc9000>.
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/info/rfc9001>. <https://www.rfc-editor.org/info/rfc9001>.
[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/info/rfc9113>.
[SCReAM] Johansson, I., "SCReAM", github repository; , [SCReAM] Johansson, I., "SCReAM", github repository; ,
<https://github.com/EricssonResearch/scream/blob/master/ <https://github.com/EricssonResearch/scream/blob/master/
README.md>. README.md>.
[TCP-CA] Jacobson, V. and M.J. Karels, "Congestion Avoidance and [TCP-CA] Jacobson, V. and M.J. Karels, "Congestion Avoidance and
Control", Laurence Berkeley Labs Technical Report , Control", Laurence Berkeley Labs Technical Report ,
November 1988, <http://ee.lbl.gov/papers/congavoid.pdf>. November 1988, <http://ee.lbl.gov/papers/congavoid.pdf>.
[UnorderedLTE] [UnorderedLTE]
Austrheim, M.V., "Implementing immediate forwarding for 4G Austrheim, M.V., "Implementing immediate forwarding for 4G
in a network simulator", Masters Thesis, Uni Oslo , June in a network simulator", Masters Thesis, Uni Oslo , June
2019. 2019.
Acknowledgements Acknowledgements
Thanks to Richard Scheffenegger, Wes Eddy, Karen Nielsen, David Thanks to Richard Scheffenegger, Wes Eddy, Karen Nielsen, David
Black, Jake Holland, Vidhi Goel, Ermin Sakic, Praveen Black, Jake Holland, Vidhi Goel, Ermin Sakic, Praveen
Balasubramanian, Gorry Fairhurst, Mirja Kuehlewind, Philip Eardley, Balasubramanian, Gorry Fairhurst, Mirja Kuehlewind, Philip Eardley,
Neal Cardwell, Pete Heist and Martin Duke for their useful review Neal Cardwell, Pete Heist and Martin Duke for their useful review
comments. Thanks also to the area reviewers: Marco Tiloca. comments. Thanks also to the area reviewers: Marco Tiloca, Lars
Eggert, Roman Danyliw and Eric Vyncke.
Bob Briscoe and Koen De Schepper were part-funded by the European Bob Briscoe and Koen De Schepper were part-funded by the European
Community under its Seventh Framework Programme through the Reducing Community under its Seventh Framework Programme through the Reducing
Internet Transport Latency (RITE) project (ICT-317700). The Internet Transport Latency (RITE) project (ICT-317700). The
contribution of Koen De Schepper was also part-funded by the 5Growth contribution of Koen De Schepper was also part-funded by the 5Growth
and DAEMON EU H2020 projects. Bob Briscoe was also part-funded by and DAEMON EU H2020 projects. Bob Briscoe was also part-funded by
the Research Council of Norway through the TimeIn project, partly by the Research Council of Norway through the TimeIn project, partly by
CableLabs and partly by the Comcast Innovation Fund. The views CableLabs and partly by the Comcast Innovation Fund. The views
expressed here are solely those of the authors. expressed here are solely those of the authors.
 End of changes. 37 change blocks. 
114 lines changed or deleted 107 lines changed or added

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