draft-ietf-tsvwg-aqm-dualq-coupled-22.txt   draft-ietf-tsvwg-aqm-dualq-coupled-23.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: 5 September 2022 Independent Expires: 5 November 2022 Independent
G. White G. White
CableLabs CableLabs
4 March 2022 4 May 2022
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-22 draft-ietf-tsvwg-aqm-dualq-coupled-23
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 5 September 2022. This Internet-Draft will expire on 5 November 2022.
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 35 skipping to change at page 2, line 35
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . . . 13
2.3. Traffic Classification . . . . . . . . . . . . . . . . . 13 2.3. Traffic Classification . . . . . . . . . . . . . . . . . 13
2.4. Overall DualQ Coupled AQM Structure . . . . . . . . . . . 13 2.4. Overall DualQ Coupled AQM Structure . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . . 20
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
4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22
4.1. Low Delay without Requiring Per-Flow Processing . . . . . 22 4.1. Low Delay without Requiring Per-Flow Processing . . . . . 22
4.2. Handling Unresponsive Flows and Overload . . . . . . . . 23 4.2. Handling Unresponsive Flows and Overload . . . . . . . . 23
4.2.1. Unresponsive Traffic without Overload . . . . . . . . 24 4.2.1. Unresponsive Traffic without Overload . . . . . . . . 24
4.2.2. Avoiding Short-Term Classic Starvation: Sacrifice L4S 4.2.2. Avoiding Short-Term Classic Starvation: Sacrifice L4S
Throughput or Delay? . . . . . . . . . . . . . . . . 25 Throughput or Delay? . . . . . . . . . . . . . . . . 25
skipping to change at page 3, line 15 skipping to change at page 3, line 15
4.2.3. L4S ECN Saturation: Introduce Drop or Delay? . . . . 26 4.2.3. L4S ECN Saturation: Introduce Drop or Delay? . . . . 26
4.2.3.1. Protecting against Overload by Unresponsive 4.2.3.1. Protecting against Overload by Unresponsive
ECN-Capable Traffic . . . . . . . . . . . . . . . . 28 ECN-Capable Traffic . . . . . . . . . . . . . . . . 28
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Normative References . . . . . . . . . . . . . . . . . . 29 7.1. Normative References . . . . . . . . . . . . . . . . . . 29
7.2. Informative References . . . . . . . . . . . . . . . . . 30 7.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Example DualQ Coupled PI2 Algorithm . . . . . . . . 35 Appendix A. Example DualQ Coupled PI2 Algorithm . . . . . . . . 35
A.1. Pass #1: Core Concepts . . . . . . . . . . . . . . . . . 36 A.1. Pass #1: Core Concepts . . . . . . . . . . . . . . . . . 36
A.2. Pass #2: Edge-Case Details . . . . . . . . . . . . . . . 46 A.2. Pass #2: Edge-Case Details . . . . . . . . . . . . . . . 47
Appendix B. Example DualQ Coupled Curvy RED Algorithm . . . . . 51 Appendix B. Example DualQ Coupled Curvy RED Algorithm . . . . . 51
B.1. Curvy RED in Pseudocode . . . . . . . . . . . . . . . . . 51 B.1. Curvy RED in Pseudocode . . . . . . . . . . . . . . . . . 51
B.2. Efficient Implementation of Curvy RED . . . . . . . . . . 57 B.2. Efficient Implementation of Curvy RED . . . . . . . . . . 57
Appendix C. Choice of Coupling Factor, k . . . . . . . . . . . . 59 Appendix C. Choice of Coupling Factor, k . . . . . . . . . . . . 59
C.1. RTT-Dependence . . . . . . . . . . . . . . . . . . . . . 59 C.1. RTT-Dependence . . . . . . . . . . . . . . . . . . . . . 59
C.2. Guidance on Controlling Throughput Equivalence . . . . . 60 C.2. Guidance on Controlling Throughput Equivalence . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64
1. Introduction 1. Introduction
skipping to change at page 7, line 35 skipping to change at page 7, line 35
outside the scope of this AQM document, even though the AQM is an outside the scope of this AQM document, even though the AQM is an
enabler. enabler.
The overall L4S architecture [I-D.ietf-tsvwg-l4s-arch] gives more The overall L4S architecture [I-D.ietf-tsvwg-l4s-arch] gives more
detail, including on wider deployment aspects such as backwards detail, including on wider deployment aspects such as backwards
compatibility of Scalable congestion controls in bottlenecks where a compatibility of Scalable congestion controls in bottlenecks where a
DualQ Coupled AQM has not been deployed. The supporting papers DualQ Coupled AQM has not been deployed. The supporting papers
[DualPI2Linux], [PI2], [DCttH19] and [PI2param] give the full [DualPI2Linux], [PI2], [DCttH19] and [PI2param] give the full
rationale for the AQM's design, both discursively and in more precise rationale for the AQM's design, both discursively and in more precise
mathematical form, as well as the results of performance evaluations. mathematical form, as well as the results of performance evaluations.
The main results have been validated independently when using the
Prague congestion control [Boru20] (experiments are run using Prague
and DCTCP, but only the former are relevant for validation, because
Prague fixes a number of problems with the Linux DCTCP code that make
it unsuitable for the public Internet).
1.3. Terminology 1.3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] when, and document are to be interpreted as described in [RFC2119] when, and
only when, they appear in all capitals, as shown here. only when, they appear in all capitals, as shown here.
The DualQ Coupled AQM uses two queues for two services. Each of the The DualQ Coupled AQM uses two queues for two services. Each of the
following terms identifies both the service and the queue that following terms identifies both the service and the queue that
skipping to change at page 29, line 38 skipping to change at page 29, line 38
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-24, 1 February 2022, tsvwg-ecn-l4s-id-25, 4 March 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg- <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-
ecn-l4s-id-24>. ecn-l4s-id-25>.
[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 30, line 34 skipping to change at page 30, line 34
[ARED01] Floyd, S., Gummadi, R., and S. Shenker, "Adaptive RED: An [ARED01] Floyd, S., Gummadi, R., and S. Shenker, "Adaptive RED: An
Algorithm for Increasing the Robustness of RED's Active Algorithm for Increasing the Robustness of RED's Active
Queue Management", ACIRI Technical Report , August 2001, Queue Management", ACIRI Technical Report , August 2001,
<http://www.icir.org/floyd/red.html>. <http://www.icir.org/floyd/red.html>.
[BBRv2] Cardwell, N., "BRTCP BBR v2 Alpha/Preview Release", github [BBRv2] Cardwell, N., "BRTCP BBR v2 Alpha/Preview Release", github
repository; Linux congestion control module, repository; Linux congestion control module,
<https://github.com/google/bbr/blob/v2alpha/README.md>. <https://github.com/google/bbr/blob/v2alpha/README.md>.
[Boru20] Boru Oljira, D., Grinnemo, K-J., Brunstrom, A., and J.
Taheri, "Validating the Sharing Behavior and Latency
Characteristics of the L4S Architecture", ACM CCR
50(2):37--44, May 2020,
<https://dl.acm.org/doi/abs/10.1145/3402413.3402419>.
[CCcensus19] [CCcensus19]
Mishra, A., Sun, X., Jain, A., Pande, S., Joshi, R., and Mishra, A., Sun, X., Jain, A., Pande, S., Joshi, R., and
B. Leong, "The Great Internet TCP Congestion Control B. Leong, "The Great Internet TCP Congestion Control
Census", Proc. ACM on Measurement and Analysis of Census", Proc. ACM on Measurement and Analysis of
Computing Systems 3(3), December 2019, Computing Systems 3(3), December 2019,
<https://doi.org/10.1145/3366693>. <https://doi.org/10.1145/3366693>.
[CoDel] Nichols, K. and V. Jacobson, "Controlling Queue Delay", [CoDel] Nichols, K. and V. Jacobson, "Controlling Queue Delay",
ACM Queue 10(5), May 2012, ACM Queue 10(5), May 2012,
<http://queue.acm.org/issuedetail.cfm?issue=2208917>. <http://queue.acm.org/issuedetail.cfm?issue=2208917>.
skipping to change at page 31, line 38 skipping to change at page 31, line 44
<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, "The DOCSIS(r) Queue Protection Briscoe, B. and G. White, "The DOCSIS(r) Queue Protection
Algorithm to Preserve Low Latency", Work in Progress, Algorithm to Preserve Low Latency", Work in Progress,
Internet-Draft, draft-briscoe-docsis-q-protection-02, 31 Internet-Draft, draft-briscoe-docsis-q-protection-03, 7
January 2022, <https://datatracker.ietf.org/doc/html/ March 2022, <https://datatracker.ietf.org/doc/html/draft-
draft-briscoe-docsis-q-protection-02>. briscoe-docsis-q-protection-03>.
[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., Swett, I., and V. Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V.
Jacobson, "BBR Congestion Control", Work in Progress, Jacobson, "BBR Congestion Control", Work in Progress,
Internet-Draft, draft-cardwell-iccrg-bbr-congestion- Internet-Draft, draft-cardwell-iccrg-bbr-congestion-
control-01, 7 November 2021, control-02, 7 March 2022,
<https://datatracker.ietf.org/doc/html/draft-cardwell- <https://datatracker.ietf.org/doc/html/draft-cardwell-
iccrg-bbr-congestion-control-01>. iccrg-bbr-congestion-control-02>.
[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-16, 1 February 2022, draft-ietf-tsvwg-l4s-arch-17, 4 March 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg- <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-
l4s-arch-16>. l4s-arch-17>.
[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.,
skipping to change at page 45, line 40 skipping to change at page 46, line 7
tunes them inherently. This is explained in [PI2], which also tunes them inherently. This is explained in [PI2], which also
explains why this more principled approach removes the need for most explains why this more principled approach removes the need for most
of the heuristics that had to be added to PIE. of the heuristics that had to be added to PIE.
Nonetheless, an implementer might wish to add selected details to Nonetheless, an implementer might wish to add selected details to
either AQM. For instance the Linux reference DualPI2 implementation either AQM. For instance the Linux reference DualPI2 implementation
includes the following (not shown in the pseudocode above): includes the following (not shown in the pseudocode above):
* Classic and coupled marking or dropping (i.e. based on p_C and * Classic and coupled marking or dropping (i.e. based on p_C and
p_CL from the PI controller) is not applied to a packet if the p_CL from the PI controller) is not applied to a packet if the
respective queue length in bytes is < 2 MTU (prior to enqueuing aggregate queue length in bytes is < 2 MTU (prior to enqueuing the
the packet or dequeuing it, depending on whether the AQM is packet or dequeuing it, depending on whether the AQM is configured
configured to be applied at enqueue or dequeue); to be applied at enqueue or dequeue);
* In the WRR scheduler, the 'credit' indicating which queue should * In the WRR scheduler, the 'credit' indicating which queue should
transmit is only changed if there are packets in both queues transmit is only changed if there are packets in both queues
(i.e. if there is actual resource contention). This means that a (i.e. if there is actual resource contention). This means that a
properly paced L flow might never be delayed by the WRR. The WRR properly paced L flow might never be delayed by the WRR. The WRR
credit is reset in favour of the L queue when the link is idle. credit is reset in favour of the L queue when the link is idle.
An implementer might also wish to add other heuristics, e.g. burst An implementer might also wish to add other heuristics, e.g. burst
protection [RFC8033] or enhanced burst protection [RFC8034]. protection [RFC8033] or enhanced burst protection [RFC8034].
 End of changes. 18 change blocks. 
20 lines changed or deleted 31 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/