draft-ietf-tsvwg-l4s-arch-02.txt   draft-ietf-tsvwg-l4s-arch-03.txt 
Transport Area Working Group B. Briscoe, Ed. Transport Area Working Group B. Briscoe, Ed.
Internet-Draft CableLabs Internet-Draft CableLabs
Intended status: Informational K. De Schepper Intended status: Informational K. De Schepper
Expires: September 23, 2018 Nokia Bell Labs Expires: April 25, 2019 Nokia Bell Labs
M. Bagnulo Braun M. Bagnulo Braun
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
March 22, 2018 October 22, 2018
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-02 draft-ietf-tsvwg-l4s-arch-03
Abstract Abstract
This document describes the L4S architecture for the provision of a This document describes the L4S architecture for the provision of a
new Internet service that could eventually replace best efforts for new Internet service that could eventually replace best efforts for
all traffic: Low Latency, Low Loss, Scalable throughput (L4S). It is all traffic: Low Latency, Low Loss, Scalable throughput (L4S). It is
becoming common for _all_ (or most) applications being run by a user becoming common for _all_ (or most) applications being run by a user
at any one time to require low latency. However, the only solution at any one time to require low latency. However, the only solution
the IETF can offer for ultra-low queuing delay is Diffserv, which the IETF can offer for ultra-low queuing delay is Diffserv, which
only favours a minority of packets at the expense of others. In only favours a minority of packets at the expense of others. In
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 September 23, 2018. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
skipping to change at page 4, line 36 skipping to change at page 4, line 36
20 ms on _average_ with a Classic TCP and current state-of-the-art 20 ms on _average_ with a Classic TCP and current state-of-the-art
AQMs such as fq_CoDel [RFC8290] or PIE [RFC8033]. Also, with a AQMs such as fq_CoDel [RFC8290] or PIE [RFC8033]. Also, with a
Classic TCP, 5 ms of queuing is usually only possible by losing some Classic TCP, 5 ms of queuing is usually only possible by losing some
utilization. utilization.
It has been convincingly demonstrated [DCttH15] that it is possible It has been convincingly demonstrated [DCttH15] that it is possible
to deploy such an L4S service alongside the existing best efforts to deploy such an L4S service alongside the existing best efforts
service so that all of a user's applications can shift to it when service so that all of a user's applications can shift to it when
their stack is updated. Access networks are typically designed with their stack is updated. Access networks are typically designed with
one link as the bottleneck for each site (which might be a home, one link as the bottleneck for each site (which might be a home,
small enterprise or mobile device), so deployment at a single node small enterprise or mobile device), so deployment at a single network
should give nearly all the benefit. The L4S approach requires node should give nearly all the benefit. The L4S approach also
component mechanisms in different parts of an Internet path to requires component mechanisms at the endpoints to fulfill its goal.
fulfill its goal. This document presents the L4S architecture, by This document presents the L4S architecture, by describing the
describing the different components and how they interact to provide different components and how they interact to provide the scalable
the scalable low-latency, low-loss, Internet service. low-latency, low-loss, Internet service.
2. L4S Architecture Overview 2. L4S Architecture Overview
There are three main components to the L4S architecture (illustrated There are three main components to the L4S architecture (illustrated
in Figure 1): in Figure 1):
1) Network: The L4S service traffic needs to be isolated from the 1) Network: The L4S service traffic needs to be isolated from the
queuing latency of the Classic service traffic. However, the two queuing latency of the Classic service traffic. However, the two
should be able to freely share a common pool of capacity. This is should be able to freely share a common pool of capacity. This is
because there is no way to predict how many flows at any one time because there is no way to predict how many flows at any one time
skipping to change at page 5, line 24 skipping to change at page 5, line 24
two are sufficient. two are sufficient.
2) Protocol: A host needs to distinguish L4S and Classic packets 2) Protocol: A host needs to distinguish L4S and Classic packets
with an identifier so that the network can classify them into with an identifier so that the network can classify them into
their separate treatments. [I-D.ietf-tsvwg-ecn-l4s-id] considers their separate treatments. [I-D.ietf-tsvwg-ecn-l4s-id] considers
various alternative identifiers, and concludes that all various alternative identifiers, and concludes that all
alternatives involve compromises, but the ECT(1) codepoint of the alternatives involve compromises, but the ECT(1) codepoint of the
ECN field is a workable solution. ECN field is 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 TCP first pointed out in [RFC3649]. The one scaling problem with TCP that was first pointed out in [RFC3649].
used most widely (in controlled environments) is Data Centre TCP The one used most widely (in controlled environments) is Data
(DCTCP [RFC8257]), which has been implemented and deployed in Centre TCP (DCTCP [RFC8257]), which has been implemented and
Windows Server Editions (since 2012), in Linux and in FreeBSD. deployed in Windows Server Editions (since 2012), in Linux and in
Although DCTCP as-is 'works' well over the public Internet, most FreeBSD. Although DCTCP as-is 'works' well over the public
implementations lack certain safety features that will be Internet, most implementations lack certain safety features that
necessary once it is used outside controlled environments like will be necessary once it is used outside controlled environments
data centres (see later). A similar scalable congestion control like data centres (see later). A similar scalable congestion
will also need to be transplanted into protocols other than TCP control will also need to be transplanted into protocols other
(SCTP, RTP/RTCP, RMCAT, etc.) than TCP (SCTP, RTP/RTCP, RMCAT, etc.)
(2) (1) (2) (1)
.-------^------. .--------------^-------------------. .-------^------. .--------------^-------------------.
,-(3)-----. ______ ,-(3)-----. ______
; ________ : L4S --------. | | ; ________ : L4S --------. | |
:|Scalable| : _\ ||___\_| mark | :|Scalable| : _\ ||___\_| mark |
:| sender | : __________ / / || / |______|\ _________ :| sender | : __________ / / || / |______|\ _________
:|________|\; | |/ --------' ^ \1| | :|________|\; | |/ --------' ^ \1| |
`---------'\_| IP-ECN | Coupling : \|priority |_\ `---------'\_| IP-ECN | Coupling : \|priority |_\
________ / |Classifier| : /|scheduler| / ________ / |Classifier| : /|scheduler| /
|Classic |/ |__________|\ --------. ___:__ / |_________| |Classic |/ |__________|\ --------. ___:__ / |_________|
skipping to change at page 7, line 8 skipping to change at page 7, line 8
Scalable Congestion Control: A congestion control where the packet Scalable Congestion Control: A congestion control where the packet
flow rate per round trip (the window) is inversely proportional to flow rate per round trip (the window) is inversely proportional to
the level (probability) of congestion signals. Then, as flow rate the level (probability) of congestion signals. Then, as flow rate
scales, the number of congestion signals per round trip remains scales, the number of congestion signals per round trip remains
invariant, maintaining the same degree of control. For instance, invariant, maintaining the same degree of control. For instance,
DCTCP averages 2 congestion signals per round-trip whatever the DCTCP averages 2 congestion signals per round-trip whatever the
flow rate. flow rate.
Classic Congestion Control: A congestion control with a flow rate Classic Congestion Control: A congestion control with a flow rate
compatible with standard TCP Reno [RFC5681]. With Classic that can co-exist with standard TCP Reno [RFC5681] without
congestion controls, as capacity increases enabling higher flow starvation. With Classic congestion controls, as capacity
rates, the number of round trips between congestion signals increases enabling higher flow rates, the number of round trips
(losses or ECN marks) rises in proportion to the flow rate. So between congestion signals (losses or ECN marks) rises in
control of queuing and/or utilization becomes very slack. For proportion to the flow rate. So control of queuing and/or
instance, with 1500 B packets and an RTT of 18 ms, as TCP Reno utilization becomes very slack. For instance, with 1500 B packets
flow rate increases from 2 to 100 Mb/s the number of round trips and an RTT of 18 ms, as TCP Reno flow rate increases from 2 to 100
between congestion signals rises proportionately, from 2 to 100. Mb/s the number of round trips between congestion signals rises
proportionately, from 2 to 100.
The default congestion control in Linux (TCP Cubic) is Reno- The default congestion control in Linux (TCP Cubic) is Reno-
compatible for most Internet access scenarios expected for some compatible for most Internet access scenarios expected for some
years. For instance, with a typical domestic round-trip time years. For instance, with a typical domestic round-trip time
(RTT) of 18ms, TCP Cubic only switches out of Reno-compatibility (RTT) of 18ms, TCP Cubic only switches out of Reno-compatibility
mode once the flow rate approaches 1 Gb/s. For a typical data mode once the flow rate approaches 1 Gb/s. For a typical data
centre RTT of 1 ms, the switch-over point is theoretically 1.3 Tb/ centre RTT of 1 ms, the switch-over point is theoretically 1.3 Tb/
s. However, with a less common transcontinental RTT of 100 ms, it s. However, with a less common transcontinental RTT of 100 ms, it
only remains Reno-compatible up to 13 Mb/s. All examples assume only remains Reno-compatible up to 13 Mb/s. All examples assume
1,500 B packets. 1,500 B packets.
skipping to change at page 7, line 50 skipping to change at page 7, line 51
Protocols:The L4S architecture encompasses the two protocol changes Protocols:The L4S architecture encompasses the two protocol changes
(an unassignment and an assignment) that we describe next: (an unassignment and an assignment) that we describe next:
a. An essential aspect of a scalable congestion control is the use a. An essential aspect of a scalable congestion control is the use
of explicit congestion signals rather than losses, because the of explicit congestion signals rather than losses, because the
signals need to be sent immediately and frequently--too often to signals need to be sent immediately and frequently--too often to
use drops. 'Classic' ECN [RFC3168] requires an ECN signal to be use drops. 'Classic' ECN [RFC3168] requires an ECN signal to be
treated the same as a drop, both when it is generated in the treated the same as a drop, both when it is generated in the
network and when it is responded to by hosts. L4S needs networks network and when it is responded to by hosts. L4S needs networks
and hosts to support two separate meanings for ECN. So the and hosts to support a different meaning for ECN. So the
standards track [RFC3168] needs to be updated to allow L4S standards track [RFC3168] needs to be updated to allow L4S
packets to depart from the 'same as drop' constraint. packets to depart from the 'same as drop' constraint.
[RFC8311] is a standards track update to relax specific [RFC8311] is a standards track update to relax specific
requirements in RFC 3168 (and certain other standards track requirements in RFC 3168 (and certain other standards track
RFCs), which clears the way for the experimental changes proposed RFCs), which clears the way for the experimental changes proposed
for L4S. [RFC8311] also reclassifies the original experimental for L4S. [RFC8311] also reclassifies the original experimental
assignment of the ECT(1) codepoint as an ECN nonce [RFC3540] as assignment of the ECT(1) codepoint as an ECN nonce [RFC3540] as
historic. historic.
skipping to change at page 8, line 31 skipping to change at page 8, line 31
'semi-permeable' membrane without specifying the particular AQMs to 'semi-permeable' membrane without specifying the particular AQMs to
use in the two queues. An informational appendix of the draft is use in the two queues. An informational appendix of the draft is
provided for pseudocode examples of different possible AQM provided for pseudocode examples of different possible AQM
approaches. Initially a zero-config variant of RED called Curvy RED approaches. Initially a zero-config variant of RED called Curvy RED
was implemented, tested and documented. The aim is for designers to was implemented, tested and documented. The aim is for designers to
be free to implement diverse ideas. So the brief normative body of be free to implement diverse ideas. So the brief normative body of
the draft only specifies the minimum constraints an AQM needs to the draft only specifies the minimum constraints an AQM needs to
comply with to ensure that the L4S and Classic services will coexist. comply with to ensure that the L4S and Classic services will coexist.
For instance, a variant of PIE called Dual PI Squared [PI2] has been For instance, a variant of PIE called Dual PI Squared [PI2] has been
implemented and found to perform better than Curvy RED over a wide implemented and found to perform better than Curvy RED over a wide
range of conditions, so it has been documented in a second appendix range of conditions, so it has been documented in another appendix of
of [I-D.ietf-tsvwg-aqm-dualq-coupled]. [I-D.ietf-tsvwg-aqm-dualq-coupled].
Host mechanisms: The L4S architecture includes a number of mechanisms Host mechanisms: The L4S architecture includes a number of mechanisms
in the end host that we enumerate next: in the end host that we enumerate next:
a. Data Centre TCP is the most widely used example of a scalable a. Data Centre TCP is the most widely used example of a scalable
congestion control. It has been documented as an informational congestion control. It has been documented as an informational
record of the protocol currently in use [RFC8257]. It will be record of the protocol currently in use [RFC8257]. It will be
necessary to define a number of safety features for a variant necessary to define a number of safety features for a variant
usable on the public Internet. A draft list of these, known as usable on the public Internet. A draft list of these, known as
the TCP Prague requirements, has been drawn up (see Appendix A of the TCP Prague requirements, has been drawn up (see Appendix A of
skipping to change at page 9, line 10 skipping to change at page 9, line 10
can use the L4S service, it will be necessary to implement can use the L4S service, it will be necessary to implement
scalable variants of each of these congestion control behaviours. scalable variants of each of these congestion control behaviours.
The following standards track RFCs currently define these The following standards track RFCs currently define these
protocols: ECN in TCP [RFC3168], in SCTP [RFC4960], in RTP protocols: ECN in TCP [RFC3168], in SCTP [RFC4960], in RTP
[RFC6679], and in DCCP [RFC4340]. Not all are in widespread use, [RFC6679], and in DCCP [RFC4340]. Not all are in widespread use,
but those that are will eventually need to be updated to allow a but those that are will eventually need to be updated to allow a
different congestion response, which they will have to indicate different congestion response, which they will have to indicate
by using the ECT(1) codepoint. Scalable variants are under by using the ECT(1) codepoint. Scalable variants are under
consideration for some new transport protocols that are consideration for some new transport protocols that are
themselves under development, e.g. QUIC [I-D.johansson-quic-ecn] themselves under development, e.g. QUIC
and certain real-time media congestion avoidance techniques [I-D.ietf-quic-transport] and certain real-time media congestion
(RMCAT) protocols. avoidance techniques (RMCAT) protocols.
c. ECN feedback is sufficient for L4S in some transport protocols c. ECN feedback is sufficient for L4S in some transport protocols
(RTCP, DCCP) but not others: (RTCP, DCCP) but not others:
* 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 that an ECN mark is the same as a assumption from Classic ECN that an ECN mark is the same as a
drop, making it unusable for a scalable TCP. Therefore, the drop, making it unusable for a scalable TCP. Therefore, the
implementation of TCP receivers will have to be upgraded implementation of TCP receivers will have to be upgraded
[RFC7560]. Work to standardize more accurate ECN feedback for [RFC7560]. Work to standardize more accurate ECN feedback for
TCP (AccECN [I-D.ietf-tcpm-accurate-ecn]) is in progress. TCP (AccECN [I-D.ietf-tcpm-accurate-ecn]) is in progress.
skipping to change at page 9, line 42 skipping to change at page 9, line 42
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
drop as a congestion signal creates a tension because drop is both drop as a congestion signal creates a tension because drop is both
a useful signal (more would reduce delay) and an impairment (less a useful signal (more would reduce delay) and an impairment (less
would reduce delay). Explicit congestion signals can be used many would reduce delay). Explicit congestion signals can be used many
times per round trip, to keep tight control, without any times per round trip, to keep tight control, without any
impairment. Under heavy load, even more explicit signals can be impairment. Under heavy load, even more explicit signals can be
applied so the queue can be kept short whatever the load. Whereas applied so the queue can be kept short whatever the load. Whereas
state-of-the-art AQMs have to introduce very high packet drop at state-of-the-art AQMs have to introduce very high packet drop at
high load to keep the queue short. Further, when using ECN TCP's high load to keep the queue short. Further, when using ECN, TCP's
sawtooth reduction can be smaller, and therefore return to the sawtooth reduction can be smaller and therefore return to the
operating point more often, without worrying that this causes more operating point more often, without worrying that this causes more
signals (one at the top of each smaller sawtooth). The consequent signals (one at the top of each smaller sawtooth). The consequent
smaller amplitude sawteeth fit between a very shallow marking smaller amplitude sawteeth fit between a very shallow marking
threshold and an empty queue, so delay variation can be very low, threshold and an empty queue, so delay variation can be very low,
without risk of under-utilization. without risk of under-utilization.
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 'the same as' drop (as required with Classic ECN considered 'the same as' drop (as required with Classic ECN
skipping to change at page 12, line 45 skipping to change at page 12, line 45
strictly, so that senders can still control the instantaneous strictly, so that senders can still control the instantaneous
rate of each flow dependent on the needs of each application rate of each flow dependent on the needs of each application
(e.g. variable rate video), giving more wriggle-room before a (e.g. variable rate video), giving more wriggle-room before a
flow is deemed non-compliant. Also policing of queuing and of flow is deemed non-compliant. Also policing of queuing and of
flow-rates can be applied independently. flow-rates can be applied independently.
Alternative Back-off ECN (ABE): Yet again, L4S is not an alternative Alternative Back-off ECN (ABE): Yet again, L4S is not an alternative
to ABE but a complement that introduces much lower queuing delay. to ABE but a complement that introduces much lower queuing delay.
ABE [I-D.ietf-tcpm-alternativebackoff-ecn] alters the host ABE [I-D.ietf-tcpm-alternativebackoff-ecn] alters the host
behaviour in response to ECN marking to utilize a link better and behaviour in response to ECN marking to utilize a link better and
give ECN flows a faster throughput, but it assumes the network give ECN flows faster throughput, but it assumes the network still
still treats ECN and drop the same. Therefore ABE exploits any treats ECN and drop the same. Therefore ABE exploits any lower
lower queuing delay that AQMs can provide. But as explained queuing delay that AQMs can provide. But as explained above, AQMs
above, AQMs still cannot reduce queuing delay too far without still cannot reduce queuing delay too far without losing link
losing link utilization (to allow for other, non-ABE, flows). utilization (to allow for other, non-ABE, flows).
6. Applicability 6. Applicability
6.1. Applications 6.1. Applications
A transport layer that solves the current latency issues will provide A transport layer that solves the current latency issues will provide
new service, product and application opportunities. new service, product and application opportunities.
With the L4S approach, the following existing applications will With the L4S approach, the following existing applications will
immediately experience significantly better quality of experience immediately experience significantly better quality of experience
skipping to change at page 16, line 25 skipping to change at page 16, line 25
before L4S will work for anyone. Operators of public Internet access before L4S will work for anyone. Operators of public Internet access
networks typically design their networks so that the bottleneck will networks typically design their networks so that the bottleneck will
nearly always occur at one known (logical) link. This confines the nearly always occur at one known (logical) link. This confines the
cost of queue management technology to one place. cost of queue management technology to one place.
The case of mesh networks is different and will be discussed later. The case of mesh networks is different and will be discussed later.
But the known bottleneck case is generally true for Internet access But the known bottleneck case is generally true for Internet access
to all sorts of different 'sites', where the word 'site' includes to all sorts of different 'sites', where the word 'site' includes
home networks, small-to-medium sized campus or enterprise networks home networks, small-to-medium sized campus or enterprise networks
and even cellular devices (Figure 2). Also, this known-bottleneck and even cellular devices (Figure 2). Also, this known-bottleneck
case tends to be true whatever the access link technology; whether case tends to be applicable whatever the access link technology;
xDSL, cable, cellular, line-of-sight wireless or satellite. whether xDSL, cable, cellular, line-of-sight wireless or satellite.
Therefore, the full benefit of the L4S service should be available in Therefore, the full benefit of the L4S service should be available in
the downstream direction when the DualQ AQM is deployed at the the downstream direction when the DualQ AQM is deployed at the
ingress to this bottleneck link (or links for multihomed sites). And ingress to this bottleneck link (or links for multihomed sites). And
similarly, the full upstream service will be available once the DualQ similarly, the full upstream service will be available once the DualQ
is deployed at the upstream ingress. is deployed at the upstream ingress.
______ ______
( ) ( )
__ __ ( ) __ __ ( )
skipping to change at page 17, line 29 skipping to change at page 17, line 29
| o | | o |
`---' `---'
Figure 2: Likely location of DualQ (DQ) Deployments in common access Figure 2: Likely location of DualQ (DQ) Deployments in common access
topologies topologies
Deployment in mesh topologies depends on how over-booked the core is. Deployment in mesh topologies depends on how over-booked the core is.
If the core is non-blocking, or at least generously provisioned so If the core is non-blocking, or at least generously provisioned so
that the edges are nearly always the bottlenecks, it would only be that the edges are nearly always the bottlenecks, it would only be
necessary to deploy the DualQ AQM at the edge bottlenecks. For necessary to deploy the DualQ AQM at the edge bottlenecks. For
example, some datacentre networks are designed with the bottleneck in example, some data-centre networks are designed with the bottleneck
the hypervisor or host NICs, while others bottleneck at the top-of- in the hypervisor or host NICs, while others bottleneck at the top-
rack switch (both the output ports facing hosts and those facing the of-rack switch (both the output ports facing hosts and those facing
core). the core).
The DualQ would eventually also need to be deployed at any other The DualQ would eventually also need to be deployed at any other
persistent bottlenecks such as network interconnections, e.g. some persistent bottlenecks such as network interconnections, e.g. some
public Internet exchange points and the ingress and egress to WAN public Internet exchange points and the ingress and egress to WAN
links interconnecting datacentres. links interconnecting data-centres.
6.3.2. Deployment Sequences 6.3.2. Deployment Sequences
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 faced deployed. This was the same deployment problem that ECN faced
[RFC8170] so we have learned from this. [RFC8170] so we have learned from this.
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 DualQ AQM at a network bottleneck clients. Therefore, just deploying DualQ AQM at a network bottleneck
skipping to change at page 18, line 15 skipping to change at page 18, line 15
controlled deployments or controlled trials. controlled deployments or 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 intially 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 link packet header or some status of a customer or their access link
[I-D.ietf-tsvwg-ecn-l4s-id]. Operators could do this anyway, even if [I-D.ietf-tsvwg-ecn-l4s-id]. Operators could do this anyway, even if
it were not blessed by the IETF. However, it is best for the IETF to it were not blessed by the IETF. However, it is best for the IETF to
specify that they must use their own local identifier in combination specify that they must use their own local identifier in combination
with the IETF's identifier. Then, if an operator enables the with the IETF's identifier. Then, if an operator enables the
skipping to change at page 19, line 27 skipping to change at page 19, line 27
one end will provide all the benefit needed. Accurate ECN one end will provide all the benefit needed. Accurate ECN
feedback (AccECN) [I-D.ietf-tcpm-accurate-ecn] is needed at the feedback (AccECN) [I-D.ietf-tcpm-accurate-ecn] is needed at the
other end, but it is a generic ECN feedback facility that is other end, but it is a generic ECN feedback facility that is
already planned to be deployed for other purposes, e.g. DCTCP, already planned to be deployed for other purposes, e.g. DCTCP,
BBR [BBR]. The two ends can be deployed in either order, because BBR [BBR]. The two ends can be deployed in either order, because
TCP Prague only enables itself if it has negotiated the use of TCP Prague only enables itself if it has negotiated the use of
AccECN feedback with the other end during the connection AccECN feedback with the other end during the connection
handshake. Thus, deployment of TCP Prague on a server enables handshake. Thus, deployment of TCP Prague on a server enables
L4S trials to move to a production service in one direction, L4S trials to move to a production service in one direction,
wherever AccECN is deployed at the other end. This stage might wherever AccECN is deployed at the other end. This stage might
be further motivated by performance improvements between DCTCP be further motivated by the performance improvements of TCP
and TCP Prague (see Appendix A.2 of [I-D.ietf-tsvwg-ecn-l4s-id]). Prague relative to DCTCP (see Appendix A.2 of
[I-D.ietf-tsvwg-ecn-l4s-id]).
3. This is a two-move stage to enable L4S upstream. The DualQ or 3. This is a two-move stage to enable L4S upstream. The DualQ or
TCP Prague can be deployed in either order as already explained. TCP Prague can be deployed in either order as already explained.
To motivate the first of two independent moves, the deferred To motivate the first of two independent moves, the deferred
benefit of enabling new services after the second move has to be benefit of enabling new services after the second move has to be
worth it to cover the first mover's investment risk. As worth it to cover the first mover's investment risk. As
explained already, the potential for new interactive services explained already, the potential for new interactive services
provides this motivation. The DualQ AQM also greatly improves provides this motivation. The DualQ AQM also greatly improves
the upstream Classic service, assuming no other AQM has already the upstream Classic service, assuming no other AQM has already
been deployed. been deployed.
skipping to change at page 20, line 27 skipping to change at page 20, line 27
Three complementary approaches are in progress to address this issue, Three complementary approaches are in progress to address this issue,
but they are all currently research: but they are all currently research:
o In TCP Prague, ignore certain losses deemed unlikely to be due to o In TCP Prague, ignore certain losses deemed unlikely to be due to
congestion (using some ideas from BBR [BBR] but with no need to congestion (using some ideas from BBR [BBR] but with no need to
ignore nearly all losses). This could mask any of the above types ignore nearly all losses). This could mask any of the above types
of loss (requires consensus on how to safely interoperate with of loss (requires consensus on how to safely interoperate with
drop-based congestion controls). drop-based congestion controls).
o A combination of RACK, reconfigured link retransmission and L4S o A combination of RACK, reconfigured link retransmission and L4S
could address transmission errors (no reference yet); could address transmission errors [I-D.ietf-tsvwg-ecn-l4s-id];
o Hybrid ECN/drop policers (see Section 8.3). o Hybrid ECN/drop policers (see Section 8.3).
L4S deployment scenarios that minimize these issues (e.g. over L4S deployment scenarios that minimize these issues (e.g. over
wireline networks) can proceed in parallel to this research, in the wireline networks) can proceed in parallel to this research, in the
expectation that research success will continually widen L4S expectation that research success will continually widen L4S
applicability. applicability.
Classic ECN support is starting to materialize (in the upstream of Classic ECN support is starting to materialize (in the upstream of
some home routers as of early 2017), so an L4S sender will have to some home routers as of early 2017), so an L4S sender will have to
skipping to change at page 21, line 47 skipping to change at page 21, line 47
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. Allowing operators to non-premium customers) into the Classic queue. Allowing operators to
use an additional local classifier is intended to remove any use an additional local classifier is intended to remove any
incentive to bleach the L4S identifier. Then at least the L4S ECN incentive to bleach 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
service may not be supported at every hop. Such arrangements would service may not be supported at every hop. Such arrangements would
only require simple registered/not-registered packet classification, only require simple registered/not-registered packet classification,
rather than the managed application-specific traffic policing against rather than the managed, application-specific traffic policing
customer-specific traffic contracts that Diffserv requires. against customer-specific traffic contracts that Diffserv requires.
8.2. 'Latency Friendliness' 8.2. 'Latency Friendliness'
The L4S service does rely on self-constraint - not in terms of The L4S service does rely on self-constraint - not in terms of
limiting rate, but in terms of limiting latency. It is hoped that limiting rate, but in terms of limiting latency (burstiness). It is
standardisation of dynamic behaviour (cf. TCP slow-start) and self- hoped that standardisation of dynamic behaviour (cf. TCP slow-start)
interest will be sufficient to prevent transports from sending and self-interest will be sufficient to prevent transports from
excessive bursts of L4S traffic, given the application's own latency sending excessive bursts of L4S traffic, given the application's own
will suffer most from such behaviour. latency will suffer most from such behaviour.
Whether burst policing becomes necessary remains to be seen. Without Whether burst policing becomes necessary remains to be seen. Without
it, there will be potential for attacks on the low latency of the L4S it, there will be potential for attacks on the low latency of the L4S
service. However it may only be necessary to apply such policing service. However it may only be necessary to apply such policing
reactively, e.g. punitively targeted at any deployments of new bursty reactively, e.g. punitively targeted at any deployments of new bursty
malware. malware.
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
skipping to change at page 23, line 21 skipping to change at page 23, line 21
Receiving hosts can fool a sender into downloading faster by Receiving hosts can fool a sender into downloading faster by
suppressing feedback of ECN marks (or of losses if retransmissions suppressing feedback of ECN marks (or of losses if retransmissions
are not necessary or available otherwise). Various ways to protect are not necessary or available otherwise). Various ways to protect
TCP feedback integrity have been developed. For instance: TCP feedback integrity have been developed. For instance:
o The sender can test the integrity of the receiver's feedback by o The sender can test the integrity of the receiver's feedback by
occasionally setting the IP-ECN field to the congestion occasionally setting the IP-ECN field to the congestion
experienced (CE) codepoint, which is normally only set by a experienced (CE) codepoint, which is normally only set by a
congested link. Then the sender can test whether the receiver's congested link. Then the sender can test whether the receiver's
feedback faithfully reports what it expects (see 2nd para of feedback faithfully reports what it expects (see 2nd para of
[RFC3168]). Section 20.2 of [RFC3168]).
o A network can enforce a congestion response to its ECN markings o A network can enforce a congestion response to its ECN markings
(or packet losses) by auditing congestion exposure (ConEx) (or packet losses) by auditing congestion exposure (ConEx)
[RFC7713]. [RFC7713].
o The TCP authentication option (TCP-AO [RFC5925]) can be used to o The TCP authentication option (TCP-AO [RFC5925]) can be used to
detect tampering with TCP congestion feedback. detect tampering with TCP congestion feedback.
o The ECN Nonce [RFC3540] was proposed to detect tampering with o The ECN Nonce [RFC3540] was proposed to detect tampering with
congestion feedback, but it has been reclassified as historic congestion feedback, but it has been reclassified as historic
skipping to change at page 24, line 42 skipping to change at page 24, line 42
2014. 2014.
[I-D.briscoe-conex-policing] [I-D.briscoe-conex-policing]
Briscoe, B., "Network Performance Isolation using Briscoe, B., "Network Performance Isolation using
Congestion Policing", draft-briscoe-conex-policing-01 Congestion Policing", draft-briscoe-conex-policing-01
(work in progress), February 2014. (work in progress), February 2014.
[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-00 (work in progress), draft-briscoe-tsvwg-l4s-diffserv-01 (work in progress),
March 2018. July 2018.
[I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-15 (work
in progress), October 2018.
[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-06 (work in progress), March 2018. ecn-07 (work in progress), July 2018.
[I-D.ietf-tcpm-alternativebackoff-ecn] [I-D.ietf-tcpm-alternativebackoff-ecn]
Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
"TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm- "TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm-
alternativebackoff-ecn-07 (work in progress), March 2018. alternativebackoff-ecn-12 (work in progress), September
2018.
[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-02 (work in progress), draft-ietf-tcpm-generalized-ecn-03 (work in progress),
October 2017. October 2018.
[I-D.ietf-tsvwg-aqm-dualq-coupled] [I-D.ietf-tsvwg-aqm-dualq-coupled]
Schepper, K., Briscoe, B., Bondarenko, O., and I. Tsang, Schepper, K., Briscoe, B., Bondarenko, O., and I. Tsang,
"DualQ Coupled AQMs for Low Latency, Low Loss and Scalable "DualQ Coupled AQMs for Low Latency, Low Loss and Scalable
Throughput (L4S)", draft-ietf-tsvwg-aqm-dualq-coupled-04 Throughput (L4S)", draft-ietf-tsvwg-aqm-dualq-coupled-06
(work in progress), March 2018. (work in progress), July 2018.
[I-D.ietf-tsvwg-ecn-encap-guidelines] [I-D.ietf-tsvwg-ecn-encap-guidelines]
Briscoe, B., Kaippallimalil, J., and P. Thaler, Briscoe, B., Kaippallimalil, J., and P. Thaler,
"Guidelines for Adding Congestion Notification to "Guidelines for Adding Congestion Notification to
Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn-
encap-guidelines-10 (work in progress), March 2018. encap-guidelines-10 (work in progress), March 2018.
[I-D.ietf-tsvwg-ecn-l4s-id] [I-D.ietf-tsvwg-ecn-l4s-id]
Schepper, K. and B. Briscoe, "Identifying Modified Schepper, K. and B. Briscoe, "Identifying Modified
Explicit Congestion Notification (ECN) Semantics for Explicit Congestion Notification (ECN) Semantics for
Ultra-Low Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s- Ultra-Low Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s-
id-02 (work in progress), March 2018. id-03 (work in progress), July 2018.
[I-D.johansson-quic-ecn]
Johansson, I., "ECN support in QUIC", draft-johansson-
quic-ecn-03 (work in progress), May 2017.
[I-D.smith-encrypted-traffic-management] [I-D.smith-encrypted-traffic-management]
Smith, K., "Network management of encrypted traffic", Smith, K., "Network management of encrypted traffic",
draft-smith-encrypted-traffic-management-05 (work in draft-smith-encrypted-traffic-management-05 (work in
progress), May 2016. progress), May 2016.
[I-D.stewart-tsvwg-sctpecn] [I-D.stewart-tsvwg-sctpecn]
Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream Stewart, 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.
 End of changes. 27 change blocks. 
73 lines changed or deleted 77 lines changed or added

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