draft-ietf-tsvwg-l4s-arch-13.txt   draft-ietf-tsvwg-l4s-arch-14.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: 11 May 2022 Nokia Bell Labs Expires: 12 May 2022 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
7 November 2021 8 November 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-13 draft-ietf-tsvwg-l4s-arch-14
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. With the L4S architecture all Internet not in the queue itself. With the L4S architecture all Internet
applications could (but do not have to) transition away from applications could (but do not have to) transition away from
congestion control algorithms that cause substantial queuing delay, congestion control algorithms that cause substantial queuing delay,
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 11 May 2022. This Internet-Draft will expire on 12 May 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 46 skipping to change at page 2, line 46
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Document Roadmap . . . . . . . . . . . . . . . . . . . . 5 1.1. Document Roadmap . . . . . . . . . . . . . . . . . . . . 5
2. L4S Architecture Overview . . . . . . . . . . . . . . . . . . 5 2. L4S Architecture Overview . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. L4S Architecture Components . . . . . . . . . . . . . . . . . 9 4. L4S Architecture Components . . . . . . . . . . . . . . . . . 9
4.1. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 9 4.1. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 9
4.2. Network Components . . . . . . . . . . . . . . . . . . . 10 4.2. Network Components . . . . . . . . . . . . . . . . . . . 10
4.3. Host Mechanisms . . . . . . . . . . . . . . . . . . . . . 13 4.3. Host Mechanisms . . . . . . . . . . . . . . . . . . . . . 13
5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Why These Primary Components? . . . . . . . . . . . . . . 14 5.1. Why These Primary Components? . . . . . . . . . . . . . . 15
5.2. What L4S adds to Existing Approaches . . . . . . . . . . 18 5.2. What L4S adds to Existing Approaches . . . . . . . . . . 18
6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 21 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. Applications . . . . . . . . . . . . . . . . . . . . . . 21 6.1. Applications . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 22 6.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 23
6.3. Applicability with Specific Link Technologies . . . . . . 23 6.3. Applicability with Specific Link Technologies . . . . . . 24
6.4. Deployment Considerations . . . . . . . . . . . . . . . . 24 6.4. Deployment Considerations . . . . . . . . . . . . . . . . 24
6.4.1. Deployment Topology . . . . . . . . . . . . . . . . . 24 6.4.1. Deployment Topology . . . . . . . . . . . . . . . . . 25
6.4.2. Deployment Sequences . . . . . . . . . . . . . . . . 26 6.4.2. Deployment Sequences . . . . . . . . . . . . . . . . 26
6.4.3. L4S Flow but Non-ECN Bottleneck . . . . . . . . . . . 28 6.4.3. L4S Flow but Non-ECN Bottleneck . . . . . . . . . . . 29
6.4.4. L4S Flow but Classic ECN Bottleneck . . . . . . . . . 29 6.4.4. L4S Flow but Classic ECN Bottleneck . . . . . . . . . 30
6.4.5. L4S AQM Deployment within Tunnels . . . . . . . . . . 30 6.4.5. L4S AQM Deployment within Tunnels . . . . . . . . . . 30
7. IANA Considerations (to be removed by RFC Editor) . . . . . . 30 7. IANA Considerations (to be removed by RFC Editor) . . . . . . 30
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
8.1. Traffic Rate (Non-)Policing . . . . . . . . . . . . . . . 30 8.1. Traffic Rate (Non-)Policing . . . . . . . . . . . . . . . 30
8.2. 'Latency Friendliness' . . . . . . . . . . . . . . . . . 31 8.2. 'Latency Friendliness' . . . . . . . . . . . . . . . . . 32
8.3. Interaction between Rate Policing and L4S . . . . . . . . 33 8.3. Interaction between Rate Policing and L4S . . . . . . . . 33
8.4. ECN Integrity . . . . . . . . . . . . . . . . . . . . . . 34 8.4. ECN Integrity . . . . . . . . . . . . . . . . . . . . . . 34
8.5. Privacy Considerations . . . . . . . . . . . . . . . . . 34 8.5. Privacy Considerations . . . . . . . . . . . . . . . . . 35
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
10. Informative References . . . . . . . . . . . . . . . . . . . 35 10. Informative References . . . . . . . . . . . . . . . . . . . 35
Appendix A. Standardization items . . . . . . . . . . . . . . . 45 Appendix A. Standardization items . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
At any one time, it is increasingly common for all of the traffic in At any one time, it is increasingly common for all of the traffic in
a bottleneck link (e.g. a household's Internet access) to come from a bottleneck link (e.g. a household's Internet access) to come from
applications that prefer low delay: interactive Web, Web services, applications that prefer low delay: interactive Web, Web services,
skipping to change at page 7, line 39 skipping to change at page 7, line 39
3) Protocol: A host needs to distinguish L4S and Classic packets 3) 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] concludes their separate treatments. [I-D.ietf-tsvwg-ecn-l4s-id] concludes
that all alternatives involve compromises, but the ECT(1) and CE that all alternatives involve compromises, but the ECT(1) and CE
codepoints of the ECN field represent a workable solution. As codepoints of the ECN field represent a workable solution. As
already explained, the network also uses ECN to immediately signal already explained, the network also uses ECN to immediately signal
the very start of queue growth to the transport. the very start of queue growth to the transport.
3. Terminology 3. Terminology
Note: The following definitions are copied from
[I-D.ietf-tsvwg-ecn-l4s-id] for convenience. If there are accidental
differences those in [I-D.ietf-tsvwg-ecn-l4s-id] take precedence.
Classic Congestion Control: A congestion control behaviour that can Classic Congestion Control: A congestion control behaviour that can
co-exist with standard Reno [RFC5681] without causing co-exist with standard Reno [RFC5681] without causing
significantly negative impact on its flow rate [RFC5033]. The significantly negative impact on its flow rate [RFC5033]. The
scaling problem with Classic congestion control is explained, with scaling problem with Classic congestion control is explained, with
examples, in Section 5.1 and in [RFC3649]. examples, in Section 5.1 and in [RFC3649].
Scalable Congestion Control: A congestion control where the average Scalable Congestion Control: A congestion control where the average
time from one congestion signal to the next (the recovery time) time from one congestion signal to the next (the recovery time)
remains invariant as the flow rate scales, all other factors being remains invariant as the flow rate scales, all other factors being
equal. For instance, DCTCP averages 2 congestion signals per equal. For instance, DCTCP averages 2 congestion signals per
skipping to change at page 8, line 37 skipping to change at page 8, line 42
'flow'. For example: an L4S packet means a packet with an L4S 'flow'. For example: an L4S packet means a packet with an L4S
identifier sent from an L4S congestion control. identifier sent from an L4S congestion control.
Both Classic and L4S services can cope with a proportion of Both Classic and L4S services can cope with a proportion of
unresponsive or less-responsive traffic as well, but in the L4S unresponsive or less-responsive traffic as well, but in the L4S
case its rate has to be smooth enough or low enough not build a case its rate has to be smooth enough or low enough not build a
queue (e.g. DNS, VoIP, game sync datagrams, etc). queue (e.g. DNS, VoIP, game sync datagrams, etc).
Reno-friendly: The subset of Classic traffic that is friendly to the Reno-friendly: The subset of Classic traffic that is friendly to the
standard Reno congestion control defined for TCP in [RFC5681]. standard Reno congestion control defined for TCP in [RFC5681].
Reno-friendly is used in place of 'TCP-friendly', given the latter The TFRC spec. [RFC5348] indirectly implies that 'friendly' is
has become imprecise, because the TCP protocol is now used with so defined as "generally within a factor of two of the sending rate
many different congestion control behaviours, and Reno is used in of a TCP flow under the same conditions". Reno-friendly is used
non-TCP transports such as QUIC [RFC9000]. here in place of 'TCP-friendly', given the latter has become
imprecise, because the TCP protocol is now used with so many
different congestion control behaviours, and Reno is used in non-
TCP transports such as QUIC [RFC9000].
Classic ECN: The original Explicit Congestion Notification (ECN) Classic ECN: The original Explicit Congestion Notification (ECN)
protocol [RFC3168], which requires ECN signals to be treated as protocol [RFC3168], which requires ECN signals to be treated as
equivalent to drops, both when generated in the network and when equivalent to drops, both when generated in the network and when
responded to by the sender. responded to by the sender.
L4S uses the ECN field as an identifier L4S uses the ECN field as an identifier
[I-D.ietf-tsvwg-ecn-l4s-id] with the names for the four codepoints [I-D.ietf-tsvwg-ecn-l4s-id] with the names for the four codepoints
of the 2-bit IP-ECN field unchanged from those defined in of the 2-bit IP-ECN field unchanged from those defined in
[RFC3168]: Not ECT, ECT(0), ECT(1) and CE, where ECT stands for [RFC3168]: Not ECT, ECT(0), ECT(1) and CE, where ECT stands for
skipping to change at page 20, line 32 skipping to change at page 20, line 45
Note: Note:
1. It might seem that self-inflicted queuing delay within a per- 1. It might seem that self-inflicted queuing delay within a per-
flow queue should not be counted, because if the delay wasn't flow queue should not be counted, because if the delay wasn't
in the network it would just shift to the sender. However, in the network it would just shift to the sender. However,
modern adaptive applications, e.g. HTTP/2 [RFC7540] or some modern adaptive applications, e.g. HTTP/2 [RFC7540] or some
interactive media applications (see Section 6.1), can keep low interactive media applications (see Section 6.1), can keep low
latency objects at the front of their local send queue by latency objects at the front of their local send queue by
shuffling priorities of other objects dependent on the shuffling priorities of other objects dependent on the
progress of other transfers. They cannot shuffle objects once progress of other transfers (for example see [lowat]). They
they have released them into the network. cannot shuffle objects once they have released them into the
network.
Alternative Back-off ECN (ABE): Here again, L4S is not an Alternative Back-off ECN (ABE): Here again, L4S is not an
alternative to ABE but a complement that introduces much lower alternative to ABE but a complement that introduces much lower
queuing delay. ABE [RFC8511] alters the host behaviour in queuing delay. ABE [RFC8511] alters the host behaviour in
response to ECN marking to utilize a link better and give ECN response to ECN marking to utilize a link better and give ECN
flows faster throughput. It uses ECT(0) and assumes the network flows faster throughput. It uses ECT(0) and assumes the network
still treats ECN and drop the same. Therefore ABE exploits any still treats ECN and drop the same. Therefore ABE exploits any
lower queuing delay that AQMs can provide. But as explained lower queuing delay that AQMs can provide. But as explained
above, AQMs still cannot reduce queuing delay too far without above, AQMs still cannot reduce queuing delay too far without
losing link utilization (to allow for other, non-ABE, flows). losing link utilization (to allow for other, non-ABE, flows).
skipping to change at page 26, line 13 skipping to change at page 26, line 41
core). core).
An L4S AQM would often next be needed where the WiFi links in a home An L4S AQM would often next be needed where the WiFi links in a home
sometimes become the bottleneck. And an L4S AQM would eventually sometimes become the bottleneck. And an L4S AQM would eventually
also need to be deployed at any other persistent bottlenecks such as also need to be deployed at any other persistent bottlenecks such as
network interconnections, e.g. some public Internet exchange points network interconnections, e.g. some public Internet exchange points
and the ingress and egress to WAN links interconnecting data-centres. and the ingress and egress to WAN links interconnecting data-centres.
6.4.2. Deployment Sequences 6.4.2. Deployment Sequences
For any one L4S flow to provide benefit, it requires 3 parts to have For any one L4S flow to provide benefit, it requires three (or
been deployed. This was the same deployment problem that ECN sometimes two) parts to have been deployed: i) the congestion control
faced [RFC8170] so we have learned from that experience. at the sender; ii) the AQM at the bottleneck; and iii) older
transports (namely TCP) need upgraded receiver feedback too. This
was the same deployment problem that ECN 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, an L4S AQM can be deployed at a network clients. Therefore, an L4S AQM can be deployed at a network
bottleneck to immediately give a working deployment of all the L4S bottleneck to immediately give a working deployment of all the L4S
parts for testing, as long as the ECT(0) codepoint is switched to parts for testing, as long as the ECT(0) codepoint is switched to
ECT(1). DCTCP needs some safety concerns to be fixed for general use ECT(1). DCTCP needs some safety concerns to be fixed for general use
over the public Internet (see Section 4.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
skipping to change at page 31, line 38 skipping to change at page 32, line 7
[I-D.ietf-tsvwg-ecn-l4s-id]) is intended to remove any motivation to [I-D.ietf-tsvwg-ecn-l4s-id]) is intended to remove any motivation to
clear the L4S identifier. Then at least the L4S ECN identifier will clear the L4S identifier. Then at least the L4S ECN identifier will
be more likely to survive end-to-end even though the service may not be more likely to survive end-to-end even though the service may not
be supported at every hop. Such local arrangements would only be supported at every hop. Such local arrangements would only
require simple registered/not-registered packet classification, require simple registered/not-registered packet classification,
rather than the managed, application-specific traffic policing rather than the managed, application-specific traffic policing
against customer-specific traffic contracts that Diffserv uses. 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-restraint -
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-restraint 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
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. service.
skipping to change at page 40, line 8 skipping to change at page 40, line 23
(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>.
[lowat] Meenan, P., "Optimizing HTTP/2 prioritization with BBR and
tcp_notsent_lowat", Cloudflare Blog , 12 October 2018,
<https://blog.cloudflare.com/http-2-prioritization-with-
nginx/>.
[Mathis09] Mathis, M., "Relentless Congestion Control", PFLDNeT'09 , [Mathis09] Mathis, M., "Relentless Congestion Control", PFLDNeT'09 ,
May 2009, <https://www.gdt.id.au/~gdt/ May 2009, <https://www.gdt.id.au/~gdt/
presentations/2010-07-06-questnet-tcp/reference- presentations/2010-07-06-questnet-tcp/reference-
materials/papers/mathis-relentless-congestion- materials/papers/mathis-relentless-congestion-
control.pdf>. control.pdf>.
[McIlroy78] [McIlroy78]
McIlroy, M.D., Pinson, E. N., and B. A. Tague, "UNIX Time- McIlroy, M.D., Pinson, E. N., and B. A. Tague, "UNIX Time-
Sharing System: Foreword", The Bell System Technical Sharing System: Foreword", The Bell System Technical
Journal 57:6(1902--1903), July 1978, Journal 57:6(1902--1903), July 1978,
 End of changes. 17 change blocks. 
24 lines changed or deleted 40 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/