< draft-ietf-tsvwg-aqm-dualq-coupled-09.txt   draft-ietf-tsvwg-aqm-dualq-coupled-10.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 6, 2020 G. White Expires: January 9, 2020 G. White
CableLabs CableLabs
July 05, 2019 July 8, 2019
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-09 draft-ietf-tsvwg-aqm-dualq-coupled-10
Abstract Abstract
The Low Latency Low Loss Scalable Throughput (L4S) architecture The Low Latency Low Loss Scalable Throughput (L4S) architecture
allows data flows over the public Internet to predictably achieve allows data flows over the public Internet to achieve consistent
ultra-low queuing latency, generally zero congestion loss and scaling ultra-low queuing latency, generally zero congestion loss and scaling
of per-flow throughput without the problems of traditional TCP. To of per-flow throughput without the scaling problems of traditional
achieve this, L4S data flows have to use one of the family of TCP. To achieve this, L4S data flows have to use one of the family
'Scalable' congestion controls (Data Centre TCP and TCP Prague are of 'Scalable' congestion controls (Data Centre TCP and TCP Prague are
examples) and a form of Explicit Congestion Notification (ECN) with examples) and a form of Explicit Congestion Notification (ECN) with
modified behaviour. However, until now, Scalable congestion controls modified behaviour. However, until now, Scalable congestion controls
did not co-exist with existing TCP Reno/Cubic traffic --- Scalable did not co-exist with existing TCP Reno/Cubic traffic --- Scalable
controls are so aggressive that 'Classic' TCP algorithms drive controls are so aggressive that 'Classic' TCP algorithms drive
themselves to a small capacity share. Therefore, until now, L4S themselves to a small capacity share. Therefore, until now, L4S
controls could only be deployed where a clean-slate environment could controls could only be deployed where a clean-slate environment could
be arranged, such as in private data centres (hence the name DCTCP). be arranged, such as in private data centres (hence the name DCTCP).
This specification defines `DualQ Coupled Active Queue Management This specification defines `DualQ Coupled Active Queue Management
(AQM)', which enables these Scalable congestion controls to safely (AQM)', which enables these Scalable congestion controls to safely
co-exist with Classic Internet traffic. co-exist with Classic Internet traffic.
The Coupled AQM ensures that competing Scalable and Classic flows run Analytical study and implementation testing of the Coupled AQM have
at about the same rate. It achieves this indirectly, without having shown that Scalable and Classic flows competing under similar
to inspect transport layer flow identifiers, When tested in a conditions run at roughly the same rate. It achieves this
residential broadband setting, DCTCP also achieves sub-millisecond indirectly, without having to inspect transport layer flow
average queuing delay and zero congestion loss under a wide range of identifiers. When tested in a residential broadband setting, DCTCP
mixes of DCTCP and `Classic' broadband Internet traffic, without also achieves sub-millisecond average queuing delay and zero
compromising the performance of the Classic traffic. The solution congestion loss under a wide range of mixes of DCTCP and `Classic'
also reduces network complexity and requires no configuration for the broadband Internet traffic, without compromising the performance of
public Internet. the Classic traffic. The solution also reduces network complexity
and requires no configuration for the public Internet.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 6, 2020. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 23, line 20 skipping to change at page 23, line 20
Olga Albisser <olga@albisser.org> of Simula Research Lab, Norway Olga Albisser <olga@albisser.org> of Simula Research Lab, Norway
(Olga Bondarenko during early drafts) implemented the prototype (Olga Bondarenko during early drafts) implemented the prototype
DualPI2 AQM for Linux with Koen De Schepper and conducted DualPI2 AQM for Linux with Koen De Schepper and conducted
extensive evaluations as well as implementing the live performance extensive evaluations as well as implementing the live performance
visualization GUI [L4Sdemo16]. visualization GUI [L4Sdemo16].
Olivier Tilmans <olivier.tilmans@nokia-bell-labs.com> of Nokia Olivier Tilmans <olivier.tilmans@nokia-bell-labs.com> of Nokia
Bell Labs, Belgium prepared and maintains the Linux implementation Bell Labs, Belgium prepared and maintains the Linux implementation
of DualPI2 for upstreaming. of DualPI2 for upstreaming.
Tom Henderson <tomh@tomh.org> of the University of Washington, WA, Tom Henderson <tomh@tomh.org> of CableLabs, US implemented various
US implemented various Coupled DualQ AQMs for ns3, including Coupled DualQ AQMs for ns3, including DualPI2 and DualPIE over
DualPI2 and DualPIE over point to point and DOCSIS 3.1 link models point to point and DOCSIS 3.1 link models and conducted extensive
and conducted extensive evaluations. evaluations.
Ing Jyh (Inton) Tsang of Nokia, Belgium built the End-to-End Data Ing Jyh (Inton) Tsang of Nokia, Belgium built the End-to-End Data
Centre to the Home broadband testbed on which Coupled DualQ Centre to the Home broadband testbed on which Coupled DualQ
implementations were tested. implementations were tested.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-tsvwg-ecn-l4s-id] [I-D.ietf-tsvwg-ecn-l4s-id]
 End of changes. 8 change blocks. 
21 lines changed or deleted 22 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/