draft-ietf-tsvwg-aqm-dualq-coupled-06.txt   draft-ietf-tsvwg-aqm-dualq-coupled-07.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: January 19, 2019 CableLabs Expires: April 25, 2019 CableLabs
O. Bondarenko O. Bondarenko
Simula Research Lab Simula Research Lab
I. Tsang I. Tsang
Nokia Nokia
July 18, 2018 October 22, 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-06 draft-ietf-tsvwg-aqm-dualq-coupled-07
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 January 19, 2019. This Internet-Draft will expire on April 25, 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.1.1. Requirements in Unexpected Cases . . . . . . . . 12 2.5.1.1. Requirements in Unexpected Cases . . . . . . . . 13
2.5.2. Management Requirements . . . . . . . . . . . . . . . 13 2.5.2. Management Requirements . . . . . . . . . . . . . . . 14
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
4.1. Overload Handling . . . . . . . . . . . . . . . . . . . . 14 4.1. Overload Handling . . . . . . . . . . . . . . . . . . . . 15
4.1.1. Avoiding Classic Starvation: Sacrifice L4S Throughput 4.1.1. Avoiding Classic Starvation: Sacrifice L4S Throughput
or Delay? . . . . . . . . . . . . . . . . . . . . . . 15 or Delay? . . . . . . . . . . . . . . . . . . . . . . 15
4.1.2. Congestion Signal Saturation: Introduce L4S Drop or 4.1.2. Congestion Signal Saturation: Introduce L4S Drop or
Delay? . . . . . . . . . . . . . . . . . . . . . . . 16 Delay? . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.3. Protecting against Unresponsive ECN-Capable Traffic . 17 4.1.3. Protecting against Unresponsive ECN-Capable Traffic . 17
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Normative References . . . . . . . . . . . . . . . . . . 18 6.1. Normative References . . . . . . . . . . . . . . . . . . 18
6.2. Informative References . . . . . . . . . . . . . . . . . 18 6.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Example DualQ Coupled PI2 Algorithm . . . . . . . . 21 Appendix A. Example DualQ Coupled PI2 Algorithm . . . . . . . . 21
A.1. Pass #1: Core Concepts . . . . . . . . . . . . . . . . . 21 A.1. Pass #1: Core Concepts . . . . . . . . . . . . . . . . . 21
A.2. Pass #2: Overload Details . . . . . . . . . . . . . . . . 27 A.2. Pass #2: Overload Details . . . . . . . . . . . . . . . . 27
Appendix B. Example DualQ Coupled Curvy RED Algorithm . . . . . 30 Appendix B. Example DualQ Coupled Curvy RED Algorithm . . . . . 30
Appendix C. Guidance on Controlling Throughput Equivalence . . . 36 Appendix C. Guidance on Controlling Throughput Equivalence . . . 36
Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 37 Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
skipping to change at page 7, line 48 skipping to change at page 7, line 48
rate equation for DCTCP, for which cwnd is inversely proportional to rate equation for DCTCP, for which cwnd is inversely proportional to
p (not the square root), where in this case p is the ECN marking p (not the square root), where in this case p is the ECN marking
probability. DCTCP is not the only congestion control that behaves probability. DCTCP is not the only congestion control that behaves
like this, so the term 'L4S' traffic will be used for all similar like this, so the term 'L4S' traffic will be used for all similar
behaviour. behaviour.
In order to make a DCTCP flow run at roughly the same rate as a Reno In order to make a DCTCP flow run at roughly the same rate as a Reno
TCP flow (all other factors being equal), the drop or marking TCP flow (all other factors being equal), the drop or marking
probability for Classic traffic, p_C has to be distinct from the probability for Classic traffic, p_C has to be distinct from the
marking probability for L4S traffic, p_L (in contrast to RFC3168 marking probability for L4S traffic, p_L (in contrast to RFC3168
which requires them to be the same). It is necessary to make the which requires them to be the same). To remain stable, Classic
Classic drop probability p_C proportional to the square of the L4S traffic needs p_C to change relatively slowly, whereas L4S traffic
marking probability p_L. This makes the Reno flow rate roughly equal needs to be controlled rapidly by a probability p_L that track the
the DCTCP flow rate, because it squares the square root of p_C in the instantaneous queue. It is necessary to make the Classic drop
Reno rate equation to make it proportional to the straight p_L in the probability p_C proportional to the square of a variable we shall
DCTCP rate equation. call p_CL, which is an input to the instantaneous L4S marking
probability p_L but changes as slowly as p_C. This makes the Reno
flow rate roughly equal the DCTCP flow rate, because it squares the
square root of p_C in the Reno rate equation to make it proportional
to the smoothed value of p_L used in the DCTCP rate equation.
Stating this as a formula, the relation between Classic drop Stating this as a formula, the relation between Classic drop
probability, p_C, and L4S marking probability, p_L needs to take the probability, p_C, and the input variable p_CL to the L4S marking
form: probability p_L needs to take the form:
p_C = ( p_L / k )^2 (1) p_C = ( p_CL / k )^2 (1)
where k is the constant of proportionality. where k is the constant of proportionality.
2.2. Dual Queue 2.2. Dual Queue
Classic traffic typically builds a large queue to prevent under- Classic traffic typically builds a large queue to prevent under-
utilization. Therefore a separate queue is provided for L4S traffic, utilization. Therefore a separate queue is provided for L4S traffic,
and it is scheduled with priority over Classic. Priority is and it is scheduled with priority over Classic. Priority is
conditional to prevent starvation of Classic traffic. conditional to prevent starvation of Classic traffic.
skipping to change at page 9, line 23 skipping to change at page 9, line 29
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
queues (L and C). Each queue has its own AQM that determines the queues (L and C). Each queue has its own AQM that determines the
likelihood of dropping or marking (p_L and p_C). Nonetheless, the likelihood of marking or dropping (p_L and p_C). It has been proved
AQM for Classic traffic is implemented in two stages: i) a base stage [PI2] that it is preferable to control TCP with a linear PI
that outputs an internal probability p' (pronounced p-prime); and ii) controller, then square the output before applying it as a drop
a squaring stage that outputs p_C, where probability to TCP. So, the AQM for Classic traffic needs to be
implemented in two stages: i) a base stage that outputs an internal
probability p' (pronounced p-prime); and ii) a squaring stage that
outputs p_C, where
p_C = (p')^2. (2) p_C = (p')^2. (2)
This allows p_L to be coupled to p_C by marking L4S traffic Substituting for p_C in Eqn (1) gives:
proportionately to the intermediate output from the first stage.
Specifically, the output of the base AQM is coupled across to the L p' = p_CL / k
queue in proportion to the output of the base AQM:
So we get our slow-moving input to ECN marking in the L queue as:
p_CL = k*p', (3) p_CL = k*p', (3)
where k is the constant coupling factor (see Appendix C) and p_CL is where k is the constant coupling factor (see Appendix C).
the output from the coupling between the C queue and the L queue.
It can be seen in the following that these two transformations of p' It can be seen that these two transformations of p' implement the
implement the required coupling given in equation (1) earlier. required coupling given in equation (1) earlier. Substituting for p'
Substituting for p' from equation (3) into (2): from equation (3) into (2):
p_C = ( p_CL / k )^2. p_C = ( p_CL / k )^2.
The actual L4S marking probability p_L is the maximum of the coupled The actual probability p_L that we apply to the L queue needs to
output (p_CL) and the output of a native L4S AQM (p'L), shown as track the immediate L queue delay, as well as track p_CL under
'(MAX)' in the schematic. While the output of the Native L4S AQM is stationary conditions. So we use a native AQM in the L queue that
high (p'L > p_CL) it will dominate the way L traffic is marked. When calculates a marking probability p'L as a function of the
the native L4S AQM output is lower, the way L traffic is marked will instantaneous L queue. And, given the L queue has conditional strict
be driven by the coupling, that is p_L = p_CL. So, whenever the priority over the C queue, whenever the L queue grows, we should
coupling is needed, as required from equation (1): apply marking probability p'_L, but p_L should not fall below p_CL.
This suggests:
p_C = ( p_L / k )^2. p_L = max(p'L, p_CL),
which has also been found to work very well in practice.
This allows p_L to be coupled to p_C by marking L4S traffic
proportionately to the intermediate output from the first stage.
Specifically, the output of the base AQM is coupled across to the L
queue in proportion to the output of the base AQM
_________ _________
| | ,------. | | ,------.
L4S queue | |===>| ECN | L4S queue | |===>| ECN |
,'| _______|_| |marker|\ ,'| _______|_| |marker|\
<' | | `------'\\ <' | | `------'\\
//`' v ^ p_L \\ //`' v ^ p_L \\
// ,-------. | \\ // ,-------. | \\
// |Native |p'L | \\,. // |Native |p'L | \\,.
// | L4S |-->(MAX) < | ___ // | L4S |-->(MAX) < | ___
skipping to change at page 13, line 5 skipping to change at page 13, line 18
leads to the need to specify what the AQM in each queue ought to do 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. 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 It is recommended that the AQM in each queue inspects the ECN field
to determine what sort of congestion notification to signal, then to determine what sort of congestion notification to signal, then
decides whether to apply congestion notification to this particular decides whether to apply congestion notification to this particular
packet, as follows: packet, as follows:
o If a packet that does not carry an ECT(1) or CE codepoint is o If a packet that does not carry an ECT(1) or CE codepoint is
classified into the L queue: classified into the L queue:
* if the packet is ECT(0), the L AQM SHOULD apply drop using a * if the packet is ECT(0), the L AQM SHOULD apply CE-marking
drop probability appropriate to Classic congestion control and using a probability appropriate to Classic congestion control
appropriate to the target delay in the L queue and appropriate to the target delay in the L queue
* if the packet is Not-ECT, the appropriate action depends on * if the packet is Not-ECT, the appropriate action depends on
whether some other function is protecting the L queue from whether some other function is protecting the L queue from
misbehaving flows (e.g. per-flow queue protection or latency misbehaving flows (e.g. per-flow queue protection or latency
policing): policing):
+ If separate queue protection is provided, the L AQM SHOULD + If separate queue protection is provided, the L AQM SHOULD
ignore the packet and forward it unchanged, meaning it ignore the packet and forward it unchanged, meaning it
should not calculate whether to apply congestion should not calculate whether to apply congestion
notification and it should neither drop nor CE-mark the notification and it should neither drop nor CE-mark the
skipping to change at page 14, line 26 skipping to change at page 14, line 38
o The maximum Classic ECN marking probability, p_Cmax, before o The maximum Classic ECN marking probability, p_Cmax, before
switching over to drop. switching over to drop.
An experimental DualQ Coupled AQM SHOULD allow the operator to An experimental DualQ Coupled AQM SHOULD allow the operator to
monitor the following operational statistics: monitor the following operational statistics:
o Bits forwarded (total and per queue per sample interval), from o Bits forwarded (total and per queue per sample interval), from
which utilization can be calculated which utilization can be calculated
o Q delay (per queue over sample interval) o Q delay (per queue over sample interval) {ToDo: max per interval,
histogram with configurable edges (from which percentile(s) can be
derived), not incl. medium access delay}
o Total packets arriving, enqueued and dequeued (per queue per o Total packets arriving, enqueued and dequeued (per queue per
sample interval) sample interval)
o ECN packets marked, non-ECN packets dropped, ECN packets dropped o ECN packets marked, non-ECN packets dropped, ECN packets dropped
(per queue per sample interval), from which marking and dropping (per queue per sample interval), from which marking and dropping
probabilities can be calculated probabilities can be calculated
o Time and duration of each overload event. o Time and duration of each overload event.
skipping to change at page 23, line 12 skipping to change at page 23, line 12
explained as it is encountered in the walk-through of the pseudocode explained as it is encountered in the walk-through of the pseudocode
below. below.
1: dualpi2_params_init(...) { % Set input parameter defaults 1: dualpi2_params_init(...) { % Set input parameter defaults
2: % PI2 AQM parameters 2: % PI2 AQM parameters
3: target = 15 ms % PI AQM Classic queue delay target 3: target = 15 ms % PI AQM Classic queue delay target
4: Tupdate = 16 ms % PI Classic queue sampling interval 4: Tupdate = 16 ms % PI Classic queue sampling interval
5: alpha = 10 Hz^2 % PI integral gain 5: alpha = 10 Hz^2 % PI integral gain
6: beta = 100 Hz^2 % PI proportional gain 6: beta = 100 Hz^2 % PI proportional gain
7: p_Cmax = 1/4 % Max Classic drop/mark prob 7: p_Cmax = 1/4 % Max Classic drop/mark prob
8: % Derived PI2 AQM variables 8: % Constants derived from PI2 AQM parameters
9: alpha_U = alpha *Tupdate % PI integral gain per update interval 9: alpha_U = alpha *Tupdate % PI integral gain per update interval
10: beta_U = beta * Tupdate % PI prop'nal gain per update interval 10: beta_U = beta * Tupdate % PI prop'nal gain per update interval
11: 11:
12: % DualQ Coupled framework parameters 12: % DualQ Coupled framework parameters
13: k = 2 % Coupling factor 13: k = 2 % Coupling factor
14: % scheduler weight or equival't parameter (scheduler-dependent) 14: % scheduler weight or equival't parameter (scheduler-dependent)
15: limit = MAX_LINK_RATE * 250 ms % Dual buffer size 15: limit = MAX_LINK_RATE * 250 ms % Dual buffer size
16: 16:
17: % L4S AQM parameters 17: % L4S AQM parameters
18: T_time = 1 ms % L4S marking threshold in time 18: T_time = 1 ms % L4S marking threshold in time
19: T_len = 2 * MTU % Min L4S marking threshold in bytes 19: T_len = 2 * MTU % Min L4S marking threshold in bytes
20: % Derived L4S AQM variables 20: % Constants derived from L4S AQM parameters
21: p_Lmax = min(k*sqrt(p_Cmax), 1) % Max L4S marking prob 21: p_Lmax = min(k*sqrt(p_Cmax), 1) % Max L4S marking prob
22: } 22: }
Figure 2: Example Header Pseudocode for DualQ Coupled PI2 AQM Figure 2: Example Header Pseudocode for DualQ Coupled PI2 AQM
The overall goal of the code is to maintain the base probability (p), The overall goal of the code is to maintain the base probability (p),
which is an internal variable from which the marking and dropping which is an internal variable from which the marking and dropping
probabilities for L4S and Classic traffic (p_L and p_C) are derived. probabilities for L4S and Classic traffic (p_L and p_C) are derived.
The variable named p in the pseudocode and in this walk-through is The variable named p in the pseudocode and in this walk-through is
the same as p' (p-prime) in Section 2.4. The probabilities p_L and the same as p' (p-prime) in Section 2.4. The probabilities p_L and
skipping to change at page 24, line 9 skipping to change at page 24, line 9
8: cq.enqueue(pkt) 8: cq.enqueue(pkt)
9: } 9: }
10: } 10: }
Figure 3: Example Enqueue Pseudocode for DualQ Coupled PI2 AQM Figure 3: Example Enqueue Pseudocode for DualQ Coupled PI2 AQM
1: dualpi2_dequeue(lq, cq, pkt) { % Couples L4S & Classic queues 1: dualpi2_dequeue(lq, cq, pkt) { % Couples L4S & Classic queues
2: while ( lq.len() + cq.len() > 0 ) 2: while ( lq.len() + cq.len() > 0 )
3: if ( scheduler() == lq ) { 3: if ( scheduler() == lq ) {
4: lq.dequeue(pkt) % Scheduler chooses lq 4: lq.dequeue(pkt) % Scheduler chooses lq
{ToDo: Generalize 5-7 for any L AQM (see email to Tom 9-Aug-18)}
5: if ( ((lq.time() > T_time) % step marking ... 5: if ( ((lq.time() > T_time) % step marking ...
6: AND (lq.len() > T_len)) 6: AND (lq.len() > T_len))
7: OR (p_CL > rand()) ) % ...or linear marking 7: OR (p_CL > rand()) ) % ...or linear marking
8: mark(pkt) 8: mark(pkt)
9: } else { 9: } else {
10: cq.dequeue(pkt) % Scheduler chooses cq 10: cq.dequeue(pkt) % Scheduler chooses cq
11: if ( p_C > rand() ) { % probability p_C = p^2 11: if ( p_C > rand() ) { % probability p_C = p^2
12: if ( ecn(pkt) == 0 ) { % if ECN field = not-ECT 12: if ( ecn(pkt) == 0 ) { % if ECN field = not-ECT
13: drop(pkt) % squared drop 13: drop(pkt) % squared drop
14: continue % continue to the top of the while loop 14: continue % continue to the top of the while loop
skipping to change at page 24, line 33 skipping to change at page 24, line 36
19: return(pkt) % return the packet and stop 19: return(pkt) % return the packet and stop
20: } 20: }
21: return(NULL) % no packet to dequeue 21: return(NULL) % no packet to dequeue
22: } 22: }
Figure 4: Example Dequeue Pseudocode for DualQ Coupled PI2 AQM Figure 4: Example Dequeue Pseudocode for DualQ Coupled PI2 AQM
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 depending whether the implementation stores a
limit). If limit is not exceeded, the packet will be classified and packet while testing whether to drop it from the tail, it might be
enqueued to the Classic or L4S queue dependent on the least necessary for the actual buffer memory to be one MTU larger than
significant bit of the ECN field in the IP header (line 5). Packets limit).
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 Line 2 assumes an implementation where lq and cq share common buffer
be enqueued in the L4S queue. Optional additional packet memory. An alternative implementation could use separate buffers for
classification flexibility is omitted for brevity (see each queue, in which case the arriving packet would have to be
[I-D.ietf-tsvwg-ecn-l4s-id]). classified first to determine which buffer to check for available
space. The choice is a trade off; a shared buffer can use less
memory whereas separate buffers isolate the L4S queue from tail-drop
due to large bursts of Classic traffic (e.g. a Classic TCP during
slow-start over a long RTT).
Returning to the shared buffer case, if limit is not exceeded, the
packet will be classified and enqueued to the Classic or L4S queue
dependent on the least 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 enqueued in the Classic queue. Otherwise,
ECT(1) and CE packets will be enqueued in the L4S queue. Optional
additional packet classification flexibility is omitted for brevity
(see [I-D.ietf-tsvwg-ecn-l4s-id]).
The dequeue pseudocode (Figure 4) is repeatedly called whenever the The dequeue pseudocode (Figure 4) is repeatedly called whenever the
lower layer is ready to forward a packet. It schedules one packet lower layer is ready to forward a packet. It schedules one packet
for dequeuing (or zero if the queue is empty) then returns control to for dequeuing (or zero if the queue is empty) then returns control to
the caller, so that it does not block while that packet is being the caller, so that it does not block while that packet is being
forwarded. While making this dequeue decision, it also makes the forwarded. While making this dequeue decision, it also makes the
necessary AQM decisions on dropping or marking. The alternative of necessary AQM decisions on dropping or marking. The alternative of
applying the AQMs at enqueue would shift some processing from the applying the AQMs at enqueue would shift some processing from the
critical time when each packet is dequeued. However, it would also critical time when each packet is dequeued. However, it would also
add a whole queue of delay to the control signals, making the control add a whole queue of delay to the control signals, making the control
skipping to change at page 28, line 11 skipping to change at page 28, line 29
ensure that the L4S queue starts to introduce dropping once marking ensure that the L4S queue starts to introduce dropping once marking
saturates and can rise no further. The 'TCP Prague' requirements saturates and can rise no further. The 'TCP Prague' requirements
[I-D.ietf-tsvwg-ecn-l4s-id] state that, when an L4S congestion [I-D.ietf-tsvwg-ecn-l4s-id] state that, when an L4S congestion
control detects a drop, it falls back to a response that coexists control detects a drop, it falls back to a response that coexists
with 'Classic' TCP. So it is correct that the L4S queue drops with 'Classic' TCP. So it is correct that the L4S queue drops
packets proportional to p^2, as if they are Classic packets. packets proportional to p^2, as if they are Classic packets.
Both these switch-overs are triggered by the tests for overload Both these switch-overs are triggered by the tests for overload
introduced in lines 4b and 12b of the dequeue function (Figure 6). introduced in lines 4b and 12b of the dequeue function (Figure 6).
Lines 8c to 8g drop L4S packets with probability p^2. Lines 8h to 8i Lines 8c to 8g drop L4S packets with probability p^2. Lines 8h to 8i
mark the remaining packets with probability p_CL. mark the remaining packets with probability p_CL. If p_Lmax = 1,
which is the suggested default configuration, all remaining packets
will be marked because, to have reached the else block at line 8b,
p_CL >= 1.
Lines 2c to 2d in the core PI algorithm (Figure 7) deal with overload Lines 2c to 2d in the core PI algorithm (Figure 7) deal with overload
of the L4S queue when there is no Classic traffic. This is of the L4S queue when there is no Classic traffic. This is
necessary, because the core PI algorithm maintains the appropriate necessary, because the core PI algorithm maintains the appropriate
drop probability to regulate overload, but it depends on the length drop probability to regulate overload, but it depends on the length
of the Classic queue. If there is no Classic queue the naive of the Classic queue. If there is no Classic queue the naive
algorithm in Figure 5 drops nothing, even if the L4S queue is algorithm in Figure 5 drops nothing, even if the L4S queue is
overloaded - so tail drop would have to take over (lines 3 and 4 of overloaded - so tail drop would have to take over (lines 3 and 4 of
Figure 3). Figure 3).
 End of changes. 22 change blocks. 
56 lines changed or deleted 92 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/