draft-ietf-tsvwg-aqm-dualq-coupled-19.txt   draft-ietf-tsvwg-aqm-dualq-coupled-20.txt 
Transport Area working group (tsvwg) K. De Schepper Transport Area working group (tsvwg) K. De Schepper
Internet-Draft Nokia Bell Labs Internet-Draft Nokia Bell Labs
Intended status: Experimental B. Briscoe, Ed. Intended status: Experimental B. Briscoe, Ed.
Expires: 7 May 2022 Independent Expires: 27 June 2022 Independent
G. White G. White
CableLabs CableLabs
3 November 2021 24 December 2021
DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput
(L4S) (L4S)
draft-ietf-tsvwg-aqm-dualq-coupled-19 draft-ietf-tsvwg-aqm-dualq-coupled-20
Abstract Abstract
This specification defines a framework for coupling the Active Queue This specification defines a framework for coupling the Active Queue
Management (AQM) algorithms in two queues intended for flows with Management (AQM) algorithms in two queues intended for flows with
different responses to congestion. This provides a way for the different responses to congestion. This provides a way for the
Internet to transition from the scaling problems of standard TCP Internet to transition from the scaling problems of standard TCP
Reno-friendly ('Classic') congestion controls to the family of Reno-friendly ('Classic') congestion controls to the family of
'Scalable' congestion controls. These are designed for consistently 'Scalable' congestion controls. These are designed for consistently
very Low queuing Latency, very Low congestion Loss and Scaling of very Low queuing Latency, very Low congestion Loss and Scaling 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 7 May 2022. This Internet-Draft will expire on 27 June 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
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Outline of the Problem . . . . . . . . . . . . . . . . . 3 1.1. Outline of the Problem . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Features . . . . . . . . . . . . . . . . . . . . . . . . 9 1.4. Features . . . . . . . . . . . . . . . . . . . . . . . . 9
2. DualQ Coupled AQM . . . . . . . . . . . . . . . . . . . . . . 11 2. DualQ Coupled AQM . . . . . . . . . . . . . . . . . . . . . . 11
2.1. Coupled AQM . . . . . . . . . . . . . . . . . . . . . . . 11 2.1. Coupled AQM . . . . . . . . . . . . . . . . . . . . . . . 11
2.2. Dual Queue . . . . . . . . . . . . . . . . . . . . . . . 12 2.2. Dual Queue . . . . . . . . . . . . . . . . . . . . . . . 12
2.3. Traffic Classification . . . . . . . . . . . . . . . . . 13 2.3. Traffic Classification . . . . . . . . . . . . . . . . . 12
2.4. Overall DualQ Coupled AQM Structure . . . . . . . . . . . 13 2.4. Overall DualQ Coupled AQM Structure . . . . . . . . . . . 13
2.5. Normative Requirements for a DualQ Coupled AQM . . . . . 17 2.5. Normative Requirements for a DualQ Coupled AQM . . . . . 17
2.5.1. Functional Requirements . . . . . . . . . . . . . . . 17 2.5.1. Functional Requirements . . . . . . . . . . . . . . . 17
2.5.1.1. Requirements in Unexpected Cases . . . . . . . . 18 2.5.1.1. Requirements in Unexpected Cases . . . . . . . . 18
2.5.2. Management Requirements . . . . . . . . . . . . . . . 19 2.5.2. Management Requirements . . . . . . . . . . . . . . . 19
2.5.2.1. Configuration . . . . . . . . . . . . . . . . . . 19 2.5.2.1. Configuration . . . . . . . . . . . . . . . . . . 19
2.5.2.2. Monitoring . . . . . . . . . . . . . . . . . . . 21 2.5.2.2. Monitoring . . . . . . . . . . . . . . . . . . . 21
2.5.2.3. Anomaly Detection . . . . . . . . . . . . . . . . 22 2.5.2.3. Anomaly Detection . . . . . . . . . . . . . . . . 22
2.5.2.4. Deployment, Coexistence and Scaling . . . . . . . 22 2.5.2.4. Deployment, Coexistence and Scaling . . . . . . . 22
3. IANA Considerations (to be removed by RFC Editor) . . . . . . 22 3. IANA Considerations (to be removed by RFC Editor) . . . . . . 22
skipping to change at page 16, line 28 skipping to change at page 16, line 28
DualPI2 uses a Proportional-Integral (PI) controller as the Base AQM. DualPI2 uses a Proportional-Integral (PI) controller as the Base AQM.
Indeed, this Base AQM with just the squared output and no L4S queue Indeed, this Base AQM with just the squared output and no L4S queue
can be used as a drop-in replacement for PIE [RFC8033], in which case can be used as a drop-in replacement for PIE [RFC8033], in which case
it is just called PI2 [PI2]. PI2 is a principled simplification of it is just called PI2 [PI2]. PI2 is a principled simplification of
PIE that is both more responsive and more stable in the face of PIE that is both more responsive and more stable in the face of
dynamically varying load. dynamically varying load.
Curvy RED is derived from RED [RFC2309], except its configuration Curvy RED is derived from RED [RFC2309], except its configuration
parameters are delay-based to make them insensitive to link rate and parameters are delay-based to make them insensitive to link rate and
it requires less operations per packet. However, DualPI2 is more it requires less operations per packet than RED. However, DualPI2 is
responsive and stable over a wider range of RTTs than Curvy RED. As more responsive and stable over a wider range of RTTs than Curvy RED.
a consequence, at the time of writing, DualPI2 has attracted more As a consequence, at the time of writing, DualPI2 has attracted more
development and evaluation attention than Curvy RED, leaving the development and evaluation attention than Curvy RED, leaving the
Curvy RED design not so fully evaluated. Curvy RED design not so fully evaluated.
Both AQMs regulate their queue in units of time rather than bytes. Both AQMs regulate their queue in units of time rather than bytes.
As already explained, this ensures configuration can be invariant for As already explained, this ensures configuration can be invariant for
different drain rates. With AQMs in a dualQ structure this is different drain rates. With AQMs in a dualQ structure this is
particularly important because the drain rate of each queue can vary particularly important because the drain rate of each queue can vary
rapidly as flows for the two queues arrive and depart, even if the rapidly as flows for the two queues arrive and depart, even if the
combined link rate is constant. combined link rate is constant.
skipping to change at page 19, line 39 skipping to change at page 19, line 39
The above requirements are worded as "SHOULDs", because operator- The above requirements are worded as "SHOULDs", because operator-
specific classifiers are for flexibility, by definition. Therefore, specific classifiers are for flexibility, by definition. Therefore,
alternative actions might be appropriate in the operator's specific alternative actions might be appropriate in the operator's specific
circumstances. An example would be where the operator knows that circumstances. An example would be where the operator knows that
certain legacy traffic marked with one codepoint actually has a certain legacy traffic marked with one codepoint actually has a
congestion response associated with another codepoint. congestion response associated with another codepoint.
If the DualQ Coupled AQM has detected overload, it MUST begin using If the DualQ Coupled AQM has detected overload, it MUST begin using
Classic drop, and continue until the overload episode has subsided. Classic drop, and continue until the overload episode has subsided.
Switching to drop if ECN marking is persistently high is required by Introducing drop if ECN marking is persistently high is required by
Section 7 of [RFC3168] and Section 4.2.1 of [RFC7567]. Section 7 of [RFC3168] and Section 4.2.1 of [RFC7567].
2.5.2. Management Requirements 2.5.2. Management Requirements
2.5.2.1. Configuration 2.5.2.1. Configuration
By default, a DualQ Coupled AQM SHOULD NOT need any configuration for By default, a DualQ Coupled AQM SHOULD NOT need any configuration for
use at a bottleneck on the public Internet [RFC7567]. The following use at a bottleneck on the public Internet [RFC7567]. The following
parameters MAY be operator-configurable, e.g. to tune for non- parameters MAY be operator-configurable, e.g. to tune for non-
Internet settings: Internet settings:
skipping to change at page 25, line 46 skipping to change at page 25, line 46
target delay of the C queue. target delay of the C queue.
4.1.3. Protecting against Unresponsive ECN-Capable Traffic 4.1.3. Protecting against Unresponsive ECN-Capable Traffic
Unresponsive traffic has a greater advantage if it is also ECN- Unresponsive traffic has a greater advantage if it is also ECN-
capable. The advantage is undetectable at normal low levels of drop/ capable. The advantage is undetectable at normal low levels of drop/
marking, but it becomes significant with the higher levels of drop/ marking, but it becomes significant with the higher levels of drop/
marking typical during overload. This is an issue whether the ECN- marking typical during overload. This is an issue whether the ECN-
capable traffic is L4S or Classic. capable traffic is L4S or Classic.
This raises the question of whether and when to switch off ECN This raises the question of whether and when to introduce drop of
marking and use solely drop instead, as required by both Section 7 of ECN-capable traffic, as required by both Section 7 of [RFC3168] and
[RFC3168] and Section 4.2.1 of [RFC7567]. Section 4.2.1 of [RFC7567].
Experiments with the DualPI2 AQM (Appendix A) have shown that Experiments with the DualPI2 AQM (Appendix A) have shown that
introducing 'drop on saturation' at 100% L4S marking addresses this introducing 'drop on saturation' at 100% L4S marking addresses this
problem with unresponsive ECN as well as addressing the saturation problem with unresponsive ECN as well as addressing the saturation
problem. It leaves only a small range of congestion levels where problem. It leaves only a small range of congestion levels where
unresponsive traffic gains any advantage from using the ECN unresponsive traffic gains any advantage from using the ECN
capability (relative to being unresponsive without ECN), and the capability (relative to being unresponsive without ECN), and the
advantage is hardly detectable [DualQ-Test]. advantage is hardly detectable [DualQ-Test].
5. Acknowledgements 5. Acknowledgements
skipping to change at page 27, line 13 skipping to change at page 27, line 13
implementations were tested. implementations were tested.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-tsvwg-ecn-l4s-id] [I-D.ietf-tsvwg-ecn-l4s-id]
Schepper, K. D. and B. Briscoe, "Explicit Congestion Schepper, K. D. and B. Briscoe, "Explicit Congestion
Notification (ECN) Protocol for Very Low Queuing Delay Notification (ECN) Protocol for Very Low Queuing Delay
(L4S)", Work in Progress, Internet-Draft, draft-ietf- (L4S)", Work in Progress, Internet-Draft, draft-ietf-
tsvwg-ecn-l4s-id-19, 26 July 2021, tsvwg-ecn-l4s-id-22, 8 November 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg- <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-
ecn-l4s-id-19>. ecn-l4s-id-22>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
skipping to change at page 29, line 17 skipping to change at page 29, line 17
Dual Queue Coupled Active Queue Management", Masters Dual Queue Coupled Active Queue Management", Masters
Thesis, Dept of Informatics, Uni Oslo , May 2017, Thesis, Dept of Informatics, Uni Oslo , May 2017,
<https://www.duo.uio.no/bitstream/handle/10852/57424/ <https://www.duo.uio.no/bitstream/handle/10852/57424/
thesis-henrste.pdf?sequence=1>. thesis-henrste.pdf?sequence=1>.
[Heist21] Heist, P. and J. Morton, "L4S Tests", github README, [Heist21] Heist, P. and J. Morton, "L4S Tests", github README,
August 2021, <https://github.com/heistp/l4s- August 2021, <https://github.com/heistp/l4s-
tests/#underutilization-with-bursty-traffic>. tests/#underutilization-with-bursty-traffic>.
[I-D.briscoe-docsis-q-protection] [I-D.briscoe-docsis-q-protection]
Briscoe, B. and G. White, "Queue Protection to Preserve Briscoe, B. and G. White, "The DOCSIS(r) Queue Protection
Low Latency", Work in Progress, Internet-Draft, draft- Algorithm to Preserve Low Latency", Work in Progress,
briscoe-docsis-q-protection-00, 8 July 2019, Internet-Draft, draft-briscoe-docsis-q-protection-01, 17
<https://datatracker.ietf.org/doc/html/draft-briscoe- December 2021, <https://datatracker.ietf.org/doc/html/
docsis-q-protection-00>. draft-briscoe-docsis-q-protection-01>.
[I-D.briscoe-iccrg-prague-congestion-control] [I-D.briscoe-iccrg-prague-congestion-control]
Schepper, K. D., Tilmans, O., and B. Briscoe, "Prague Schepper, K. D., Tilmans, O., and B. Briscoe, "Prague
Congestion Control", Work in Progress, Internet-Draft, Congestion Control", Work in Progress, Internet-Draft,
draft-briscoe-iccrg-prague-congestion-control-00, 9 March draft-briscoe-iccrg-prague-congestion-control-00, 9 March
2021, <https://datatracker.ietf.org/doc/html/draft- 2021, <https://datatracker.ietf.org/doc/html/draft-
briscoe-iccrg-prague-congestion-control-00>. briscoe-iccrg-prague-congestion-control-00>.
[I-D.briscoe-tsvwg-l4s-diffserv] [I-D.briscoe-tsvwg-l4s-diffserv]
Briscoe, B., "Interactions between Low Latency, Low Loss, Briscoe, B., "Interactions between Low Latency, Low Loss,
Scalable Throughput (L4S) and Differentiated Services", Scalable Throughput (L4S) and Differentiated Services",
Work in Progress, Internet-Draft, draft-briscoe-tsvwg-l4s- Work in Progress, Internet-Draft, draft-briscoe-tsvwg-l4s-
diffserv-02, 4 November 2018, diffserv-02, 4 November 2018,
<https://datatracker.ietf.org/doc/html/draft-briscoe- <https://datatracker.ietf.org/doc/html/draft-briscoe-
tsvwg-l4s-diffserv-02>. tsvwg-l4s-diffserv-02>.
[I-D.cardwell-iccrg-bbr-congestion-control] [I-D.cardwell-iccrg-bbr-congestion-control]
Cardwell, N., Cheng, Y., Yeganeh, S. H., and V. Jacobson, Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V.
"BBR Congestion Control", Work in Progress, Internet- Jacobson, "BBR Congestion Control", Work in Progress,
Draft, draft-cardwell-iccrg-bbr-congestion-control-00, 3 Internet-Draft, draft-cardwell-iccrg-bbr-congestion-
July 2017, <https://datatracker.ietf.org/doc/html/draft- control-01, 7 November 2021,
cardwell-iccrg-bbr-congestion-control-00>. <https://datatracker.ietf.org/doc/html/draft-cardwell-
iccrg-bbr-congestion-control-01>.
[I-D.ietf-tsvwg-l4s-arch] [I-D.ietf-tsvwg-l4s-arch]
Briscoe, B., Schepper, K. D., Bagnulo, M., and G. White, Briscoe, B., Schepper, K. D., Bagnulo, M., and G. White,
"Low Latency, Low Loss, Scalable Throughput (L4S) Internet "Low Latency, Low Loss, Scalable Throughput (L4S) Internet
Service: Architecture", Work in Progress, Internet-Draft, Service: Architecture", Work in Progress, Internet-Draft,
draft-ietf-tsvwg-l4s-arch-10, 1 July 2021, draft-ietf-tsvwg-l4s-arch-14, 8 November 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg- <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-
l4s-arch-10>. l4s-arch-14>.
[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: (videos of demos:
https://riteproject.eu/dctth/#1511dispatchwg )>. https://riteproject.eu/dctth/#1511dispatchwg )>.
[L4S_5G] Willars, P., Wittenmark, E., Ronkainen, H., Östberg, C., [L4S_5G] Willars, P., Wittenmark, E., Ronkainen, H., Östberg, C.,
 End of changes. 15 change blocks. 
29 lines changed or deleted 30 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/