draft-ietf-tsvwg-l4s-arch-08.txt   draft-ietf-tsvwg-l4s-arch-09.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: May 19, 2021 Nokia Bell Labs Expires: November 22, 2021 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
November 15, 2020 May 21, 2021
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-08 draft-ietf-tsvwg-l4s-arch-09
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). The insight on which L4S is based is that the root throughput (L4S). The insight on which L4S is based is that the root
cause of queuing delay is in the congestion controllers of senders, cause of queuing delay is in the congestion controllers of senders,
not in the queue itself. The L4S architecture is intended to enable not in the queue itself. The L4S architecture is intended to enable
_all_ Internet applications to transition away from congestion _all_ Internet applications to transition away from congestion
control algorithms that cause queuing delay, to a new class of control algorithms that cause queuing delay, to a new class of
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 May 19, 2021. This Internet-Draft will expire on November 22, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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
skipping to change at page 3, line 45 skipping to change at page 3, line 45
longer retransmission delays. longer retransmission delays.
It has been demonstrated that, once access network bit rates reach It has been demonstrated that, once access network bit rates reach
levels now common in the developed world, increasing capacity offers levels now common in the developed world, increasing capacity offers
diminishing returns if latency (delay) is not addressed. diminishing returns if latency (delay) is not addressed.
Differentiated services (Diffserv) offers Expedited Forwarding Differentiated services (Diffserv) offers Expedited Forwarding
(EF [RFC3246]) for some packets at the expense of others, but this is (EF [RFC3246]) for some packets at the expense of others, but this is
not sufficient when all (or most) of a user's applications require not sufficient when all (or most) of a user's applications require
low latency. low latency.
Therefore, the goal is an Internet service with ultra-Low queueing Therefore, the goal is an Internet service with very Low queueing
Latency, ultra-Low Loss and Scalable throughput (L4S). Ultra-low Latency, very Low Loss and Scalable throughput (L4S). Very low
queuing latency means less than 1 millisecond (ms) on average and queuing latency means less than 1 millisecond (ms) on average and
less than about 2 ms at the 99th percentile. L4S is potentially for less than about 2 ms at the 99th percentile. L4S is potentially for
_all_ traffic - a service for all traffic needs none of the _all_ traffic - a service for all traffic needs none of the
configuration or management baggage (traffic policing, traffic configuration or management baggage (traffic policing, traffic
contracts) associated with favouring some traffic over others. This contracts) associated with favouring some traffic over others. This
document describes the L4S architecture for achieving these goals. document describes the L4S architecture for achieving these goals.
It must be said that queuing delay only degrades performance It must be said that queuing delay only degrades performance
infrequently [Hohlfeld14]. It only occurs when a large enough infrequently [Hohlfeld14]. It only occurs when a large enough
capacity-seeking (e.g. TCP) flow is running alongside the user's capacity-seeking (e.g. TCP) flow is running alongside the user's
skipping to change at page 5, line 33 skipping to change at page 5, line 33
developed as a minimal complexity solution to this problem. It developed as a minimal complexity solution to this problem. It
acts like a 'semi-permeable' membrane that partitions latency but acts like a 'semi-permeable' membrane that partitions latency but
not bandwidth. As such, the two queues are for transition from not bandwidth. As such, the two queues are for transition from
Classic to L4S behaviour, not bandwidth prioritization. Section 4 Classic to L4S behaviour, not bandwidth prioritization. Section 4
gives a high level explanation of how FQ and DualQ solutions work, gives a high level explanation of how FQ and DualQ solutions work,
and [I-D.ietf-tsvwg-aqm-dualq-coupled] gives a full explanation of and [I-D.ietf-tsvwg-aqm-dualq-coupled] gives a full explanation of
the DualQ Coupled AQM framework. the 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] concludes
various alternative identifiers for L4S, and concludes that all that all alternatives involve compromises, but the ECT(1) and CE
alternatives involve compromises, but the ECT(1) and CE codepoints 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
[RFC3649]. The one used most widely (in controlled environments) [RFC3649]. The one used most widely (in controlled environments)
is Data Center TCP (DCTCP [RFC8257]), which has been implemented is Data Center TCP (DCTCP [RFC8257]), which has been implemented
and deployed in Windows Server Editions (since 2012), in Linux and and deployed in Windows Server Editions (since 2012), in Linux and
in FreeBSD. Although DCTCP as-is 'works' well over the public in FreeBSD. Although DCTCP as-is 'works' well over the public
Internet, most implementations lack certain safety features that Internet, most implementations lack certain safety features that
will be necessary once it is used outside controlled environments will be necessary once it is used outside controlled environments
like data centres (see Section 6.4.3 and Appendix A). Scalable like data centres (see Section 6.4.3 and Appendix A). Scalable
skipping to change at page 8, line 33 skipping to change at page 8, line 32
b. [I-D.ietf-tsvwg-ecn-l4s-id] recommends ECT(1) is used as the b. [I-D.ietf-tsvwg-ecn-l4s-id] recommends 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 requirements for identifying Classic packets. This satisfies the requirements 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
into the L4S queue. [I-D.ietf-tsvwg-ecn-l4s-id] explains why 5 into the L4S queue. Appendix B of [I-D.ietf-tsvwg-ecn-l4s-id]
unlikely eventualities all have to coincide for this to have any explains why five unlikely eventualities all have to coincide for
detrimental effect, which even then would only involve a this to have any detrimental effect, which even then would only
vanishingly small likelihood of a spurious retransmission. involve a vanishingly small likelihood of a spurious
retransmission.
c. A network operator might wish to include certain unresponsive, c. A network operator might wish to include certain unresponsive,
non-L4S traffic in the L4S queue if it is deemed to be smoothly non-L4S traffic in the L4S queue if it is deemed to be smoothly
enough paced and low enough rate not to build a queue. For enough paced and low enough rate not to build a queue. For
instance, VoIP, low rate datagrams to sync online games, instance, VoIP, low rate datagrams to sync online games,
relatively low rate application-limited traffic, DNS, LDAP, etc. relatively low rate application-limited traffic, DNS, LDAP, etc.
This traffic would need to be tagged with specific identifiers, This traffic would need to be tagged with specific identifiers,
e.g. a low latency Diffserv Codepoint such as Expedited e.g. a low latency Diffserv Codepoint such as Expedited
Forwarding (EF [RFC3246]), Non-Queue-Building Forwarding (EF [RFC3246]), Non-Queue-Building
(NQB [I-D.white-tsvwg-nqb]), or operator-specific identifiers. (NQB [I-D.white-tsvwg-nqb]), or operator-specific identifiers.
skipping to change at page 9, line 38 skipping to change at page 9, line 38
L4S traffic to ensure that neither has priority when it comes to L4S traffic to ensure that neither has priority when it comes to
bandwidth. The tension between prioritizing L4S and coupling bandwidth. The tension between prioritizing L4S and coupling
marking from Classic results in per-flow fairness. To protect marking from Classic results in per-flow fairness. To protect
against unresponsive traffic in the L4S queue taking advantage of against unresponsive traffic in the L4S queue taking advantage of
the prioritization and starving the Classic queue, it is the prioritization and starving the Classic queue, it is
advisable not to use strict priority, but instead to use a advisable not to use strict priority, but instead to use a
weighted scheduler (see Appendix A of weighted scheduler (see Appendix A of
[I-D.ietf-tsvwg-aqm-dualq-coupled]). [I-D.ietf-tsvwg-aqm-dualq-coupled]).
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 very
low queuing delay. low queuing delay.
The Dual Queue Coupled AQM has been specified as generically as The Dual Queue Coupled 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. Informational appendices in are free to implement diverse ideas. Informational appendices in
that draft give pseudocode examples of two different specific AQM that draft give pseudocode examples of two different specific AQM
approaches: one called DualPI2 (pronounced Dual PI approaches: one called DualPI2 (pronounced Dual PI
Squared) [DualPI2Linux] that uses the PI2 variant of PIE, and a Squared) [DualPI2Linux] that uses the PI2 variant of PIE, and a
zero-config variant of RED called Curvy RED. A DualQ Coupled AQM zero-config variant of RED called Curvy RED. A DualQ Coupled AQM
skipping to change at page 12, line 45 skipping to change at page 12, line 45
network (which doesn't know the round trip times of all the network (which doesn't know the round trip times of all the
flows) to the host (which knows its own round trip time). flows) to the host (which knows its own round trip time).
Previously, the network had to smooth to keep a worst-case Previously, the network had to smooth to keep a worst-case
round trip stable, which delayed congestion signals by 100-200 round trip stable, which delayed congestion signals by 100-200
ms. ms.
All the above makes it clear that explicit congestion signalling All the above makes it clear that explicit congestion signalling
is only advantageous for latency if it does not have to be is only advantageous for latency if it does not have to be
considered 'equivalent to' drop (as was required with Classic considered 'equivalent to' drop (as was required with Classic
ECN [RFC3168]). Therefore, in an L4S AQM, the L4S queue uses a ECN [RFC3168]). Therefore, in an L4S AQM, the L4S queue uses a
new L4S variant of ECN that is not equivalent to new L4S variant of ECN that is not equivalent to drop (see section
drop [I-D.ietf-tsvwg-ecn-l4s-id], while the Classic queue uses 5.2 of [I-D.ietf-tsvwg-ecn-l4s-id]), while the Classic queue uses
either classic ECN [RFC3168] or drop, which are equivalent to each either classic ECN [RFC3168] or drop, which are equivalent to each
other. other.
Before Classic ECN was standardized, there were various proposals Before Classic ECN was standardized, there were various proposals
to give an ECN mark a different meaning from drop. However, there to give an ECN mark a different meaning from drop. However, there
was no particular reason to agree on any one of the alternative was no particular reason to agree on any one of the alternative
meanings, so 'equivalent to drop' was the only compromise that meanings, so 'equivalent to drop' was the only compromise that
could be reached. RFC 3168 contains a statement that: could be reached. RFC 3168 contains a statement that:
"An environment where all end nodes were ECN-Capable could "An environment where all end nodes were ECN-Capable could
skipping to change at page 15, line 36 skipping to change at page 15, line 36
they starve them. they starve them.
Per-flow queuing or marking: Similarly, per-flow approaches such as Per-flow queuing or marking: Similarly, per-flow approaches such as
FQ-CoDel or Approx Fair CoDel [AFCD] are not incompatible with the FQ-CoDel or Approx Fair CoDel [AFCD] are not incompatible with the
L4S approach. However, per-flow queuing alone is not enough - it L4S approach. However, per-flow queuing alone is not enough - it
only isolates the queuing of one flow from others; not from only isolates the queuing of one flow from others; not from
itself. Per-flow implementations still need to have support for itself. Per-flow implementations still need to have support for
scalable congestion control added, which has already been done in scalable congestion control added, which has already been done in
FQ-CoDel (see Sec.5.2.7 of [RFC8290]). Without this simple FQ-CoDel (see Sec.5.2.7 of [RFC8290]). Without this simple
modification, per-flow AQMs like FQ-CoDel would still not be able modification, per-flow AQMs like FQ-CoDel would still not be able
to support applications that need both ultra-low delay and high to support applications that need both very low delay and high
bandwidth, e.g. video-based control of remote procedures, or bandwidth, e.g. video-based control of remote procedures, or
interactive cloud-based video (see Note 1 below). interactive cloud-based video (see Note 1 below).
Although per-flow techniques are not incompatible with L4S, it is Although per-flow techniques are not incompatible with L4S, it is
important to have the DualQ alternative. This is because handling important to have the DualQ alternative. This is because handling
end-to-end (layer 4) flows in the network (layer 3 or 2) precludes end-to-end (layer 4) flows in the network (layer 3 or 2) precludes
some important end-to-end functions. For instance: some important end-to-end functions. For instance:
A. Per-flow forms of L4S like FQ-CoDel are incompatible with full A. Per-flow forms of L4S like FQ-CoDel are incompatible with full
end-to-end encryption of transport layer identifiers for end-to-end encryption of transport layer identifiers for
privacy and confidentiality (e.g. IPSec or encrypted VPN privacy and confidentiality (e.g. IPSec or encrypted VPN
tunnels), because they require packet inspection to access the tunnels), because they require packet inspection to access the
end-to-end transport flow identifiers. end-to-end transport flow identifiers.
In contrast, the DualQ form of L4S requires no deeper In contrast, the DualQ form of L4S requires no deeper
inspection than the IP layer. So, as long as operators take inspection than the IP layer. So, as long as operators take
the DualQ approach, their users can have both ultra-low the DualQ approach, their users can have both very low queuing
queuing delay and full end-to-end encryption [RFC8404]. delay and full end-to-end encryption [RFC8404].
B. With per-flow forms of L4S, the network takes over control of B. With per-flow forms of L4S, the network takes over control of
the relative rates of each application flow. Some see it as the relative rates of each application flow. Some see it as
an advantage that the network will prevent some flows running an advantage that the network will prevent some flows running
faster than others. Others consider it an inherent part of faster than others. Others consider it an inherent part of
the Internet's appeal that applications can control their rate the Internet's appeal that applications can control their rate
while taking account of the needs of others via congestion while taking account of the needs of others via congestion
signals. They maintain that this has allowed applications signals. They maintain that this has allowed applications
with interesting rate behaviours to evolve, for instance, with interesting rate behaviours to evolve, for instance,
variable bit-rate video that varies around an equal share variable bit-rate video that varies around an equal share
skipping to change at page 22, line 49 skipping to change at page 22, line 49
For any one L4S flow to work, it requires 3 parts to have been For any one L4S flow to work, it requires 3 parts to have been
deployed. This was the same deployment problem that ECN deployed. This was the same deployment problem that ECN
faced [RFC8170] so we have learned from that experience. faced [RFC8170] so we have learned from that experience.
Firstly, L4S deployment exploits the fact that DCTCP already exists Firstly, L4S deployment exploits the fact that DCTCP already exists
on many Internet hosts (Windows, FreeBSD and Linux); both servers and on many Internet hosts (Windows, FreeBSD and Linux); both servers and
clients. Therefore, just deploying an L4S AQM at a network clients. Therefore, just deploying an L4S AQM at a network
bottleneck immediately gives a working deployment of all the L4S bottleneck immediately gives a working deployment of all the L4S
parts. DCTCP needs some safety concerns to be fixed for general use parts. DCTCP needs some safety concerns to be fixed for general use
over the public Internet (see Section 2.3 of over the public Internet (see Section 4.3 of
[I-D.ietf-tsvwg-ecn-l4s-id]), but DCTCP is not on by default, so [I-D.ietf-tsvwg-ecn-l4s-id]), but DCTCP is not on by default, so
these issues can be managed within controlled deployments or these issues can be managed within controlled deployments or
controlled trials. controlled trials.
Secondly, the performance improvement with L4S is so significant that Secondly, the performance improvement with L4S is so significant that
it enables new interactive services and products that were not it enables new interactive services and products that were not
previously possible. It is much easier for companies to initiate new previously possible. It is much easier for companies to initiate new
work on deployment if there is budget for a new product trial. If, work on deployment if there is budget for a new product trial. If,
in contrast, there were only an incremental performance improvement in contrast, there were only an incremental performance improvement
(as with Classic ECN), spending on deployment tends to be much harder (as with Classic ECN), spending on deployment tends to be much harder
to justify. to justify.
Thirdly, the L4S identifier is defined so that initially network Thirdly, the L4S identifier is defined so that initially network
operators can enable L4S exclusively for certain customers or certain operators can enable L4S exclusively for certain customers or certain
applications. But this is carefully defined so that it does not applications. But this is carefully defined so that it does not
compromise future evolution towards L4S as an Internet-wide service. compromise future evolution towards L4S as an Internet-wide service.
This is because the L4S identifier is defined not only as the end-to- This is because the L4S identifier is defined not only as the end-to-
end ECN field, but it can also optionally be combined with any other end ECN field, but it can also optionally be combined with any other
packet header or some status of a customer or their access packet header or some status of a customer or their access link (see
link [I-D.ietf-tsvwg-ecn-l4s-id]. Operators could do this anyway, section 5.4 of [I-D.ietf-tsvwg-ecn-l4s-id]). Operators could do this
even if it were not blessed by the IETF. However, it is best for the anyway, even if it were not blessed by the IETF. However, it is best
IETF to specify that, if they use their own local identifier, it must for the IETF to specify that, if they use their own local identifier,
be in combination with the IETF's identifier. Then, if an operator it must be in combination with the IETF's identifier. Then, if an
has opted for an exclusive local-use approach, later they only have operator has opted for an exclusive local-use approach, later they
to remove this extra rule to make the service work Internet-wide - it only have to remove this extra rule to make the service work
will already traverse middleboxes, peerings, etc. Internet-wide - it will already traverse middleboxes, peerings, etc.
+-+--------------------+----------------------+---------------------+ +-+--------------------+----------------------+---------------------+
| | Servers or proxies | Access link | Clients | | | Servers or proxies | Access link | Clients |
+-+--------------------+----------------------+---------------------+ +-+--------------------+----------------------+---------------------+
|0| DCTCP (existing) | | DCTCP (existing) | |0| DCTCP (existing) | | DCTCP (existing) |
+-+--------------------+----------------------+---------------------+ +-+--------------------+----------------------+---------------------+
|1| |Add L4S AQM downstream| | |1| |Add L4S AQM downstream| |
| | WORKS DOWNSTREAM FOR CONTROLLED DEPLOYMENTS/TRIALS | | | WORKS DOWNSTREAM FOR CONTROLLED DEPLOYMENTS/TRIALS |
+-+--------------------+----------------------+---------------------+ +-+--------------------+----------------------+---------------------+
|2| Upgrade DCTCP to | |Replace DCTCP feedb'k| |2| Upgrade DCTCP to | |Replace DCTCP feedb'k|
skipping to change at page 27, line 9 skipping to change at page 27, line 9
a single queue bottleneck might opt to police L4S traffic in order to a single queue bottleneck might opt to police L4S traffic in order to
protect competing Classic ECN traffic. protect competing Classic ECN traffic.
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 class, 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 ECN. If only the ECN L4S identifier matched, but not the as well as ECN. If only the ECN L4S identifier matched, but not the
source address (say), the classifier could direct these packets (from source address (say), the classifier could direct these packets (from
non-premium customers) into the Classic queue. Explaining clearly non-premium customers) into the Classic queue. Explaining clearly
how operators can use an additional local classifiers (see how operators can use an additional local classifiers (see section
[I-D.ietf-tsvwg-ecn-l4s-id]) is intended to remove any motivation to 5.4 of [I-D.ietf-tsvwg-ecn-l4s-id]) is intended to remove any
bleach the L4S identifier. Then at least the L4S ECN identifier will motivation to bleach the L4S identifier. Then at least the L4S ECN
be more likely to survive end-to-end even though the service may not identifier will be more likely to survive end-to-end even though the
be supported at every hop. Such local arrangements would only service may not be supported at every hop. Such local arrangements
require simple registered/not-registered packet classification, would only require simple registered/not-registered packet
rather than the managed, application-specific traffic policing classification, rather than the managed, application-specific traffic
against customer-specific traffic contracts that Diffserv uses. policing against customer-specific traffic contracts that Diffserv
uses.
8.2. 'Latency Friendliness' 8.2. 'Latency Friendliness'
Like the Classic service, the L4S service relies on self-constraint - Like the Classic service, the L4S service relies on self-constraint -
limiting rate in response to congestion. In addition, the L4S limiting rate in response to congestion. In addition, the L4S
service requires self-constraint in terms of limiting latency service requires self-constraint in terms of limiting latency
(burstiness). It is hoped that self-interest and guidance on dynamic (burstiness). It is hoped that self-interest and guidance on dynamic
behaviour (especially flow start-up, which might need to be behaviour (especially flow start-up, which might need to be
standardized) will be sufficient to prevent transports from sending standardized) will be sufficient to prevent transports from sending
excessive bursts of L4S traffic, given the application's own latency excessive bursts of L4S traffic, given the application's own latency
skipping to change at page 30, line 32 skipping to change at page 30, line 32
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 it is simple to add L4S support to FQ-CoDel, which instance it is simple to add L4S support to FQ-CoDel, which
classifies by application flow ID in the network. However, the main classifies by application flow ID in the network. However, the main
innovation of L4S is the DualQ AQM framework that does not need to innovation of L4S is the DualQ AQM framework that does not need to
inspect any deeper than the outermost IP header, because the L4S inspect any deeper than the outermost IP header, because the L4S
identifier is in the IP-ECN field. identifier is in the IP-ECN field.
Thus, the L4S architecture enables ultra-low queuing delay without Thus, the L4S architecture enables very low queuing delay without
_requiring_ inspection of information above the IP layer. This means _requiring_ inspection of information above the IP layer. This means
that users who want to encrypt application flow identifiers, e.g. in that users who want to encrypt application flow identifiers, e.g. in
IPSec or other encrypted VPN tunnels, don't have to sacrifice low IPSec or other encrypted VPN tunnels, don't have to sacrifice low
delay [RFC8404]. delay [RFC8404].
Because L4S can provide low delay for a broad set of applications Because L4S can provide low delay for a broad set of applications
that choose to use it, there is no need for individual applications that choose to use it, there is no need for individual applications
or classes within that broad set to be distinguishable in any way or classes within that broad set to be distinguishable in any way
while traversing networks. This removes much of the ability to while traversing networks. This removes much of the ability to
correlate between the delay requirements of traffic and other correlate between the delay requirements of traffic and other
skipping to change at page 32, line 22 skipping to change at page 32, line 22
Low Latency", draft-briscoe-docsis-q-protection-00 (work Low Latency", draft-briscoe-docsis-q-protection-00 (work
in progress), July 2019. in progress), July 2019.
[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",
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. H., 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-avtcore-cc-feedback-message] [I-D.ietf-avtcore-cc-feedback-message]
Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP Sarker, Z., Perkins, C., Singh, V., and M. A. Ramalho,
Control Protocol (RTCP) Feedback for Congestion Control", "RTP Control Protocol (RTCP) Feedback for Congestion
draft-ietf-avtcore-cc-feedback-message-09 (work in Control", draft-ietf-avtcore-cc-feedback-message-09 (work
progress), November 2020. in progress), November 2020.
[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-32 (work and Secure Transport", draft-ietf-quic-transport-34 (work
in progress), October 2020. in progress), January 2021.
[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-13 (work in progress), November 2020. ecn-14 (work in progress), February 2021.
[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-06 (work in progress), draft-ietf-tcpm-generalized-ecn-07 (work in progress),
October 2020. February 2021.
[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. 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)", draft-ietf-tsvwg-aqm-dualq-coupled-12 (work in (L4S)", draft-ietf-tsvwg-aqm-dualq-coupled-14 (work in
progress), July 2020. progress), March 2021.
[I-D.ietf-tsvwg-ecn-encap-guidelines] [I-D.ietf-tsvwg-ecn-encap-guidelines]
Briscoe, B., Kaippallimalil, J., and P. Thaler, Briscoe, B. and J. Kaippallimalil, "Guidelines for Adding
"Guidelines for Adding Congestion Notification to Congestion Notification to Protocols that Encapsulate IP",
Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- draft-ietf-tsvwg-ecn-encap-guidelines-15 (work in
encap-guidelines-13 (work in progress), May 2019. progress), March 2021.
[I-D.ietf-tsvwg-ecn-l4s-id] [I-D.ietf-tsvwg-ecn-l4s-id]
Schepper, K. and B. Briscoe, "Identifying Modified Schepper, K. D. and B. Briscoe, "Explicit Congestion
Explicit Congestion Notification (ECN) Semantics for Notification (ECN) Protocol for Ultra-Low Queuing Delay
Ultra-Low Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s- (L4S)", draft-ietf-tsvwg-ecn-l4s-id-14 (work in progress),
id-11 (work in progress), November 2020. March 2021.
[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", draft-ietf- Across IP Tunnel Headers Separated by a Shim", draft-ietf-
tsvwg-rfc6040update-shim-10 (work in progress), March tsvwg-rfc6040update-shim-13 (work in progress), March
2020. 2021.
[I-D.morton-tsvwg-codel-approx-fair] [I-D.morton-tsvwg-codel-approx-fair]
Morton, J. and P. Heist, "Controlled Delay Approximate Morton, J. and P. G. Heist, "Controlled Delay Approximate
Fairness AQM", draft-morton-tsvwg-codel-approx-fair-01 Fairness AQM", draft-morton-tsvwg-codel-approx-fair-01
(work in progress), March 2020. (work in progress), March 2020.
[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
(work in progress), November 2008. (work in progress), November 2008.
[I-D.stewart-tsvwg-sctpecn] [I-D.stewart-tsvwg-sctpecn]
Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream Stewart, R. R., Tuexen, M., and X. Dong, "ECN for Stream
Control Transmission Protocol (SCTP)", draft-stewart- Control Transmission Protocol (SCTP)", draft-stewart-
tsvwg-sctpecn-05 (work in progress), January 2014. tsvwg-sctpecn-05 (work in progress), January 2014.
[I-D.white-tsvwg-nqb] [I-D.white-tsvwg-nqb]
White, G. and T. Fossati, "Identifying and Handling Non White, G. and T. Fossati, "Identifying and Handling Non
Queue Building Flows in a Bottleneck Link", draft-white- Queue Building Flows in a Bottleneck Link", draft-white-
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, "Ultra-Low Delay for All: Live Experience, Live
Live Analysis", Proc. MMSYS'16 pp33:1--33:4, May 2016, 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 )>.
[LEDBAT_AQM] [LEDBAT_AQM]
Al-Saadi, R., Armitage, G., and J. But, "Characterising Al-Saadi, R., Armitage, G., and J. But, "Characterising
LEDBAT Performance Through Bottlenecks Using PIE, FQ-CoDel LEDBAT Performance Through Bottlenecks Using PIE, FQ-CoDel
and FQ-PIE Active Queue Management", Proc. IEEE 42nd and FQ-PIE Active Queue Management", Proc. IEEE 42nd
Conference on Local Computer Networks (LCN) 278--285, Conference on Local Computer Networks (LCN) 278--285,
2017, <https://ieeexplore.ieee.org/document/8109367>. 2017, <https://ieeexplore.ieee.org/document/8109367>.
skipping to change at page 39, line 16 skipping to change at page 39, line 16
control intended for controlled environments; control intended for controlled environments;
XXX Prague: Applicable to a Scalable variant of XXX (TCP/SCTP/RMCAT) XXX Prague: Applicable to a Scalable variant of XXX (TCP/SCTP/RMCAT)
congestion control. congestion control.
+-----+------------------------+------------------------------------+ +-----+------------------------+------------------------------------+
| Req | Requirement | Reference | | Req | Requirement | Reference |
| # | | | | # | | |
+-----+------------------------+------------------------------------+ +-----+------------------------+------------------------------------+
| 0 | ARCHITECTURE | | | 0 | ARCHITECTURE | |
| 1 | L4S IDENTIFIER | [I-D.ietf-tsvwg-ecn-l4s-id] | | 1 | L4S IDENTIFIER | [I-D.ietf-tsvwg-ecn-l4s-id] S.3 |
| 2 | DUAL QUEUE AQM | [I-D.ietf-tsvwg-aqm-dualq-coupled] | | 2 | DUAL QUEUE AQM | [I-D.ietf-tsvwg-aqm-dualq-coupled] |
| 3 | Suitable ECN Feedback | [I-D.ietf-tcpm-accurate-ecn], | | 3 | Suitable ECN Feedback | [I-D.ietf-tcpm-accurate-ecn] |
| | | S.4.2, |
| | | [I-D.stewart-tsvwg-sctpecn]. | | | | [I-D.stewart-tsvwg-sctpecn]. |
| | | | | | | |
| | SCALABLE TRANSPORT - | | | | SCALABLE TRANSPORT - | |
| | SAFETY ADDITIONS | | | | SAFETY ADDITIONS | |
| 4-1 | Fall back to | [I-D.ietf-tsvwg-ecn-l4s-id] S.2.3, | | 4-1 | Fall back to | [I-D.ietf-tsvwg-ecn-l4s-id] S.4.3, |
| | Reno/Cubic on loss | [RFC8257] | | | Reno/Cubic on loss | [RFC8257] |
| 4-2 | Fall back to | [I-D.ietf-tsvwg-ecn-l4s-id] S.2.3 | | 4-2 | Fall back to | [I-D.ietf-tsvwg-ecn-l4s-id] S.4.3 |
| | Reno/Cubic if classic | | | | Reno/Cubic if classic | |
| | ECN bottleneck | | | | ECN bottleneck | |
| | detected | | | | detected | |
| | | | | | | |
| 4-3 | Reduce RTT-dependence | [I-D.ietf-tsvwg-ecn-l4s-id] S.2.3 | | 4-3 | Reduce RTT-dependence | [I-D.ietf-tsvwg-ecn-l4s-id] S.4.3 |
| | | | | | | |
| 4-4 | Scaling TCP's | [I-D.ietf-tsvwg-ecn-l4s-id] S.2.3, | | 4-4 | Scaling TCP's | [I-D.ietf-tsvwg-ecn-l4s-id] S.4.3, |
| | Congestion Window for | [TCP-sub-mss-w] | | | Congestion Window for | [TCP-sub-mss-w] |
| | Small Round Trip Times | | | | Small Round Trip Times | |
| | SCALABLE TRANSPORT - | | | | SCALABLE TRANSPORT - | |
| | PERFORMANCE | | | | PERFORMANCE | |
| | ENHANCEMENTS | | | | ENHANCEMENTS | |
| 5-1 | Setting ECT in TCP | [I-D.ietf-tcpm-generalized-ecn] | | 5-1 | Setting ECT in TCP | [I-D.ietf-tcpm-generalized-ecn] |
| | Control Packets and | | | | Control Packets and | |
| | Retransmissions | | | | Retransmissions | |
| 5-2 | Faster-than-additive | [I-D.ietf-tsvwg-ecn-l4s-id] (Appx | | 5-2 | Faster-than-additive | [I-D.ietf-tsvwg-ecn-l4s-id] (Appx |
| | increase | A.2.2) | | | increase | A.2.2) |
 End of changes. 35 change blocks. 
72 lines changed or deleted 74 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/