draft-ietf-tsvwg-aqm-dualq-coupled-05.txt   draft-ietf-tsvwg-aqm-dualq-coupled-06.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 3, 2019 CableLabs Expires: January 19, 2019 CableLabs
O. Bondarenko O. Bondarenko
Simula Research Lab Simula Research Lab
I. Tsang I. Tsang
Nokia Nokia
July 2, 2018 July 18, 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-05 draft-ietf-tsvwg-aqm-dualq-coupled-06
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 3, 2019. This Internet-Draft will expire on January 19, 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 48 skipping to change at page 2, line 48
2.5.2. Management Requirements . . . . . . . . . . . . . . . 13 2.5.2. Management Requirements . . . . . . . . . . . . . . . 13
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
4.1. Overload Handling . . . . . . . . . . . . . . . . . . . . 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? . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 17
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . 29 Appendix B. Example DualQ Coupled Curvy RED Algorithm . . . . . 30
Appendix C. Guidance on Controlling Throughput Equivalence . . . 35 Appendix C. Guidance on Controlling Throughput Equivalence . . . 36
Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 36 Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
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 13, line 5 skipping to change at page 13, line 5
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 CE-marking as * if the packet is ECT(0), the L AQM SHOULD apply drop using a
if the packet were ECT(1) drop probability appropriate to Classic congestion control 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 policing): misbehaving flows (e.g. per-flow queue protection or latency
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
packet (for instance, the operator might classify EF traffic packet (for instance, the operator might classify EF traffic
that is unresponsive to drop into the L queue, alongside that is unresponsive to drop into the L queue, alongside
responsive L4S-ECN traffic) responsive L4S-ECN traffic)
+ if separate queue protection is not provided, the L AQM MUST + if separate queue protection is not provided, the L AQM
apply drop using the drop probability appropriate to the C SHOULD apply drop using a drop probability appropriate to
queue Classic congestion control and appropriate to the target
delay in the L queue
o If a packet that carries an ECT(1) or CE codepoint is classified o If a packet that carries an ECT(1) codepoint is classified into
into the C queue: the C queue:
* the C AQM SHOULD apply CE-marking as if the packet were ECT(0). * the C AQM SHOULD apply CE-marking using the coupled AQM
probability p_CL (= k*p').
If the DualQ Coupled AQM has detected overload, it will signal If the DualQ Coupled AQM has detected overload, it will signal
congestion solely using drop, irrespective of the ECN field. congestion solely using drop, irrespective of the ECN field.
Most of the above requirements are worded as "SHOULDs", because The above requirements are worded as "SHOULDs", because operator-
operator-specific classifiers are for flexibility, by definition. specific classifiers are for flexibility, by definition. Therefore,
Therefore, alternative actions might be appropriate in the operator's alternative actions might be appropriate in the operator's specific
specific circumstances. circumstances. An example would be where the operator knows that
certain legacy traffic marked with one codepoint actually has a
congestion response associated with another codepoint.
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);
 End of changes. 12 change blocks. 
22 lines changed or deleted 28 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/