draft-ietf-tsvwg-l4s-arch-01.txt   draft-ietf-tsvwg-l4s-arch-02.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: May 3, 2018 Nokia Bell Labs Expires: September 23, 2018 Nokia Bell Labs
M. Bagnulo Braun M. Bagnulo Braun
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
October 30, 2017 March 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-01 draft-ietf-tsvwg-l4s-arch-02
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 May 3, 2018. This Internet-Draft will expire on September 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. L4S Architecture Overview . . . . . . . . . . . . . . . . . . 4 2. L4S Architecture Overview . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. L4S Architecture Components . . . . . . . . . . . . . . . . . 7 4. L4S Architecture Components . . . . . . . . . . . . . . . . . 7
5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Why These Primary Components? . . . . . . . . . . . . . . 9 5.1. Why These Primary Components? . . . . . . . . . . . . . . 9
5.2. Why Not Alternative Approaches? . . . . . . . . . . . . . 11 5.2. Why Not Alternative Approaches? . . . . . . . . . . . . . 10
6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Applications . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Applications . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 14
6.3. Deployment Considerations . . . . . . . . . . . . . . . . 15 6.3. Deployment Considerations . . . . . . . . . . . . . . . . 15
6.3.1. Deployment Topology . . . . . . . . . . . . . . . . . 16 6.3.1. Deployment Topology . . . . . . . . . . . . . . . . . 16
6.3.2. Deployment Sequences . . . . . . . . . . . . . . . . 17 6.3.2. Deployment Sequences . . . . . . . . . . . . . . . . 17
6.3.3. L4S Flow but Non-L4S Bottleneck . . . . . . . . . . . 19 6.3.3. L4S Flow but Non-L4S Bottleneck . . . . . . . . . . . 19
6.3.4. Other Potential Deployment Issues . . . . . . . . . . 20 6.3.4. Other Potential Deployment Issues . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8.1. Traffic (Non-)Policing . . . . . . . . . . . . . . . . . 21 8.1. Traffic (Non-)Policing . . . . . . . . . . . . . . . . . 21
8.2. 'Latency Friendliness' . . . . . . . . . . . . . . . . . 22 8.2. 'Latency Friendliness' . . . . . . . . . . . . . . . . . 22
8.3. Policing Prioritized L4S Bandwidth . . . . . . . . . . . 22 8.3. Interaction between Rate Policing and L4S . . . . . . . . 22
8.4. ECN Integrity . . . . . . . . . . . . . . . . . . . . . . 23 8.4. ECN Integrity . . . . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Standardization items . . . . . . . . . . . . . . . 28 Appendix A. Standardization items . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
It is increasingly common for _all_ of a user's applications at any It is increasingly common for _all_ of a user's applications at any
one time to require low delay: interactive Web, Web services, voice, one time to require low delay: interactive Web, Web services, voice,
conversational video, interactive video, interactive remote presence, conversational video, interactive video, interactive remote presence,
instant messaging, online gaming, remote desktop, cloud-based instant messaging, online gaming, remote desktop, cloud-based
applications and video-assisted remote control of machinery and applications and video-assisted remote control of machinery and
industrial processes. In the last decade or so, much has been done industrial processes. In the last decade or so, much has been done
to reduce propagation delay by placing caches or servers closer to to reduce propagation delay by placing caches or servers closer to
skipping to change at page 3, line 40 skipping to change at page 3, line 40
state-of-the-art active queue management (AQM), the base speed-of- state-of-the-art active queue management (AQM), the base speed-of-
light path delay roughly doubles. Low loss is also important light path delay roughly doubles. Low loss is also important
because, for interactive applications, losses translate into even because, for interactive applications, losses translate into even
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
[RFC3246] for some packets at the expense of others, but this is not [RFC3246] for some packets at the expense of others, but this is not
applicable when all (or most) of a user's applications require low sufficient when all (or most) of a user's applications require low
latency. latency.
Therefore, the goal is an Internet service with ultra-Low queueing Therefore, the goal is an Internet service with ultra-Low queueing
Latency, ultra-Low Loss and Scalable throughput (L4S) - for _all_ Latency, ultra-Low Loss and Scalable throughput (L4S) - for _all_
traffic. A service for all traffic will need none of the traffic. A service for all traffic will need none of the
configuration or management baggage (traffic policing, traffic configuration or management baggage (traffic policing, traffic
contracts) associated with favouring some packets over others. This contracts) associated with favouring some packets over others. This
document describes the L4S architecture for achieving that goal. document describes the L4S architecture for achieving that goal.
It must be said that queuing delay only degrades performance It must be said that queuing delay only degrades performance
skipping to change at page 4, line 18 skipping to change at page 4, line 18
performance improvement from L4S must be so remarkable that network performance improvement from L4S must be so remarkable that network
operators will be motivated to deploy it. operators will be motivated to deploy it.
Active Queue Management (AQM) is part of the solution to queuing Active Queue Management (AQM) is part of the solution to queuing
under load. AQM improves performance for all traffic, but there is a under load. AQM improves performance for all traffic, but there is a
limit to how much queuing delay can be reduced by solely changing the limit to how much queuing delay can be reduced by solely changing the
network; without addressing the root of the problem. network; without addressing the root of the problem.
The root of the problem is the presence of standard TCP congestion The root of the problem is the presence of standard TCP congestion
control (Reno [RFC5681]) or compatible variants (e.g. TCP Cubic control (Reno [RFC5681]) or compatible variants (e.g. TCP Cubic
[I-D.ietf-tcpm-cubic]). We shall call this family of congestion [RFC8312]). We shall call this family of congestion controls
controls 'Classic' TCP. It has been demonstrated that if the sending 'Classic' TCP. It has been demonstrated that if the sending host
host replaces Classic TCP with a 'Scalable' alternative, when a replaces Classic TCP with a 'Scalable' alternative, when a suitable
suitable AQM is deployed in the network the performance under load of AQM is deployed in the network the performance under load of all the
all the above interactive applications can be stunningly improved. above interactive applications can be stunningly improved. For
For instance, queuing delay under heavy load with the example DCTCP/ instance, queuing delay under heavy load with the example DCTCP/DualQ
DualQ solution cited below is roughly 1 millisecond (1 ms) at the solution cited below is roughly 1 millisecond (1 ms) at the 99th
99th percentile without losing link utilization. This compares with percentile without losing link utilization. This compares with 5 to
5 to 20 ms on _average_ with a Classic TCP and current state-of-the- 20 ms on _average_ with a Classic TCP and current state-of-the-art
art AQMs such as fq_CoDel [I-D.ietf-aqm-fq-codel] or PIE [RFC8033]. AQMs such as fq_CoDel [RFC8290] or PIE [RFC8033]. Also, with a
Also, with a Classic TCP, 5 ms of queuing is usually only possible by Classic TCP, 5 ms of queuing is usually only possible by losing some
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 node
should give nearly all the benefit. The L4S approach requires should give nearly all the benefit. The L4S approach requires
component mechanisms in different parts of an Internet path to component mechanisms in different parts of an Internet path to
fulfill its goal. This document presents the L4S architecture, by fulfill its goal. This document presents the L4S architecture, by
skipping to change at page 5, line 10 skipping to change at page 5, line 10
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
might use each service and capacity in access networks is too might use each service and capacity in access networks is too
scarce to partition into two. So a 'semi-permeable' membrane is scarce to partition into two. So a 'semi-permeable' membrane is
needed that partitions latency but not bandwidth. The Dual Queue needed that partitions latency but not bandwidth. The Dual Queue
Coupled AQM [I-D.ietf-tsvwg-aqm-dualq-coupled] is an example of Coupled AQM [I-D.ietf-tsvwg-aqm-dualq-coupled] is an example of
such a semi-permeable membrane. such a semi-permeable membrane.
Per-flow queuing such as in [I-D.ietf-aqm-fq-codel] could be used, Per-flow queuing such as in [RFC8290] could be used, but it
but it partitions both latency and bandwidth between every end-to- partitions both latency and bandwidth between every end-to-end
end flow. So it is rather overkill, which brings disadvantages flow. So it is rather overkill, which brings disadvantages (see
(see Section 5.2), not least that thousands of queues are needed Section 5.2), not least that thousands of queues are needed when
when 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 first pointed out in [RFC3649]. The one
skipping to change at page 8, line 7 skipping to change at page 8, line 7
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 two separate meanings 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.
[I-D.ietf-tsvwg-ecn-experimentation] has been prepared as a [RFC8311] is a standards track update to relax specific
standards track update to relax specific requirements in RFC 3168 requirements in RFC 3168 (and certain other standards track
(and certain other standards track RFCs), which clears the way RFCs), which clears the way for the experimental changes proposed
for the experimental changes proposed for L4S. for L4S. [RFC8311] also reclassifies the original experimental
[I-D.ietf-tsvwg-ecn-experimentation] also explains why the assignment of the ECT(1) codepoint as an ECN nonce [RFC3540] as
original experimental assignment of the ECT(1) codepoint as an historic.
ECN nonce [RFC3540] is being reclassified as historic (it was
never deployed, and it offers no security benefit now that
deployment is optional).
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].
Network components:The Dual Queue Coupled AQM has been specified as Network components:The Dual Queue Coupled AQM has been specified as
generically as possible [I-D.ietf-tsvwg-aqm-dualq-coupled] as a generically as possible [I-D.ietf-tsvwg-aqm-dualq-coupled] as a
'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
skipping to change at page 11, line 17 skipping to change at page 11, line 11
All the following approaches address some part of the same problem All the following approaches address some part of the same problem
space as L4S. In each case, it is shown that L4S complements them or space as L4S. In each case, it is shown that L4S complements them or
improves on them, rather than being a mutually exclusive alternative: improves on them, rather than being a mutually exclusive alternative:
Diffserv: Diffserv addresses the problem of bandwidth apportionment Diffserv: Diffserv addresses the problem of bandwidth apportionment
for important traffic as well as queuing latency for delay- for important traffic as well as queuing latency for delay-
sensitive traffic. L4S solely addresses the problem of queuing sensitive traffic. L4S solely addresses the problem of queuing
latency (as well as loss and throughput scaling). Diffserv will latency (as well as loss and throughput scaling). Diffserv will
still be necessary where important traffic requires priority (e.g. still be necessary where important traffic requires priority (e.g.
for commercial reasons, or for protection of critical for commercial reasons, or for protection of critical
infrastructure traffic). Nonetheless, if there are Diffserv infrastructure traffic) - see [I-D.briscoe-tsvwg-l4s-diffserv].
classes for important traffic, the L4S approach can provide low Nonetheless, if there are Diffserv classes for important traffic,
latency for _all_ traffic within each Diffserv class (including the L4S approach can provide low latency for _all_ traffic within
the case where there is only one Diffserv class). each Diffserv class (including the case where there is only one
Diffserv class).
Also, as already explained, Diffserv only works for a small subset Also, as already explained, Diffserv only works for a small subset
of the traffic on a link. It is not applicable when all the of the traffic on a link. It is not applicable when all the
applications in use at one time at a single site (home, small applications in use at one time at a single site (home, small
business or mobile device) require low latency. Also, because L4S business or mobile device) require low latency. Also, because L4S
is for all traffic, it needs none of the management baggage is for all traffic, it needs none of the management baggage
(traffic policing, traffic contracts) associated with favouring (traffic policing, traffic contracts) associated with favouring
some packets over others. This baggage has held Diffserv back some packets over others. This baggage has held Diffserv back
from widespread end-to-end deployment. from widespread end-to-end deployment.
skipping to change at page 15, line 33 skipping to change at page 15, line 29
o Different types of transport (or application) congestion control: o Different types of transport (or application) congestion control:
* elastic (TCP/SCTP); * elastic (TCP/SCTP);
* real-time (RTP, RMCAT); * real-time (RTP, RMCAT);
* query (DNS/LDAP). * query (DNS/LDAP).
o Where low delay quality of service is required, but without o Where low delay quality of service is required, but without
inspecting or intervening above the IP layer inspecting or intervening above the IP layer
[I-D.you-encrypted-traffic-management]: [I-D.smith-encrypted-traffic-management]:
* mobile and other networks have tended to inspect higher layers * mobile and other networks have tended to inspect higher layers
in order to guess application QoS requirements. However, with in order to guess application QoS requirements. However, with
growing demand for support of privacy and encryption, L4S growing demand for support of privacy and encryption, L4S
offers an alternative. There is no need to select which offers an alternative. There is no need to select which
traffic to favour for queuing, when L4S gives favourable traffic to favour for queuing, when L4S gives favourable
queuing to all traffic. queuing to all traffic.
o If queuing delay is minimized, applications with a fixed delay o If queuing delay is minimized, applications with a fixed delay
budget can communicate over longer distances, or via a longer budget can communicate over longer distances, or via a longer
skipping to change at page 17, line 43 skipping to change at page 17, line 43
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 datacentres.
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
[I-D.iab-protocol-transitions] 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
immediately gives a working deployment of all the L4S parts. DCTCP immediately gives a working deployment of all the L4S parts. DCTCP
needs some safety concerns to be fixed for general use over the needs some safety concerns to be fixed for general use over the
public Internet (see Section 2.3 of [I-D.ietf-tsvwg-ecn-l4s-id]), but public Internet (see Section 2.3 of [I-D.ietf-tsvwg-ecn-l4s-id]), but
DCTCP is not on by default, so these issues can be managed within DCTCP is not on by default, so these issues can be managed within
controlled deployments or controlled trials. controlled deployments or controlled trials.
skipping to change at page 22, line 20 skipping to change at page 22, line 20
interest will be sufficient to prevent transports from sending interest 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
will suffer most from such behaviour. 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. Policing Prioritized L4S Bandwidth 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. Then, within such Diffserv classes, L4S would often be applicable. Then, within such Diffserv classes, L4S would often be
applicable to give traffic low latency and low loss. Within such a applicable to give traffic low latency and low loss as well. Within
class, the bandwidth available to a user or application is often such a Diffserv class, the bandwidth available to a user or
limited by a rate policer. Similarly, in the default Diffserv class, application is often limited by a rate policer. Similarly, in the
rate policers are used to partition shared capacity. default Diffserv class, rate policers are used to partition shared
capacity.
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 may be dropped elsewhere during contention). In codepoint, so they may be dropped elsewhere during contention).
networks that deploy L4S and use rate policers, it will be preferable Whenever L4S traffic encounters one of these rate policers, it will
to deploy a policer designed to be more friendly to the L4S service, experience drops and the source has to fall back to a Classic
congestion control, thus losing the benefits of L4S. 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 friendly to the
L4S service.
This is currently a research area. It might be achieved by setting a This is currently a research area. It might be achieved by setting a
threshold where ECN marking is introduced, such that it is just under threshold where ECN marking is introduced, such that it is just under
the policed rate or just under the burst allowance where drop is the policed rate or just under the burst allowance where drop is
introduced. This could be applied to various types of policer, e.g. introduced. This could be applied to various types of policer, e.g.
[RFC2697], [RFC2698] or the 'local' (non-ConEx) variant of the ConEx [RFC2697], [RFC2698] or the 'local' (non-ConEx) variant of the ConEx
congestion policer [I-D.briscoe-conex-policing]. Otherwise, whenever congestion policer [I-D.briscoe-conex-policing]. It might also be
L4S traffic encounters a rate policer, it will experience drops and possible to design scalable congestion controls to respond less
the source will fall back to a Classic congestion control, thus catastrophically to loss that has not been preceded by a period of
losing the benefits of L4S. increasing delay.
Further discussion of the applicability of L4S to the various The design of L4S-friendly rate policers will require a separate
Diffserv classes, and the design of suitable L4S rate policers will dedicated document. For further discussion of the interaction
require a separate dedicated document. between L4S and Diffserv, see [I-D.briscoe-tsvwg-l4s-diffserv].
8.4. ECN Integrity 8.4. ECN Integrity
Receiving hosts can fool a sender into downloading faster by Receiving hosts can fool a sender into downloading faster by
suppressing feedback of ECN marks (or of losses if retransmissions suppressing feedback of ECN marks (or of losses if retransmissions
are not necessary or available otherwise). Various ways to protect are not necessary or available otherwise). Various ways to protect
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 feedback faithfully reports what it expects (see 2nd para of
[I-D.moncaster-tcpm-rcv-cheat]. [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 is being reclassified as historic. congestion feedback, but it has been reclassified as historic
[RFC8311].
Appendix C.1 of [I-D.ietf-tsvwg-ecn-l4s-id] gives more details of Appendix C.1 of [I-D.ietf-tsvwg-ecn-l4s-id] gives more details of
these techniques including their applicability and pros and cons. these techniques including their applicability and pros and cons.
9. Acknowledgements 9. Acknowledgements
Thanks to Wes Eddy, Karen Nielsen and David Black for their useful Thanks to Wes Eddy, Karen Nielsen and David Black for their useful
review comments. review comments.
Bob Briscoe and Koen De Schepper were part-funded by the European Bob Briscoe and Koen De Schepper were part-funded by the European
skipping to change at page 24, line 30 skipping to change at page 24, line 39
Hohlfeld , O., Pujol, E., Ciucu, F., Feldmann, A., and P. Hohlfeld , O., Pujol, E., Ciucu, F., Feldmann, A., and P.
Barford, "A QoE Perspective on Sizing Network Buffers", Barford, "A QoE Perspective on Sizing Network Buffers",
Proc. ACM Internet Measurement Conf (IMC'14) hmm, November Proc. ACM Internet Measurement Conf (IMC'14) hmm, November
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.iab-protocol-transitions] [I-D.briscoe-tsvwg-l4s-diffserv]
Thaler, D., "Planning for Protocol Adoption and Subsequent Briscoe, B., "Interactions between Low Latency, Low Loss,
Transitions", draft-iab-protocol-transitions-08 (work in Scalable Throughput (L4S) and Differentiated Services",
progress), March 2017. draft-briscoe-tsvwg-l4s-diffserv-00 (work in progress),
March 2018.
[I-D.ietf-aqm-fq-codel]
Hoeiland-Joergensen, T., McKenney, P.,
dave.taht@gmail.com, d., Gettys, J., and E. Dumazet, "The
FlowQueue-CoDel Packet Scheduler and Active Queue
Management Algorithm", draft-ietf-aqm-fq-codel-06 (work in
progress), March 2016.
[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-03 (work in progress), May 2017. ecn-06 (work in progress), March 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-02 (work in progress), October alternativebackoff-ecn-07 (work in progress), March 2018.
2017.
[I-D.ietf-tcpm-cubic]
Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
draft-ietf-tcpm-cubic-06 (work in progress), September
2017.
[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-02 (work in progress),
October 2017. October 2017.
[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 AQM for Low Latency, Low Loss and Scalable "DualQ Coupled AQMs for Low Latency, Low Loss and Scalable
Throughput", draft-ietf-tsvwg-aqm-dualq-coupled-00 (work Throughput (L4S)", draft-ietf-tsvwg-aqm-dualq-coupled-04
in progress), April 2017. (work in progress), March 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-09 (work in progress), July 2017. encap-guidelines-10 (work in progress), March 2018.
[I-D.ietf-tsvwg-ecn-experimentation]
Black, D., "Relaxing Restrictions on Explicit Congestion
Notification (ECN) Experimentation", draft-ietf-tsvwg-ecn-
experimentation-07 (work in progress), October 2017.
[I-D.ietf-tsvwg-ecn-l4s-id] [I-D.ietf-tsvwg-ecn-l4s-id]
Schepper, K., Briscoe, B., and I. Tsang, "Identifying Schepper, K. and B. Briscoe, "Identifying Modified
Modified Explicit Congestion Notification (ECN) Semantics Explicit Congestion Notification (ECN) Semantics for
for Ultra-Low Queuing Delay", draft-ietf-tsvwg-ecn-l4s- Ultra-Low Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s-
id-00 (work in progress), April 2017. id-02 (work in progress), March 2018.
[I-D.johansson-quic-ecn] [I-D.johansson-quic-ecn]
Johansson, I., "ECN support in QUIC", draft-johansson- Johansson, I., "ECN support in QUIC", draft-johansson-
quic-ecn-03 (work in progress), May 2017. quic-ecn-03 (work in progress), May 2017.
[I-D.moncaster-tcpm-rcv-cheat] [I-D.smith-encrypted-traffic-management]
Moncaster, T., Briscoe, B., and A. Jacquet, "A TCP Test to Smith, K., "Network management of encrypted traffic",
Allow Senders to Identify Receiver Non-Compliance", draft- draft-smith-encrypted-traffic-management-05 (work in
moncaster-tcpm-rcv-cheat-03 (work in progress), July 2014. 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.
[I-D.you-encrypted-traffic-management]
You, J. and C. Xiong, "The Effect of Encrypted Traffic on
the QoS Mechanisms in Cellular Networks", draft-you-
encrypted-traffic-management-00 (work in progress),
October 2015.
[L4Sdemo16] [L4Sdemo16]
Bondarenko, O., De Schepper, K., Tsang, I., and B. Bondarenko, O., De Schepper, K., Tsang, I., and B.
Briscoe, "Ultra-Low Delay for All: Live Experience, Live Briscoe, "Ultra-Low Delay for All: Live Experience, 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: https://riteproject.eu/ (videos of demos: https://riteproject.eu/
dctth/#1511dispatchwg )>. dctth/#1511dispatchwg )>.
[Mathis09] [Mathis09]
Mathis, M., "Relentless Congestion Control", PFLDNeT'09 , Mathis, M., "Relentless Congestion Control", PFLDNeT'09 ,
skipping to change at page 28, line 21 skipping to change at page 28, line 16
Concepts, Abstract Mechanism, and Requirements", RFC 7713, Concepts, Abstract Mechanism, and Requirements", RFC 7713,
DOI 10.17487/RFC7713, December 2015, DOI 10.17487/RFC7713, December 2015,
<https://www.rfc-editor.org/info/rfc7713>. <https://www.rfc-editor.org/info/rfc7713>.
[RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White,
"Proportional Integral Controller Enhanced (PIE): A "Proportional Integral Controller Enhanced (PIE): A
Lightweight Control Scheme to Address the Bufferbloat Lightweight Control Scheme to Address the Bufferbloat
Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017,
<https://www.rfc-editor.org/info/rfc8033>. <https://www.rfc-editor.org/info/rfc8033>.
[RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and
Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170,
May 2017, <https://www.rfc-editor.org/info/rfc8170>.
[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., [RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
and G. Judd, "Data Center TCP (DCTCP): TCP Congestion and G. Judd, "Data Center TCP (DCTCP): TCP Congestion
Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257,
October 2017, <https://www.rfc-editor.org/info/rfc8257>. October 2017, <https://www.rfc-editor.org/info/rfc8257>.
[RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys,
J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler
and Active Queue Management Algorithm", RFC 8290,
DOI 10.17487/RFC8290, January 2018,
<https://www.rfc-editor.org/info/rfc8290>.
[RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion
Notification (ECN) Experimentation", RFC 8311,
DOI 10.17487/RFC8311, January 2018,
<https://www.rfc-editor.org/info/rfc8311>.
[RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
RFC 8312, DOI 10.17487/RFC8312, February 2018,
<https://www.rfc-editor.org/info/rfc8312>.
[TCP-sub-mss-w] [TCP-sub-mss-w]
Briscoe, B. and K. De Schepper, "Scaling TCP's Congestion Briscoe, B. and K. De Schepper, "Scaling TCP's Congestion
Window for Small Round Trip Times", BT Technical Report Window for Small Round Trip Times", BT Technical Report
TR-TUB8-2015-002, May 2015, TR-TUB8-2015-002, May 2015,
<http://www.bobbriscoe.net/projects/latency/ <http://www.bobbriscoe.net/projects/latency/
sub-mss-w.pdf>. sub-mss-w.pdf>.
Appendix A. Standardization items Appendix A. Standardization items
The following table includes all the items that will need to be The following table includes all the items that will need to be
 End of changes. 33 change blocks. 
104 lines changed or deleted 104 lines changed or added

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