draft-ietf-tsvwg-aqm-dualq-coupled-03.txt   draft-ietf-tsvwg-aqm-dualq-coupled-04.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: July 28, 2018 CableLabs Expires: September 6, 2018 CableLabs
O. Bondarenko O. Bondarenko
Simula Research Lab Simula Research Lab
I. Tsang I. Tsang
Nokia Nokia
January 24, 2018 March 5, 2018
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-03 draft-ietf-tsvwg-aqm-dualq-coupled-04
Abstract Abstract
Data Centre TCP (DCTCP) was designed to provide predictably low Data Centre TCP (DCTCP) was designed to provide predictably low
queuing latency, near-zero loss, and throughput scalability using queuing latency, near-zero loss, and throughput scalability using
explicit congestion notification (ECN) and an extremely simple explicit congestion notification (ECN) and an extremely simple
marking behaviour on switches. However, DCTCP does not co-exist with marking behaviour on switches. However, DCTCP does not co-exist with
existing TCP traffic---DCTCP is so aggressive that existing TCP existing TCP traffic---DCTCP is so aggressive that existing TCP
algorithms approach starvation. So, until now, DCTCP could only be algorithms approach starvation. So, until now, DCTCP could only be
deployed where a clean-slate environment could be arranged, such as deployed where a clean-slate environment could be arranged, such as
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 July 28, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem and Scope . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem and Scope . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Features . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Features . . . . . . . . . . . . . . . . . . . . . . . . 6
2. DualQ Coupled AQM . . . . . . . . . . . . . . . . . . . . . . 7 2. DualQ Coupled AQM . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Coupled AQM . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Coupled AQM . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Dual Queue . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Dual Queue . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Traffic Classification . . . . . . . . . . . . . . . . . 8 2.3. Traffic Classification . . . . . . . . . . . . . . . . . 8
2.4. Overall DualQ Coupled AQM Structure . . . . . . . . . . . 8 2.4. Overall DualQ Coupled AQM Structure . . . . . . . . . . . 9
2.5. Normative Requirements for a DualQ Coupled AQM . . . . . 11 2.5. Normative Requirements for a DualQ Coupled AQM . . . . . 11
2.5.1. Functional Requirements . . . . . . . . . . . . . . . 11 2.5.1. Functional Requirements . . . . . . . . . . . . . . . 11
2.5.2. Management Requirements . . . . . . . . . . . . . . . 12 2.5.2. Management Requirements . . . . . . . . . . . . . . . 12
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
4.1. Overload Handling . . . . . . . . . . . . . . . . . . . . 13 4.1. Overload Handling . . . . . . . . . . . . . . . . . . . . 13
4.1.1. Avoiding Classic Starvation: Sacrifice L4S Throughput 4.1.1. Avoiding Classic Starvation: Sacrifice L4S Throughput
or Delay? . . . . . . . . . . . . . . . . . . . . . . 14 or Delay? . . . . . . . . . . . . . . . . . . . . . . 14
4.1.2. Congestion Signal Saturation: Introduce L4S Drop or 4.1.2. Congestion Signal Saturation: Introduce L4S Drop or
Delay? . . . . . . . . . . . . . . . . . . . . . . . 15 Delay? . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.3. Protecting against Unresponsive ECN-Capable Traffic . 16 4.1.3. Protecting against Unresponsive ECN-Capable Traffic . 16
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Normative References . . . . . . . . . . . . . . . . . . 17 6.1. Normative References . . . . . . . . . . . . . . . . . . 17
6.2. Informative References . . . . . . . . . . . . . . . . . 17 6.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Example DualQ Coupled PI2 Algorithm . . . . . . . . 20 Appendix A. Example DualQ Coupled PI2 Algorithm . . . . . . . . 20
A.1. Pass #1: Core Concepts . . . . . . . . . . . . . . . . . 20 A.1. Pass #1: Core Concepts . . . . . . . . . . . . . . . . . 20
A.2. Pass #2: Overload Details . . . . . . . . . . . . . . . . 25 A.2. Pass #2: Overload Details . . . . . . . . . . . . . . . . 26
Appendix B. Example DualQ Coupled Curvy RED Algorithm . . . . . 28 Appendix B. Example DualQ Coupled Curvy RED Algorithm . . . . . 28
Appendix C. Guidance on Controlling Throughput Equivalence . . . 34 Appendix C. Guidance on Controlling Throughput Equivalence . . . 34
Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 35 Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
1.1. Problem and Scope 1.1. Problem and Scope
Latency is becoming the critical performance factor for many (most?) Latency is becoming the critical performance factor for many (most?)
skipping to change at page 8, line 35 skipping to change at page 8, line 35
2.3. Traffic Classification 2.3. Traffic Classification
Both the Coupled AQM and DualQ mechanisms need an identifier to Both the Coupled AQM and DualQ mechanisms need an identifier to
distinguish L and C packets. A separate draft distinguish L and C packets. A separate draft
[I-D.ietf-tsvwg-ecn-l4s-id] recommends using the ECT(1) codepoint of [I-D.ietf-tsvwg-ecn-l4s-id] recommends using the ECT(1) codepoint of
the ECN field as this identifier, having assessed various the ECN field as this identifier, having assessed various
alternatives. An additional process document has proved necessary to alternatives. An additional process document has proved necessary to
make the ECT(1) codepoint available for experimentation [RFC8311]. make the ECT(1) codepoint available for experimentation [RFC8311].
In addition (not instead), other identifiers could be used to
classify certain additional packet types into the L queue, that are
deemed not to risk harming the L4S service. For instance addresses
of specific applications or hosts (see [I-D.ietf-tsvwg-ecn-l4s-id]),
specific Diffserv codepoints such as EF (Expedited Forwarding), CS5
(Application Signalling) and Voice-Admit service classes (see
[I-D.briscoe-tsvwg-l4s-diffserv]) or certain protocols (e.g. ARP,
DNS).
Note that the DualQ Coupled AQM only reads these classifiers, it MUST
NOT re-mark or alter these identifiers (except for marking the ECN
field with the CE codepoint - with increasing frequency to indicate
increasing congestion).
2.4. Overall DualQ Coupled AQM Structure 2.4. Overall DualQ Coupled AQM Structure
Figure 1 shows the overall structure that any DualQ Coupled AQM is Figure 1 shows the overall structure that any DualQ Coupled AQM is
likely to have. This schematic is intended to aid understanding of likely to have. This schematic is intended to aid understanding of
the current designs of DualQ Coupled AQMs. However, it is not the current designs of DualQ Coupled AQMs. However, it is not
intended to preclude other innovative ways of satisfying the intended to preclude other innovative ways of satisfying the
normative requirements in Section 2.5 that minimally define a DualQ normative requirements in Section 2.5 that minimally define a DualQ
Coupled AQM. Coupled AQM.
The classifier on the left separates incoming traffic between the two The classifier on the left separates incoming traffic between the two
skipping to change at page 12, line 45 skipping to change at page 12, line 45
affect small flows. affect small flows.
2.5.2. Management Requirements 2.5.2. Management Requirements
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:
o Optional packet classifier(s) to use in addition to the ECN field o Optional packet classifier(s) to use in addition to the ECN field
{ToDo: e.g. ARP}; (see Section 2.3);
o Expected typical RTT (a parameter for typical or target queuing o Expected typical RTT (a parameter for typical or target queuing
delay in each queue might be configurable instead); delay in each queue might be configurable instead);
o Expected maximum RTT (a stability parameter that depends on o Expected maximum RTT (a stability parameter that depends on
maximum RTT might be configurable instead); maximum RTT might be configurable instead);
o Coupling factor, k; o Coupling factor, k;
o The limit to the conditional priority of L4S (scheduler-dependent, o The limit to the conditional priority of L4S (scheduler-dependent,
skipping to change at page 17, line 40 skipping to change at page 17, line 40
All", 2015, <http://www.bobbriscoe.net/projects/latency/ All", 2015, <http://www.bobbriscoe.net/projects/latency/
dctth_preprint.pdf>. dctth_preprint.pdf>.
(Under submission) (Under submission)
[DualQ-Test] [DualQ-Test]
Steen, H., "Destruction Testing: Ultra-Low Delay using Steen, H., "Destruction Testing: Ultra-Low Delay using
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.
[I-D.briscoe-tsvwg-l4s-diffserv]
Briscoe, B., "Interactions between Low Latency, Low Loss,
Scalable Throughput (L4S) and Differentiated Services",
draft-briscoe-tsvwg-l4s-diffserv-00 (work in progress),
March 2018.
[I-D.ietf-tcpm-cubic] [I-D.ietf-tcpm-cubic]
Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
draft-ietf-tcpm-cubic-07 (work in progress), November draft-ietf-tcpm-cubic-07 (work in progress), November
2017. 2017.
[I-D.ietf-tsvwg-ecn-l4s-id] [I-D.ietf-tsvwg-ecn-l4s-id]
Schepper, K., Briscoe, B., and I. Tsang, "Identifying Schepper, K., Briscoe, B., and I. Tsang, "Identifying
Modified Explicit Congestion Notification (ECN) Semantics Modified Explicit Congestion Notification (ECN) Semantics
for Ultra-Low Queuing Delay", draft-ietf-tsvwg-ecn-l4s- for Ultra-Low Queuing Delay", draft-ietf-tsvwg-ecn-l4s-
id-00 (work in progress), November 2016. id-02 (work in progress), March 2018.
[I-D.ietf-tsvwg-l4s-arch] [I-D.ietf-tsvwg-l4s-arch]
Briscoe, B., Schepper, K., and M. Bagnulo, "Low Latency, Briscoe, B., Schepper, K., and M. Bagnulo, "Low Latency,
Low Loss, Scalable Throughput (L4S) Internet Service: Low Loss, Scalable Throughput (L4S) Internet Service:
Architecture", draft-ietf-tsvwg-l4s-arch-00 (work in Architecture", draft-ietf-tsvwg-l4s-arch-02 (work in
progress), November 2016. progress), March 2018.
[I-D.sridharan-tcpm-ctcp] [I-D.sridharan-tcpm-ctcp]
Sridharan, M., Tan, K., Bansal, D., and D. Thaler, Sridharan, M., Tan, K., Bansal, D., and D. Thaler,
"Compound TCP: A New TCP Congestion Control for High-Speed "Compound TCP: A New TCP Congestion Control for High-Speed
and Long Distance Networks", draft-sridharan-tcpm-ctcp-02 and Long Distance Networks", draft-sridharan-tcpm-ctcp-02
(work in progress), November 2008. (work in progress), November 2008.
[Mathis09] [Mathis09]
Mathis, M., "Relentless Congestion Control", PFLDNeT'09 , Mathis, M., "Relentless Congestion Control", PFLDNeT'09 ,
May 2009, <http://www.hpcc.jp/pfldnet2009/ May 2009, <http://www.hpcc.jp/pfldnet2009/
skipping to change at page 23, line 7 skipping to change at page 23, line 15
When packets arrive, first a common queue limit is checked as shown When packets arrive, first a common queue limit is checked as shown
in line 2 of the enqueuing pseudocode in Figure 3. Note that the in line 2 of the enqueuing pseudocode in Figure 3. Note that the
limit is deliberately tested before enqueue to avoid any bias against limit is deliberately tested before enqueue to avoid any bias against
larger packets (so the actual buffer has to be one MTU larger than larger packets (so the actual buffer has to be one MTU larger than
limit). If limit is not exceeded, the packet will be classified and limit). If limit is not exceeded, the packet will be classified and
enqueued to the Classic or L4S queue dependent on the least enqueued to the Classic or L4S queue dependent on the least
significant bit of the ECN field in the IP header (line 5). Packets significant bit of the ECN field in the IP header (line 5). Packets
with a codepoint having an LSB of 0 (Not-ECT and ECT(0)) will be with a codepoint having an LSB of 0 (Not-ECT and ECT(0)) will be
enqueued in the Classic queue. Otherwise, ECT(1) and CE packets will enqueued in the Classic queue. Otherwise, ECT(1) and CE packets will
be enqueued in the L4S queue. Optional additional packet be enqueued in the L4S queue. Optional additional packet
classification flexibility is omitted for brevity. classification flexibility is omitted for brevity (see
[I-D.ietf-tsvwg-ecn-l4s-id]).
The dequeue pseudocode (Figure 4) schedules one packet for dequeuing The dequeue pseudocode (Figure 4) schedules one packet for dequeuing
(or zero if the queue is empty). It also makes all the AQM decisions (or zero if the queue is empty). It also makes all the AQM decisions
on dropping and marking. The alternative of applying the AQMs at on dropping and marking. The alternative of applying the AQMs at
enqueue would shift some processing from the critical time when each enqueue would shift some processing from the critical time when each
packet is dequeued. However, it would also add a whole queue of packet is dequeued. However, it would also add a whole queue of
delay to the control signals, making the control loop very sloppy. delay to the control signals, making the control loop very sloppy.
All the dequeue code is contained within a large while loop so that All the dequeue code is contained within a large while loop so that
if it decides to drop a packet, it will continue until it selects a if it decides to drop a packet, it will continue until it selects a
skipping to change at page 29, line 37 skipping to change at page 29, line 37
17: maxr=0 17: maxr=0
18: while (u-- > 0) 18: while (u-- > 0)
19: maxr = max(maxr, rand()) % 0 <= rand() < 1 19: maxr = max(maxr, rand()) % 0 <= rand() < 1
20: return(maxr) 20: return(maxr)
21: } 21: }
Figure 8: Example Dequeue Pseudocode for DualQ Coupled Curvy RED AQM Figure 8: Example Dequeue Pseudocode for DualQ Coupled Curvy RED AQM
Packet classification code is not shown, as it is no different from Packet classification code is not shown, as it is no different from
Figure 3. Potential classification schemes are discussed in Figure 3. Potential classification schemes are discussed in
Section 2. The Curvy RED algorithm has not been maintained to the Section 2.3. The Curvy RED algorithm has not been maintained to the
same degree as the DualPI2 algorithm. Some ideas used in DualPI2 same degree as the DualPI2 algorithm. Some ideas used in DualPI2
would need to be translated into Curvy RED, such as i) the would need to be translated into Curvy RED, such as i) the
conditional priority scheduler instead of strict priority ii) the conditional priority scheduler instead of strict priority ii) the
time-based L4S threshold; iii) turning off ECN as overload time-based L4S threshold; iii) turning off ECN as overload
protection; iv) Classic ECN support. These are not shown in the protection; iv) Classic ECN support. These are not shown in the
Curvy RED pseudocode, but would need to be implemented for Curvy RED pseudocode, but would need to be implemented for
production. {ToDo} production. {ToDo}
At the outer level, the structure of dualq_dequeue() implements At the outer level, the structure of dualq_dequeue() implements
strict priority scheduling. The code is written assuming the AQM is strict priority scheduling. The code is written assuming the AQM is
skipping to change at page 35, line 48 skipping to change at page 35, line 48
general Internet, a value of k'=1 (equivalent to k=2) is recommended general Internet, a value of k'=1 (equivalent to k=2) is recommended
as a good workable compromise. as a good workable compromise.
Appendix D. Open Issues Appendix D. Open Issues
Most of the following open issues are also tagged '{ToDo}' at the Most of the following open issues are also tagged '{ToDo}' at the
appropriate point in the document: appropriate point in the document:
Operational guidance to monitor L4S experiment Operational guidance to monitor L4S experiment
Interaction between Diffserv & L4S
Define additional classifier flexibility more clearly Define additional classifier flexibility more clearly
PI2 appendix: scaling of alpha & beta, esp. dependence of beta_U PI2 appendix: scaling of alpha & beta, esp. dependence of beta_U
on Tupdate on Tupdate
Curvy RED appendix: complete the unfinished parts Curvy RED appendix: complete the unfinished parts
Authors' Addresses Authors' Addresses
Koen De Schepper Koen De Schepper
Nokia Bell Labs Nokia Bell Labs
Antwerp Antwerp
Belgium Belgium
Email: koen.de_schepper@nokia.com Email: koen.de_schepper@nokia.com
 End of changes. 16 change blocks. 
15 lines changed or deleted 34 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/