draft-ietf-tsvwg-aqm-dualq-coupled-04.txt   draft-ietf-tsvwg-aqm-dualq-coupled-05.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: September 6, 2018 CableLabs Expires: January 3, 2019 CableLabs
O. Bondarenko O. Bondarenko
Simula Research Lab Simula Research Lab
I. Tsang I. Tsang
Nokia Nokia
March 5, 2018 July 2, 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-04 draft-ietf-tsvwg-aqm-dualq-coupled-05
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 September 6, 2018. This Internet-Draft will expire on January 3, 2019.
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 37 skipping to change at page 2, line 37
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 . . . . . . . . . . . 9 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.1.1. Requirements in Unexpected Cases . . . . . . . . 12
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 2.5.2. Management Requirements . . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
4.1. Overload Handling . . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
4.1. Overload Handling . . . . . . . . . . . . . . . . . . . . 14
4.1.1. Avoiding Classic Starvation: Sacrifice L4S Throughput 4.1.1. Avoiding Classic Starvation: Sacrifice L4S Throughput
or Delay? . . . . . . . . . . . . . . . . . . . . . . 14 or Delay? . . . . . . . . . . . . . . . . . . . . . . 15
4.1.2. Congestion Signal Saturation: Introduce L4S Drop or 4.1.2. Congestion Signal Saturation: Introduce L4S Drop or
Delay? . . . . . . . . . . . . . . . . . . . . . . . 15 Delay? . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.3. Protecting against Unresponsive ECN-Capable Traffic . 16 4.1.3. Protecting against Unresponsive ECN-Capable Traffic . 17
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Normative References . . . . . . . . . . . . . . . . . . 17 6.1. Normative References . . . . . . . . . . . . . . . . . . 18
6.2. Informative References . . . . . . . . . . . . . . . . . 17 6.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Example DualQ Coupled PI2 Algorithm . . . . . . . . 20 Appendix A. Example DualQ Coupled PI2 Algorithm . . . . . . . . 21
A.1. Pass #1: Core Concepts . . . . . . . . . . . . . . . . . 20 A.1. Pass #1: Core Concepts . . . . . . . . . . . . . . . . . 21
A.2. Pass #2: Overload Details . . . . . . . . . . . . . . . . 26 A.2. Pass #2: Overload Details . . . . . . . . . . . . . . . . 27
Appendix B. Example DualQ Coupled Curvy RED Algorithm . . . . . 28 Appendix B. Example DualQ Coupled Curvy RED Algorithm . . . . . 29
Appendix C. Guidance on Controlling Throughput Equivalence . . . 34 Appendix C. Guidance on Controlling Throughput Equivalence . . . 35
Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 35 Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
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?)
applications on the public Internet, e.g. interactive Web, Web applications on the public Internet, e.g. interactive Web, Web
services, voice, conversational video, interactive video, interactive services, voice, conversational video, interactive video, interactive
remote presence, instant messaging, online gaming, remote desktop, remote presence, instant messaging, online gaming, remote desktop,
cloud-based applications, and video-assisted remote control of cloud-based applications, and video-assisted remote control of
skipping to change at page 4, line 42 skipping to change at page 4, line 44
(transcontinental) RTT, which could be hundreds of times the actual (transcontinental) RTT, which could be hundreds of times the actual
RTT of typical traffic from localized CDNs. RTT of typical traffic from localized CDNs.
Latency is not our only concern: Latency is not our only concern:
3. It was known when TCP was first developed that it would not scale 3. It was known when TCP was first developed that it would not scale
to high bandwidth-delay products. to high bandwidth-delay products.
Given regular broadband bit-rates over WAN distances are Given regular broadband bit-rates over WAN distances are
already [RFC3649] beyond the scaling range of `classic' TCP Reno, already [RFC3649] beyond the scaling range of `classic' TCP Reno,
`less unscalable' Cubic [I-D.ietf-tcpm-cubic] and `less unscalable' Cubic [RFC8312] and
Compound [I-D.sridharan-tcpm-ctcp] variants of TCP have been Compound [I-D.sridharan-tcpm-ctcp] variants of TCP have been
successfully deployed. However, these are now approaching their successfully deployed. However, these are now approaching their
scaling limits. Unfortunately, fully scalable TCPs such as DCTCP scaling limits. Unfortunately, fully scalable TCPs such as DCTCP
cause `classic' TCP to starve itself, which is why they have been cause `classic' TCP to starve itself, which is why they have been
confined to private data centres or research testbeds (until now). confined to private data centres or research testbeds (until now).
This document specifies a `DualQ Coupled AQM' extension that solves This document specifies a `DualQ Coupled AQM' extension that solves
the problem of coexistence between scalable and classic flows, the problem of coexistence between scalable and classic flows,
without having to inspect flow identifiers. The AQM is not like without having to inspect flow identifiers. The AQM is not like
flow-queuing approaches [RFC8290] that classify packets by flow flow-queuing approaches [RFC8290] that classify packets by flow
skipping to change at page 8, line 35 skipping to change at page 8, line 37
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 For policy reasons, an operator might choose to steer certain packets
classify certain additional packet types into the L queue, that are (e.g. from certain flows or with certain addresses) out of the L
deemed not to risk harming the L4S service. For instance addresses queue, even though they identify themselves as L4S by their ECN
of specific applications or hosts (see [I-D.ietf-tsvwg-ecn-l4s-id]), codepoints. In such cases, the classifier MUST NOT alter the ECN
specific Diffserv codepoints such as EF (Expedited Forwarding), CS5 field, so that it is preserved end-to-end. The aim is that each
(Application Signalling) and Voice-Admit service classes (see operator can choose how it treats L4S traffic locally, but an
[I-D.briscoe-tsvwg-l4s-diffserv]) or certain protocols (e.g. ARP, individual operator does not alter the identification of L4S packets,
DNS). which would prevent other operators downstream from making their own
choices on how to treat L4S traffic.
In addition, 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) 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 Note that the DualQ Coupled AQM only reads these classifiers, it MUST
NOT re-mark or alter these identifiers (except for marking the ECN NOT re-mark or alter these identifiers (except for marking the ECN
field with the CE codepoint - with increasing frequency to indicate field with the CE codepoint - with increasing frequency to indicate
increasing congestion). 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
skipping to change at page 11, line 35 skipping to change at page 11, line 38
The following requirements are intended to capture only the essential The following requirements are intended to capture only the essential
aspects of a DualQ Coupled AQM. They are intended to be independent aspects of a DualQ Coupled AQM. They are intended to be independent
of the particular AQMs used for each queue. of the particular AQMs used for each queue.
2.5.1. Functional Requirements 2.5.1. Functional Requirements
In the Dual Queue, L4S packets MUST be given priority over Classic, In the Dual Queue, L4S packets MUST be given priority over Classic,
although priority MUST be bounded in order not to starve Classic although priority MUST be bounded in order not to starve Classic
traffic. traffic.
All L4S traffic MUST be ECN-capable. Some Classic traffic might also
be ECN-capable.
Whatever identifier is used for L4S experiments, Whatever identifier is used for L4S experiments,
[I-D.ietf-tsvwg-ecn-l4s-id] defines the meaning of an ECN marking on [I-D.ietf-tsvwg-ecn-l4s-id] defines the meaning of an ECN marking on
L4S traffic, relative to drop of Classic traffic. In order to L4S traffic, relative to drop of Classic traffic. In order to
prevent starvation of Classic traffic by scalable L4S traffic, it prevent starvation of Classic traffic by scalable L4S traffic, it
says, "The likelihood that an AQM drops a Not-ECT Classic packet says, "The likelihood that an AQM drops a Not-ECT Classic packet
(p_C) MUST be roughly proportional to the square of the likelihood (p_C) MUST be roughly proportional to the square of the likelihood
that it would have marked it if it had been an L4S packet (p_L)." In that it would have marked it if it had been an L4S packet (p_L)." In
other words, in any DualQ Coupled AQM, the power to which p_L is other words, in any DualQ Coupled AQM, the power to which p_L is
raised in Eqn. (1) MUST be 2. The term 'likelihood' is used to allow raised in Eqn. (1) MUST be 2. The term 'likelihood' is used to allow
for marking and dropping to be either probabilistic or deterministic. for marking and dropping to be either probabilistic or deterministic.
skipping to change at page 12, line 37 skipping to change at page 12, line 39
However, on the public Internet, access network operators typically However, on the public Internet, access network operators typically
isolate customers from each other with some form of layer-2 isolate customers from each other with some form of layer-2
multiplexing (TDM in DOCSIS, CDMA in 3G) or L3 scheduling (WRR in multiplexing (TDM in DOCSIS, CDMA in 3G) or L3 scheduling (WRR in
DSL), rather than relying on TCP to share capacity between customers DSL), rather than relying on TCP to share capacity between customers
[RFC0970]. In such cases, the choice of k will solely affect [RFC0970]. In such cases, the choice of k will solely affect
relative flow rates within each customer's access capacity, not relative flow rates within each customer's access capacity, not
between customers. Also, k will not affect relative flow rates at between customers. Also, k will not affect relative flow rates at
any times when all flows are Classic or all L4S, and it will not any times when all flows are Classic or all L4S, and it will not
affect small flows. affect small flows.
2.5.1.1. Requirements in Unexpected Cases
The flexibility to allow operator-specific classifiers (Section 2.3)
leads to the need to specify what the AQM in each queue ought to do
with packets that do not carry the ECN field expected for that queue.
It is recommended that the AQM in each queue inspects the ECN field
to determine what sort of congestion notification to signal, then
decides whether to apply congestion notification to this particular
packet, as follows:
o If a packet that does not carry an ECT(1) or CE codepoint is
classified into the L queue:
* if the packet is ECT(0), the L AQM SHOULD apply CE-marking as
if the packet were ECT(1)
* if the packet is Not-ECT, the appropriate action depends on
whether some other function is protecting the L queue from
misbehaving flows (e.g. per-flow queue protection or policing):
+ If separate queue protection is provided, the L AQM SHOULD
ignore the packet and forward it unchanged, meaning it
should not calculate whether to apply congestion
notification and it should neither drop nor CE-mark the
packet (for instance, the operator might classify EF traffic
that is unresponsive to drop into the L queue, alongside
responsive L4S-ECN traffic)
+ if separate queue protection is not provided, the L AQM MUST
apply drop using the drop probability appropriate to the C
queue
o If a packet that carries an ECT(1) or CE codepoint is classified
into the C queue:
* the C AQM SHOULD apply CE-marking as if the packet were ECT(0).
If the DualQ Coupled AQM has detected overload, it will signal
congestion solely using drop, irrespective of the ECN field.
Most of the above requirements are worded as "SHOULDs", because
operator-specific classifiers are for flexibility, by definition.
Therefore, alternative actions might be appropriate in the operator's
specific circumstances.
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
(see Section 2.3); (see Section 2.3);
skipping to change at page 17, line 46 skipping to change at page 18, line 46
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] [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",
draft-briscoe-tsvwg-l4s-diffserv-00 (work in progress), draft-briscoe-tsvwg-l4s-diffserv-00 (work in progress),
March 2018. March 2018.
[I-D.ietf-tcpm-cubic]
Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
draft-ietf-tcpm-cubic-07 (work in progress), November
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-02 (work in progress), March 2018. 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-02 (work in Architecture", draft-ietf-tsvwg-l4s-arch-02 (work in
skipping to change at page 20, line 10 skipping to change at page 21, line 5
J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler
and Active Queue Management Algorithm", RFC 8290, and Active Queue Management Algorithm", RFC 8290,
DOI 10.17487/RFC8290, January 2018, DOI 10.17487/RFC8290, January 2018,
<https://www.rfc-editor.org/info/rfc8290>. <https://www.rfc-editor.org/info/rfc8290>.
[RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion
Notification (ECN) Experimentation", RFC 8311, Notification (ECN) Experimentation", RFC 8311,
DOI 10.17487/RFC8311, January 2018, DOI 10.17487/RFC8311, January 2018,
<https://www.rfc-editor.org/info/rfc8311>. <https://www.rfc-editor.org/info/rfc8311>.
[RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
RFC 8312, DOI 10.17487/RFC8312, February 2018,
<https://www.rfc-editor.org/info/rfc8312>.
Appendix A. Example DualQ Coupled PI2 Algorithm Appendix A. Example DualQ Coupled PI2 Algorithm
As a first concrete example, the pseudocode below gives the DualPI2 As a first concrete example, the pseudocode below gives the DualPI2
algorithm. DualPI2 follows the structure of the DualQ Coupled AQM algorithm. DualPI2 follows the structure of the DualQ Coupled AQM
framework in Figure 1. A simple step threshold (in units of queuing framework in Figure 1. A simple step threshold (in units of queuing
time) is used for the Native L4S AQM, but a ramp is also described as time) is used for the Native L4S AQM, but a ramp is also described as
an alternative. And the PI2 algorithm [PI2] is used for the Classic an alternative. And the PI2 algorithm [PI2] is used for the Classic
AQM. PI2 is an improved variant of the PIE AQM [RFC8033]. AQM. PI2 is an improved variant of the PIE AQM [RFC8033].
We will introduce the pseudocode in two passes. The first pass We will introduce the pseudocode in two passes. The first pass
skipping to change at page 23, line 18 skipping to change at page 24, line 18
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 (see classification flexibility is omitted for brevity (see
[I-D.ietf-tsvwg-ecn-l4s-id]). [I-D.ietf-tsvwg-ecn-l4s-id]).
The dequeue pseudocode (Figure 4) schedules one packet for dequeuing The dequeue pseudocode (Figure 4) is repeatedly called whenever the
(or zero if the queue is empty). It also makes all the AQM decisions lower layer is ready to forward a packet. It schedules one packet
on dropping and marking. The alternative of applying the AQMs at for dequeuing (or zero if the queue is empty) then returns control to
enqueue would shift some processing from the critical time when each the caller, so that it does not block while that packet is being
packet is dequeued. However, it would also add a whole queue of forwarded. While making this dequeue decision, it also makes the
delay to the control signals, making the control loop very sloppy. necessary AQM decisions on dropping or marking. The alternative of
applying the AQMs at enqueue would shift some processing from the
critical time when each packet is dequeued. However, it would also
add a whole queue of 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
packet to schedule. Line 3 of the dequeue pseudocode is where the packet to schedule. Line 3 of the dequeue pseudocode is where the
scheduler chooses between the L4S queue (lq) and the Classic queue scheduler chooses between the L4S queue (lq) and the Classic queue
(cq). Detailed implementation of the scheduler is not shown (see (cq). Detailed implementation of the scheduler is not shown (see
discussion later). discussion later).
o If an L4S packet is scheduled, lines 5 to 8 mark the packet if o If an L4S packet is scheduled, lines 5 to 8 mark the packet if
either the L4S threshold (T_time) is exceeded, or if a random either the L4S threshold (T_time) is exceeded, or if a random
skipping to change at page 28, line 11 skipping to change at page 29, line 11
Figure 6: Example Dequeue Pseudocode for DualQ Coupled PI2 AQM Figure 6: Example Dequeue Pseudocode for DualQ Coupled PI2 AQM
(Including Integer Arithmetic and Overload Code) (Including Integer Arithmetic and Overload Code)
1: dualpi2_update(lq, cq, target) { % Update p every Tupdate 1: dualpi2_update(lq, cq, target) { % Update p every Tupdate
2a: if ( cq.len() > 0 ) 2a: if ( cq.len() > 0 )
2b: curq = cq.time() %use queuing time of first-in Classic packet 2b: curq = cq.time() %use queuing time of first-in Classic packet
2c: else % Classic queue empty 2c: else % Classic queue empty
2d: curq = lq.time() % use queuing time of first-in L4S packet 2d: curq = lq.time() % use queuing time of first-in L4S packet
3: p = p + alpha_U * (curq - target) + beta_U * (curq - prevq) 3: p = p + alpha_U * (curq - target) + beta_U * (curq - prevq)
4: p_CL = p * k % L4S prob = base prob * coupling factor 4: p_CL = p * k % Coupled L4S prob = base prob * coupling factor
5: p_C = p^2 % Classic prob = (base prob)^2 5: p_C = p^2 % Classic prob = (base prob)^2
6: prevq = curq 6: prevq = curq
7: } 7: }
Figure 7: Example PI-Update Pseudocode for DualQ Coupled PI2 AQM Figure 7: Example PI-Update Pseudocode for DualQ Coupled PI2 AQM
(Including Overload Code) (Including Overload Code)
The choice of scheduler technology is critical to overload protection The choice of scheduler technology is critical to overload protection
(see Section 4.1). (see Section 4.1).
skipping to change at page 35, line 48 skipping to change at page 36, 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
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. 17 change blocks. 
49 lines changed or deleted 103 lines changed or added

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