< draft-ietf-tsvwg-l4s-arch-20a.txt | draft-ietf-tsvwg-l4s-arch-20b.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: 25 February 2023 Nokia Bell Labs | Expires: 26 February 2023 Nokia Bell Labs | |||
M. Bagnulo Braun | M. Bagnulo Braun | |||
Universidad Carlos III de Madrid | Universidad Carlos III de Madrid | |||
G. White | G. White | |||
CableLabs | CableLabs | |||
24 August 2022 | 25 August 2022 | |||
Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: | Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: | |||
Architecture | Architecture | |||
draft-ietf-tsvwg-l4s-arch-20 | draft-ietf-tsvwg-l4s-arch-20 | |||
Abstract | Abstract | |||
This document describes the L4S architecture, which enables Internet | This document describes the L4S architecture, which enables Internet | |||
applications to achieve Low queuing Latency, Low Loss, and Scalable | applications to achieve Low queuing Latency, Low Loss, and Scalable | |||
throughput (L4S). L4S is based on the insight that the root cause of | throughput (L4S). L4S is based on the insight that the root cause of | |||
skipping to change at page 2, line 10 ¶ | skipping to change at page 2, line 10 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on 25 February 2023. | This Internet-Draft will expire on 26 February 2023. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
skipping to change at page 2, line 52 ¶ | skipping to change at page 2, line 52 ¶ | |||
6.3. Applicability with Specific Link Technologies . . . . . . 24 | 6.3. Applicability with Specific Link Technologies . . . . . . 24 | |||
6.4. Deployment Considerations . . . . . . . . . . . . . . . . 24 | 6.4. Deployment Considerations . . . . . . . . . . . . . . . . 24 | |||
6.4.1. Deployment Topology . . . . . . . . . . . . . . . . . 25 | 6.4.1. Deployment Topology . . . . . . . . . . . . . . . . . 25 | |||
6.4.2. Deployment Sequences . . . . . . . . . . . . . . . . 26 | 6.4.2. Deployment Sequences . . . . . . . . . . . . . . . . 26 | |||
6.4.3. L4S Flow but Non-ECN Bottleneck . . . . . . . . . . . 29 | 6.4.3. L4S Flow but Non-ECN Bottleneck . . . . . . . . . . . 29 | |||
6.4.4. L4S Flow but Classic ECN Bottleneck . . . . . . . . . 30 | 6.4.4. L4S Flow but Classic ECN Bottleneck . . . . . . . . . 30 | |||
6.4.5. L4S AQM Deployment within Tunnels . . . . . . . . . . 30 | 6.4.5. L4S AQM Deployment within Tunnels . . . . . . . . . . 30 | |||
7. IANA Considerations (to be removed by RFC Editor) . . . . . . 30 | 7. IANA Considerations (to be removed by RFC Editor) . . . . . . 30 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 | |||
8.1. Traffic Rate (Non-)Policing . . . . . . . . . . . . . . . 30 | 8.1. Traffic Rate (Non-)Policing . . . . . . . . . . . . . . . 30 | |||
8.1.1. (Non-)Policing Rate per Flow . . . . . . . . . . . . 30 | ||||
8.1.2. (Non-)Policing Rate per Class . . . . . . . . . . . . 31 | ||||
8.2. 'Latency Friendliness' . . . . . . . . . . . . . . . . . 32 | 8.2. 'Latency Friendliness' . . . . . . . . . . . . . . . . . 32 | |||
8.3. Interaction between Rate Policing and L4S . . . . . . . . 34 | 8.3. Interaction between Rate Policing and L4S . . . . . . . . 34 | |||
8.4. ECN Integrity . . . . . . . . . . . . . . . . . . . . . . 34 | 8.4. ECN Integrity . . . . . . . . . . . . . . . . . . . . . . 35 | |||
8.5. Privacy Considerations . . . . . . . . . . . . . . . . . 35 | 8.5. Privacy Considerations . . . . . . . . . . . . . . . . . 35 | |||
9. Informative References . . . . . . . . . . . . . . . . . . . 36 | 9. Informative References . . . . . . . . . . . . . . . . . . . 36 | |||
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 45 | Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 45 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 | |||
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, | |||
voice, conversational video, interactive video, interactive remote | voice, conversational video, interactive video, interactive remote | |||
presence, instant messaging, online gaming, remote desktop, cloud- | presence, instant messaging, online gaming, remote desktop, cloud- | |||
based applications and video-assisted remote control of machinery and | based 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 | |||
skipping to change at page 7, line 6 ¶ | skipping to change at page 6, line 46 ¶ | |||
(QUIC, SCTP, RTP/RTCP, RMCAT, etc.). Indeed, between the present | (QUIC, SCTP, RTP/RTCP, RMCAT, etc.). Indeed, between the present | |||
document being drafted and published, the following scalable | document being drafted and published, the following scalable | |||
congestion controls were implemented: TCP Prague [PragueLinux], | congestion controls were implemented: TCP Prague [PragueLinux], | |||
QUIC Prague, an L4S variant of the RMCAT SCReAM | QUIC Prague, an L4S variant of the RMCAT SCReAM | |||
controller [SCReAM] and the L4S ECN part of BBRv2 [BBRv2] intended | controller [SCReAM] and the L4S ECN part of BBRv2 [BBRv2] intended | |||
for TCP and QUIC transports. | for TCP and QUIC transports. | |||
2) Network: L4S traffic needs to be isolated from the queuing | 2) Network: L4S traffic needs to be isolated from the queuing | |||
latency of Classic traffic. One queue per application flow (FQ) | latency of Classic traffic. One queue per application flow (FQ) | |||
is one way to achieve this, e.g. FQ-CoDel [RFC8290]. However, | is one way to achieve this, e.g. FQ-CoDel [RFC8290]. However, | |||
just two queues is sufficient and does not require inspection of | using just two queues is sufficient and does not require | |||
transport layer headers in the network, which is not always | inspection of transport layer headers in the network, which is not | |||
possible (see Section 5.2). With just two queues, it might seem | always possible (see Section 5.2). With just two queues, it might | |||
impossible to know how much capacity to schedule for each queue | seem impossible to know how much capacity to schedule for each | |||
without inspecting how many flows at any one time are using each. | queue without inspecting how many flows at any one time are using | |||
And it would be undesirable to arbitrarily divide access network | each. And it would be undesirable to arbitrarily divide access | |||
capacity into two partitions. The Dual Queue Coupled AQM was | network capacity into two partitions. The Dual Queue Coupled AQM | |||
developed as a minimal complexity solution to this problem. It | was developed as a minimal complexity solution to this problem. | |||
acts like a 'semi-permeable' membrane that partitions latency but | It acts like a 'semi-permeable' membrane that partitions latency | |||
not bandwidth. As such, the two queues are for transition from | but not bandwidth. As such, the two queues are for transition | |||
Classic to L4S behaviour, not bandwidth prioritization. | from Classic to L4S behaviour, not bandwidth prioritization. | |||
Section 4 gives a high level explanation of how the per-flow-queue | Section 4 gives a high level explanation of how the per-flow-queue | |||
(FQ) and DualQ variants of L4S work, and | (FQ) and DualQ variants of L4S work, and | |||
[I-D.ietf-tsvwg-aqm-dualq-coupled] gives a full explanation of the | [I-D.ietf-tsvwg-aqm-dualq-coupled] gives a full explanation of the | |||
DualQ Coupled AQM framework. A specific marking algorithm is not | DualQ Coupled AQM framework. A specific marking algorithm is not | |||
mandated for L4S AQMs. Appendices of | mandated for L4S AQMs. Appendices of | |||
[I-D.ietf-tsvwg-aqm-dualq-coupled] give non-normative examples | [I-D.ietf-tsvwg-aqm-dualq-coupled] give non-normative examples | |||
that have been implemented and evaluated, and give recommended | that have been implemented and evaluated, and give recommended | |||
default parameter settings. It is expected that L4S experiments | default parameter settings. It is expected that L4S experiments | |||
will improve knowledge of parameter settings and whether the set | will improve knowledge of parameter settings and whether the set | |||
skipping to change at page 27, line 35 ¶ | skipping to change at page 27, line 35 ¶ | |||
+-+--------------------+----------------------+---------------------+ | +-+--------------------+----------------------+---------------------+ | |||
| | | | Upgrade DCTCP to | | | | | | Upgrade DCTCP to | | |||
|3| | Add L4S AQM upstream | TCP Prague | | |3| | Add L4S AQM upstream | TCP Prague | | |||
| | | | | | | | | | | | |||
| | FULLY WORKS UPSTREAM AND DOWNSTREAM | | | | FULLY WORKS UPSTREAM AND DOWNSTREAM | | |||
+-+--------------------+----------------------+---------------------+ | +-+--------------------+----------------------+---------------------+ | |||
Figure 3: Example L4S Deployment Sequence | Figure 3: Example L4S Deployment Sequence | |||
Figure 3 illustrates some example sequences in which the parts of L4S | Figure 3 illustrates some example sequences in which the parts of L4S | |||
might be deployed. It consists of the following stages: | might be deployed. It consists of the following stages, preceded by | |||
a presumption that DCTCP is already installed at both ends: | ||||
1. Here, the immediate benefit of a single AQM deployment can be | 1. DCTCP is not applicable for use over the public Internet, so it | |||
seen, but limited to a controlled trial or controlled deployment. | is emphasized here that any DCTCP flow has to be completely | |||
In this example downstream deployment is first, but in other | contained within a controlled trial environment. | |||
scenarios the upstream might be deployed first. If no AQM at all | ||||
was previously deployed for the downstream access, an L4S AQM | Within this trial environment, once an L4S AQM has been deployed, | |||
greatly improves the Classic service (as well as adding the L4S | the trial DCTCP flow will experience immediate benefit, without | |||
service). If an AQM was already deployed, the Classic service | any other deployment being needed. In this example downstream | |||
will be unchanged (and L4S will add an improvement on top). | deployment is first, but in other scenarios the upstream might be | |||
deployed first. If no AQM at all was previously deployed for the | ||||
downstream access, an L4S AQM greatly improves the Classic | ||||
service (as well as adding the L4S service). If an AQM was | ||||
already deployed, the Classic service will be unchanged (and L4S | ||||
will add an improvement on top). | ||||
2. In this stage, the name 'TCP | 2. In this stage, the name 'TCP | |||
Prague' [I-D.briscoe-iccrg-prague-congestion-control] is used to | Prague' [I-D.briscoe-iccrg-prague-congestion-control] is used to | |||
represent a variant of DCTCP that is designed to be used in a | represent a variant of DCTCP that is designed to be used in a | |||
production Internet environment (assuming it complies with the | production Internet environment (that is, it has to comply with | |||
requirements in Section 4 of the L4S ECN | all the requirements in Section 4 of the L4S ECN | |||
spec [I-D.ietf-tsvwg-ecn-l4s-id]). If the application is | spec [I-D.ietf-tsvwg-ecn-l4s-id], which then means it can be used | |||
primarily unidirectional, 'TCP Prague' at one end will provide | over the public Internet). If the application is primarily | |||
all the benefit needed. | unidirectional, 'TCP Prague' at one end will provide all the | |||
benefit needed. | ||||
For TCP transports, Accurate ECN feedback | For TCP transports, Accurate ECN feedback | |||
(AccECN) [I-D.ietf-tcpm-accurate-ecn] is needed at the other end, | (AccECN) [I-D.ietf-tcpm-accurate-ecn] is needed at the other end, | |||
but it is a generic ECN feedback facility that is already planned | but it is a generic ECN feedback facility that is already planned | |||
to be deployed for other purposes, e.g. DCTCP, BBR. The two ends | to be deployed for other purposes, e.g. DCTCP, BBR. The two ends | |||
can be deployed in either order, because, in TCP, an L4S | can be deployed in either order, because, in TCP, an L4S | |||
congestion control only enables itself if it has negotiated the | congestion control only enables itself if it has negotiated the | |||
use of AccECN feedback with the other end during the connection | use of 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, | |||
skipping to change at page 28, line 35 ¶ | skipping to change at page 28, line 36 ¶ | |||
Prague relative to DCTCP (see Appendix A.2 of the L4S ECN | Prague relative to DCTCP (see Appendix A.2 of the L4S ECN | |||
spec [I-D.ietf-tsvwg-ecn-l4s-id]). | spec [I-D.ietf-tsvwg-ecn-l4s-id]). | |||
Unlike TCP, from the outset, QUIC ECN feedback [RFC9000] has | Unlike TCP, from the outset, QUIC ECN feedback [RFC9000] has | |||
supported L4S. Therefore, if the transport is QUIC, one-ended | supported L4S. Therefore, if the transport is QUIC, one-ended | |||
deployment of a Prague congestion control at this stage is simple | deployment of a Prague congestion control at this stage is simple | |||
and sufficient. | and sufficient. | |||
For QUIC, if a proxy sits in the path between multiple origin | For QUIC, if a proxy sits in the path between multiple origin | |||
servers and the access bottlenecks to multiple clients, then | servers and the access bottlenecks to multiple clients, then | |||
upgrading the proxy to a Scalable CC would provide the benefits | upgrading the proxy with a Scalable congestion control would | |||
of L4S over all the clients' downstream bottlenecks in one go --- | provide the benefits of L4S over all the clients' downstream | |||
whether or not all the origin servers were upgraded. Conversely, | bottlenecks in one go --- whether or not all the origin servers | |||
where a proxy has not been upgraded, the clients served by it | were upgraded. Conversely, where a proxy has not been upgraded, | |||
will not benefit from L4S at all in the downstream, even when any | the clients served by it will not benefit from L4S at all in the | |||
origin server behind the proxy has been upgraded to support L4S. | downstream, even when any origin server behind the proxy has been | |||
upgraded to support L4S. | ||||
For TCP, a proxy upgraded to support 'TCP Prague' would provide | For TCP, a proxy upgraded to support 'TCP Prague' would provide | |||
the benefits of L4S downstream to all clients that support AccECN | the benefits of L4S downstream to all clients that support AccECN | |||
(whether or not they support L4S as well). And in the upstream, | (whether or not they support L4S as well). And in the upstream, | |||
the proxy would also support AccECN as a receiver, so that any | the proxy would also support AccECN as a receiver, so that any | |||
client deploying its own L4S support would benefit in the | client deploying its own L4S support would benefit in the | |||
upstream direction, irrespective of whether any origin server | upstream direction, irrespective of whether any origin server | |||
beyond the proxy supported AccECN. | beyond the proxy supported AccECN. | |||
3. This is a two-move stage to enable L4S upstream. An L4S AQM or | 3. This is a two-move stage to enable L4S upstream. An L4S AQM or | |||
skipping to change at page 30, line 39 ¶ | skipping to change at page 30, line 39 ¶ | |||
[I-D.ietf-tsvwg-ecn-encap-guidelines]. | [I-D.ietf-tsvwg-ecn-encap-guidelines]. | |||
7. IANA Considerations (to be removed by RFC Editor) | 7. IANA Considerations (to be removed by RFC Editor) | |||
This specification contains no IANA considerations. | This specification contains no IANA considerations. | |||
8. Security Considerations | 8. Security Considerations | |||
8.1. Traffic Rate (Non-)Policing | 8.1. Traffic Rate (Non-)Policing | |||
In the current Internet, scheduling usually enforces separation | 8.1.1. (Non-)Policing Rate per Flow | |||
between 'sites' (e.g. households, businesses or mobile | ||||
users [RFC0970]) and various techniques like redirection to traffic | ||||
scrubbing facilities deal with flooding attacks. However, there has | ||||
never been a universal need to police the rate of individual | ||||
application flows - the Internet has generally always relied on self- | ||||
restraint of congestion controls at senders for sharing intra-'site' | ||||
capacity. | ||||
As explained in Section 5.2, the DualQ variant of L4S provides low | In the current Internet, ISPs usually enforce separation between the | |||
delay without prejudging the issue of flow-rate control. Then, if | capacity of shared links assigned to different 'sites' | |||
flow-rate control is needed, per-flow-queuing (FQ) can be used | (e.g. households, businesses or mobile users - see terminology in | |||
instead, or flow rate policing can be added as a modular addition to | Section 3) using some form of scheduler [RFC0970]. And they use | |||
a DualQ. | various techniques like redirection to traffic scrubbing facilities | |||
to deal with flooding attacks. However, there has never been a | ||||
universal need to police the rate of individual application flows - | ||||
the Internet has generally always relied on self-restraint of | ||||
congestion controls at senders for sharing intra-'site' capacity. | ||||
Because the L4S service reduces delay without increasing the delay of | L4S has been designed not to upset this situation. If a DualQ is | |||
Classic traffic, it should not be necessary to rate-police access to | used to provide L4S service, section 4.2 of | |||
the L4S service. In contrast, Section 5.2 explains how Diffserv only | [I-D.ietf-tsvwg-aqm-dualq-coupled] explains how it is designed to | |||
makes a difference if some packets get less favourable treatment than | give no more rate advantage to unresponsive flows than a single-queue | |||
others, which typically requires traffic rate policing, which can, in | AQM would, whether or not there is traffic overload. | |||
turn, lead to further complexity such as traffic contracts at trust | ||||
boundaries. Because L4S avoids this management complexity, it is | Also, in case per-flow rate policing is ever required, it can be | |||
more likely to work end-to-end. | added because it is orthogonal to the distinction between L4S and | |||
Classic. As explained in Section 5.2, the DualQ variant of L4S | ||||
provides low delay without prejudging the issue of flow-rate control. | ||||
So, if flow-rate control is needed, per-flow-queuing (FQ) with L4S | ||||
support can be used instead, or flow rate policing can be added as a | ||||
modular addition to a DualQ. However, an active attacker will just | ||||
shard its traffic over more flow IDs if the rate of each is | ||||
restricted, which is why per-flow rate control is typically intended | ||||
for latency isolation rather than rate control _per se_. | ||||
8.1.2. (Non-)Policing Rate per Class | ||||
Section 5.2 explains how Diffserv only makes a difference if some | ||||
packets get less favourable treatment than others, which typically | ||||
requires traffic rate policing, which can, in turn, lead to further | ||||
management complexity such as traffic contracts at trust boundaries. | ||||
In contrast, it should not be necessary to rate-police access to the | ||||
L4S service, because L4S is designed to reduce delay without harming | ||||
the delay or rate of any Classic traffic. As an aside, because L4S | ||||
avoids this management complexity, it is more likely to work end-to- | ||||
end. | ||||
During early deployment (and perhaps always), some networks will not | During early deployment (and perhaps always), some networks will not | |||
offer the L4S service. In general, these networks should not need to | offer the L4S service. In general, these networks should not need to | |||
police L4S traffic. They are required (by both the ECN | police L4S traffic. They are required (by both the ECN | |||
spec [RFC3168] and the L4S ECN spec [I-D.ietf-tsvwg-ecn-l4s-id]) not | spec [RFC3168] and the L4S ECN spec [I-D.ietf-tsvwg-ecn-l4s-id]) not | |||
to change the L4S identifier, which would interfere with end-to-end | to change the L4S identifier, which would interfere with end-to-end | |||
congestion control. If they already treat ECN traffic as Not-ECT, | congestion control. If they already treat ECN traffic as Not-ECT, | |||
they can merely treat L4S traffic as Not-ECT too. At a bottleneck, | they can merely treat L4S traffic as Not-ECT too. At a bottleneck, | |||
such networks will introduce some queuing and dropping. When a | such networks will introduce some queuing and dropping. When a | |||
scalable congestion control detects a drop it will have to respond | scalable congestion control detects a drop it will have to respond | |||
skipping to change at page 32, line 34 ¶ | skipping to change at page 32, line 38 ¶ | |||
Like the Classic service, the L4S service relies on self-restraint - | 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-restraint 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 | Because the L4S service can reduce delay without discernibly | |||
it, there will be potential for attacks on the low latency of the L4S | increasing the delay of any Classic traffic, it should not be | |||
service. | necessary to police L4S traffic to protect the delay of Classic. | |||
However, whether burst policing becomes necessary to protect other | ||||
L4S traffic remains to be seen. Without it, there will be potential | ||||
for attacks on the low latency of the L4S service. | ||||
If needed, various arrangements could be used to address this | If needed, various arrangements could be used to address this | |||
concern: | concern: | |||
Local bottleneck queue protection: A per-flow (5-tuple) queue | Local bottleneck queue protection: A per-flow (5-tuple) queue | |||
protection function [I-D.briscoe-docsis-q-protection] has been | protection function [I-D.briscoe-docsis-q-protection] has been | |||
developed for the low latency queue in DOCSIS, which has adopted | developed for the low latency queue in DOCSIS, which has adopted | |||
the DualQ L4S architecture. It protects the low latency service | the DualQ L4S architecture. It protects the low latency service | |||
from any queue-building flows that accidentally or maliciously | from any queue-building flows that accidentally or maliciously | |||
classify themselves into the low latency queue. It is designed to | classify themselves into the low latency queue. It is designed to | |||
skipping to change at page 33, line 45 ¶ | skipping to change at page 34, line 5 ¶ | |||
Distributed core network queue protection: The policing function | Distributed core network queue protection: The policing function | |||
could be divided between per-flow mechanisms at the network | could be divided between per-flow mechanisms at the network | |||
ingress that characterize the burstiness of each flow into a | ingress that characterize the burstiness of each flow into a | |||
signal carried with the traffic, and per-class mechanisms at | signal carried with the traffic, and per-class mechanisms at | |||
bottlenecks that act on these signals if queuing actually occurs | bottlenecks that act on these signals if queuing actually occurs | |||
once the traffic converges. This would be somewhat similar to | once the traffic converges. This would be somewhat similar to | |||
[Nadas20], which is in turn similar to the idea behind core | [Nadas20], which is in turn similar to the idea behind core | |||
stateless fair queuing. | stateless fair queuing. | |||
None of these possible queue protection capabilities are considered a | No single one of these possible queue protection capabilities is | |||
necessary part of the L4S architecture, which works without them (in | considered an essential part of the L4S architecture, which works | |||
a similar way to how the Internet works without per-flow rate | without any of them under non-attack conditions (in a similar way to | |||
policing). Indeed, even where latency policers are deployed, under | how the Internet normally works without per-flow rate policing). | |||
normal circumstances they would not intervene, and if operators found | Indeed, even where latency policers are deployed, under normal | |||
they were not necessary they could disable them. Part of the L4S | circumstances they would not intervene, and if operators found they | |||
were not necessary they could disable them. Part of the L4S | ||||
experiment will be to see whether such a function is necessary, and | experiment will be to see whether such a function is necessary, and | |||
which arrangements are most appropriate to the size of the problem. | which arrangements are most appropriate to the size of the problem. | |||
8.3. Interaction between Rate Policing and L4S | 8.3. Interaction between Rate Policing and L4S | |||
As mentioned in Section 5.2, L4S should remove the need for low | As mentioned in Section 5.2, L4S should remove the need for low | |||
latency Diffserv classes. However, those Diffserv classes that give | latency Diffserv classes. However, those Diffserv classes that give | |||
certain applications or users priority over capacity, would still be | certain applications or users priority over capacity, would still be | |||
applicable in certain scenarios (e.g. corporate networks). Then, | applicable in certain scenarios (e.g. corporate networks). Then, | |||
within such Diffserv classes, L4S would often be applicable to give | within such Diffserv classes, L4S would often be applicable to give | |||
traffic low latency and low loss as well. Within such a Diffserv | traffic low latency and low loss as well. Within such a Diffserv | |||
class, the bandwidth available to a user or application is often | class, the bandwidth available to a user or application is often | |||
limited by a rate policer. Similarly, in the default Diffserv class, | limited by a rate policer. Similarly, in the default Diffserv class, | |||
rate policers are used to partition shared capacity. | rate policers are sometimes used to partition shared capacity (e.g. | |||
for some passive optical networks). | ||||
A classic rate policer drops any packets exceeding a set rate, | A classic rate policer drops any packets exceeding a set rate, | |||
usually also giving a burst allowance (variants exist where the | usually also giving a burst allowance (variants exist where the | |||
policer re-marks non-compliant traffic to a discard-eligible Diffserv | policer re-marks non-compliant traffic to a discard-eligible Diffserv | |||
codepoint, so they can be dropped elsewhere during contention). | codepoint, so they can be dropped elsewhere during contention). | |||
Whenever L4S traffic encounters one of these rate policers, it will | Whenever L4S traffic encounters one of these rate policers, it will | |||
experience drops and the source will have to fall back to a Classic | experience drops and the source will have to fall back to a Classic | |||
congestion control, thus losing the benefits of L4S (Section 6.4.3). | congestion control, thus losing the benefits of L4S (Section 6.4.3). | |||
So, in networks that already use rate policers and plan to deploy | So, in networks that already use rate policers and plan to deploy | |||
L4S, it will be preferable to redesign these rate policers to be more | L4S, it will be preferable to redesign these rate policers to be more | |||
End of changes. 17 change blocks. | ||||
67 lines changed or deleted | 99 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/ |