< 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/