< draft-ietf-tsvwg-aqm-dualq-coupled-25e.txt   draft-ietf-tsvwg-aqm-dualq-coupled-25f.txt >
skipping to change at page 2, line 52 skipping to change at page 2, line 52
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
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. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1. Normative References . . . . . . . . . . . . . . . . . . 28 5.1. Normative References . . . . . . . . . . . . . . . . . . 28
5.2. Informative References . . . . . . . . . . . . . . . . . 29 5.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Example DualQ Coupled PI2 Algorithm . . . . . . . . 34 Appendix A. Example DualQ Coupled PI2 Algorithm . . . . . . . . 35
A.1. Pass #1: Core Concepts . . . . . . . . . . . . . . . . . 35 A.1. Pass #1: Core Concepts . . . . . . . . . . . . . . . . . 35
A.2. Pass #2: Edge-Case Details . . . . . . . . . . . . . . . 46 A.2. Pass #2: Edge-Case Details . . . . . . . . . . . . . . . 46
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
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 64 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 64
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 64
skipping to change at page 3, line 43 skipping to change at page 3, line 43
to a single queue. The DualQ design has low complexity and requires to a single queue. The DualQ design has low complexity and requires
no configuration for the public Internet. no configuration for the public Internet.
1.1. Outline of the Problem 1.1. Outline of the Problem
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
machinery and industrial processes. In the developed world, further machinery and industrial processes. Once access network bit rates
increases in access network bit-rate offer diminishing returns, reach levels now common in the developed world, further increases
whereas latency is still a multi-faceted problem. In the last decade offer diminishing returns unless latency is also addressed
or so, much has been done to reduce propagation time by placing [Dukkipati06]. In the last decade or so, much has been done to
caches or servers closer to users. However, queuing remains a major reduce propagation time by placing caches or servers closer to users.
intermittent component of latency. However, queuing remains a major intermittent component of latency.
Traditionally very low latency has only been available for a few Traditionally very low latency has only been available for a few
selected low rate applications, that confine their sending rate selected low rate applications, that confine their sending rate
within a specially carved-off portion of capacity, which is within a specially carved-off portion of capacity, which is
prioritized over other traffic, e.g. Diffserv EF [RFC3246]. Up to prioritized over other traffic, e.g. Diffserv EF [RFC3246]. Up to
now it has not been possible to allow any number of low latency, high now it has not been possible to allow any number of low latency, high
throughput applications to seek to fully utilize available capacity, throughput applications to seek to fully utilize available capacity,
because the capacity-seeking process itself causes too much queuing because the capacity-seeking process itself causes too much queuing
delay. delay.
skipping to change at page 10, line 35 skipping to change at page 10, line 35
simultaneously using very demanding high bandwidth low latency simultaneously using very demanding high bandwidth low latency
applications over a single shared access link [L4Sdemo16]. In one applications over a single shared access link [L4Sdemo16]. In one
application, each user could use finger gestures to pan or zoom their application, each user could use finger gestures to pan or zoom their
own high definition (HD) sub-window of a larger video scene generated own high definition (HD) sub-window of a larger video scene generated
on the fly in 'the cloud' from a football match. Another user on the fly in 'the cloud' from a football match. Another user
wearing VR goggles was remotely receiving a feed from a 360-degree wearing VR goggles was remotely receiving a feed from a 360-degree
camera in a racing car, again with the sub-window in their field of camera in a racing car, again with the sub-window in their field of
vision generated on the fly in 'the cloud' dependent on their head vision generated on the fly in 'the cloud' dependent on their head
movements. Even though other users were also downloading large movements. Even though other users were also downloading large
amounts of L4S and Classic data, playing a gaming benchmark and amounts of L4S and Classic data, playing a gaming benchmark and
watchings videos over the same 40Mb/s downstream broadband link, watching videos over the same 40Mb/s downstream broadband link,
latency was so low that the football picture appeared to stick to the latency was so low that the football picture appeared to stick to the
user's finger on the touch pad and the experience fed from the remote user's finger on the touch pad and the experience fed from the remote
camera did not noticeably lag head movements. All the L4S data (even camera did not noticeably lag head movements. All the L4S data (even
including the downloads) achieved the same very low latency. With an including the downloads) achieved the same very low latency. With an
alternative AQM, the video noticeably lagged behind the finger alternative AQM, the video noticeably lagged behind the finger
gestures and head movements. gestures and head movements.
Unlike Diffserv Expedited Forwarding, the L4S queue does not have to Unlike Diffserv Expedited Forwarding, the L4S queue does not have to
be limited to a small proportion of the link capacity in order to be limited to a small proportion of the link capacity in order to
achieve low delay. The L4S queue can be filled with a heavy load of achieve low delay. The L4S queue can be filled with a heavy load of
skipping to change at page 23, line 14 skipping to change at page 23, line 14
The security considerations section of the L4S architecture also The security considerations section of the L4S architecture also
includes subsections on policing of relative flow-rates (section 8.1) includes subsections on policing of relative flow-rates (section 8.1)
and on policing of flows that cause excessive queuing delay (section and on policing of flows that cause excessive queuing delay (section
8.2). It explains that the interests of users do not collide in the 8.2). It explains that the interests of users do not collide in the
same way for delay as they do for bandwidth. For someone to get more same way for delay as they do for bandwidth. For someone to get more
of the bandwidth of a shared link, someone else necessarily gets less of the bandwidth of a shared link, someone else necessarily gets less
(a 'zero-sum game'), whereas queuing delay can be reduced for (a 'zero-sum game'), whereas queuing delay can be reduced for
everyone, without any need for someone else to lose out. It also everyone, without any need for someone else to lose out. It also
explains that, on the current Internet, scheduling usually enforces explains that, on the current Internet, scheduling usually enforces
separation between 'sites' (e.g. households, businesses or mobile separation of bandwidth between 'sites' (e.g. households, businesses
users), but it is not common to need to schedule or police individual or mobile users), but it is not common to need to schedule or police
application flows. the bandwidth used by individual application flows.
By the above arguments, per-flow policing might not be necessary and By the above arguments, per-flow rate policing might not be necessary
in trusted environments it is certainly unlikely to be needed. and in trusted environments (e.g. private data centres) it is
Therefore, because it is hard to avoid complexity and unintended certainly unlikely to be needed. Therefore, because it is hard to
side-effects with per-flow policing, it needs to be separable from a avoid complexity and unintended side-effects with per-flow rate
basic AQM, as an option, under policy control. On this basis, the policing, it needs to be separable from a basic AQM, as an option,
DualQ Coupled AQM provides low delay without prejudging the question under policy control. On this basis, the DualQ Coupled AQM provides
of per-flow policing. low delay without prejudging the question of per-flow rate policing.
Nonetheless, the interests of users or flows might conflict, e.g. in Nonetheless, the interests of users or flows might conflict, e.g. in
case of accident or malice. Then per-flow control could be case of accident or malice. Then per-flow rate control could be
necessary. If flow-rate control is needed, it can be provided as a necessary. If flow-rate control is needed, it can be provided as a
modular addition to a DualQ. And similarly, if protection against modular addition to a DualQ. And similarly, if protection against
excessive queue delay is needed, a per-flow queue protection option excessive queue delay is needed, a per-flow queue protection option
can be added to a DualQ (e.g. [I-D.briscoe-docsis-q-protection]). can be added to a DualQ (e.g. [I-D.briscoe-docsis-q-protection]).
4.2. Handling Unresponsive Flows and Overload 4.2. Handling Unresponsive Flows and Overload
In the absence of any per-flow control, it is important that the In the absence of any per-flow control, it is important that the
basic DualQ Coupled AQM gives unresponsive flows no more throughput basic DualQ Coupled AQM gives unresponsive flows no more throughput
advantage than a single-queue AQM would, and that it at least handles advantage than a single-queue AQM would, and that it at least handles
skipping to change at page 30, line 41 skipping to change at page 30, line 41
<https://www.netdevconf.org/0x13/session.html?talk- <https://www.netdevconf.org/0x13/session.html?talk-
DUALPI2-AQM>. DUALPI2-AQM>.
[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,
<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>.
[Dukkipati06]
Dukkipati, N. and N. McKeown, "Why Flow-Completion Time is
the Right Metric for Congestion Control", ACM CCR
36(1):59--62, January 2006,
<https://dl.acm.org/doi/10.1145/1111322.1111336>.
[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-06, 13 Internet-Draft, draft-briscoe-docsis-q-protection-06, 13
May 2022, May 2022,
<https://datatracker.ietf.org/api/v1/doc/document/draft- <https://datatracker.ietf.org/api/v1/doc/document/draft-
skipping to change at page 64, line 16 skipping to change at page 64, line 16
of k=2 is recommended as a good workable compromise. of k=2 is recommended as a good workable compromise.
Acknowledgements Acknowledgements
Thanks to Anil Agarwal, Sowmini Varadhan, Gabi Bracha, Nicolas Kuhn, Thanks to Anil Agarwal, Sowmini Varadhan, Gabi Bracha, Nicolas Kuhn,
Greg Skinner, Tom Henderson, David Pullen, Mirja Kuehlewind, Gorry Greg Skinner, Tom Henderson, David Pullen, Mirja Kuehlewind, Gorry
Fairhurst, Pete Heist, Ermin Sakic and Martin Duke for detailed Fairhurst, Pete Heist, Ermin Sakic and Martin Duke for detailed
review comments particularly of the appendices and suggestions on how review comments particularly of the appendices and suggestions on how
to make the explanations clearer. Thanks also to Tom Henderson for to make the explanations clearer. Thanks also to Tom Henderson for
insights on the choice of schedulers and queue delay measurement insights on the choice of schedulers and queue delay measurement
techniques. And thanks to the area reviewer, Christer Holmberg. techniques. And thanks to the area reviewers Christer Holmberg, Lars
Eggert and Roman Danyliw.
The early contributions of Koen De Schepper, Bob Briscoe, Olga The early contributions of Koen De Schepper, Bob Briscoe, Olga
Bondarenko and Inton Tsang were part-funded by the European Community Bondarenko and Inton Tsang were part-funded by the European Community
under its Seventh Framework Programme through the Reducing Internet under its Seventh Framework Programme through the Reducing Internet
Transport Latency (RITE) project (ICT-317700). Contributions of Koen Transport Latency (RITE) project (ICT-317700). Contributions of Koen
De Schepper and Olivier Tilmans were also part-funded by the 5Growth De Schepper and Olivier Tilmans were also part-funded by the 5Growth
and DAEMON EU H2020 projects. Bob Briscoe's contribution was also and DAEMON EU H2020 projects. Bob Briscoe's contribution was also
part-funded by the Comcast Innovation Fund and the Research Council part-funded by the Comcast Innovation Fund and the Research Council
of Norway through the TimeIn project. The views expressed here are of Norway through the TimeIn project. The views expressed here are
solely those of the authors. solely those of the authors.
 End of changes. 8 change blocks. 
20 lines changed or deleted 27 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/