Subject: [tcpm] Fwd: New I-D: draft-briscoe-aqm-dualq-coupled-00.txt

From: Bob Briscoe <[email-masked]>
Date: Fri, 07 Aug 2015 16:29:51 +0100

tcpm chairs & list.

Cross-posting this announcement to tcpm, given its about evolving TCP 
and its interaction with AQMs.

If you were in Prague you may have seen this AQM demonstrated over a 
broadband Internet testbed. Here's the video 
<http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF93_AQM&chapter=chapter_1> 
(starts at about 33mins - your browser has to support HTML5).

This DualQ Coupled AQM exploits ECN and scalable TCP algos like Data 
Centre TCP (DCTCP).  In our extensive testing, it gave zero congestion 
loss and about 1ms queuing latency at the 98th percentile, even under 
high load. It is designed to allow DCTCP to co-exist with existing TCP 
Cubic & Reno, whether mixed within a data centre, on private networks or 
on the public Internet.

We believe a WG will need to be found for evolution of DCTCP (there is 
currently a non-WG mailing list called [email-masked] for this). 
Currently the list of safety mods needed in DCTCP is in an appendix, but 
it says that is only a temporary home.

Otherwise we expect any WG activity to be in tsvwg and AQM, so for tcpm 
this is just an FYI email at the moment.

Cheers

Bob, Koen, Olga & Inton

-------- Forwarded Message --------
Subject: 	New I-D: draft-briscoe-aqm-dualq-coupled-00.txt
Date: 	Fri, 07 Aug 2015 15:46:35 +0100
From: 	Bob Briscoe <[email-masked]>
To: 	Scheffenegger, Richard <[email-masked]>, Wesley Eddy 
<[email-masked]>, AQM IETF list <[email-masked]>
CC: 	De Schepper, Koen (Koen) <[email-masked]>, 
TSANG Inton <[email-masked]>, Olga Bondarenko 
<[email-masked]>

AQM Chairs, list,

My co-authors and I have just posted a draft spec of the DualQ Coupled 
AQM we presented and demonstrated in Prague under the title "Data Centre 
to the Home" (see announcement quoted below).

*Invitation to reimplement / bash**
*We are not asking for adoption right now. But we would be happy if 
others tried to reimplement it using our description and to test it 
independently. We are trying to get approval from employers to release 
it as open source, but you will see that the pseudocode is only 15 
lines, so it should not be hard to reimplement.

The draft refers out to our 'under-submission' DCttH paper 
<http://www.bobbriscoe.net/projects/latency/dctth_preprint.pdf> 
reporting a selection of the thousands of experiments we did ourselves. 
We are preparing a tech report to record the rest.

Cheers

Bob, Koen, Olga & Inton.

-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-briscoe-aqm-dualq-coupled-00.txt
Date: 	Fri, 07 Aug 2015 06:41:15 -0700
From: 	[email-masked]
To: 	Koen De Schepper <[email-masked]>, Ing-jyh 
Tsang <[email-masked]>, Bob Briscoe 
<[email-masked]>, Olga Bondarenko <[email-masked]>, Koen De 
Schepper <[email-masked]>, Olga Bondarenko 
<[email-masked]>, Bob Briscoe <[email-masked]>, 
[email-masked] <[email-masked]>

A new version of I-D, draft-briscoe-aqm-dualq-coupled-00.txt
has been successfully submitted by Bob Briscoe and posted to the
IETF repository.

Name:		draft-briscoe-aqm-dualq-coupled
Revision:	00
Title:		DualQ Coupled AQM for Low Latency, Low Loss and Scalable Throughput
Document date:	2015-08-07
Group:		Individual Submission
Pages:		22
URL:https://www.ietf.org/internet-drafts/draft-briscoe-aqm-dualq-coupled-00.txt
Status:https://datatracker.ietf.org/doc/draft-briscoe-aqm-dualq-coupled/
Htmlized:https://tools.ietf.org/html/draft-briscoe-aqm-dualq-coupled-00

Abstract:
    Data Centre TCP (DCTCP) was designed to provide predictably low
    queuing latency, near-zero loss, and throughput scalability using
    explicit congestion notification (ECN) and an extremely simple
    marking behaviour on switches.  However, DCTCP does not co-exist with
    existing TCP traffic---throughput starves.  So, until now, DCTCP
    could only be deployed where a clean-slate environment could be
    arranged, such as in private data centres.  This specification
    defines `DualQ Coupled Active Queue Management (AQM)' to allow
    scalable congestion controls like DCTCP to safely co-exist with
    classic Internet traffic.  The Coupled AQM ensures that a flow runs
    at about the same rate whether it uses DCTCP or TCP Reno/Cubic, but
    without inspecting transport layer flow identifiers.  When tested in
    a residential broadband setting, DCTCP achieved sub-millisecond
    average queuing delay and zero congestion loss under a wide range of
    mixes of DCTCP and `Classic' broadband Internet traffic, without
    compromising the performance of the Classic traffic.  The solution
    also reduces network complexity and eliminates network configuration.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Mon, 17 Aug 2015 10:51:27 +0200

Hi Bob,

To me the formulation “existing TCP Cubic & Reno” is not exactly clear. I
would have called a TCP following

existing standards RFC3168 and RFC5681 a TCP Reno implementation, but I
believe that below

you very explicitly mean a TCP Reno (or Cubic) implementation NOT

exploiting ECN RFC3168. I think this is a crucial point.

TCP Reno implementations supporting RF3168, with RFC3168 activated, are
deployed (do exist) in the internet today

(even if RFC3168 active don’t make any difference with the existing AQMs).

BR, Karen

*From:* tcpm [mailto:[email-masked]] *On Behalf Of *Bob Briscoe
*Sent:* Friday, August 07, 2015 5:30 PM
*To:* SCHARF, Michael; SAROLAHTI, Pasi; Yoshifumi Nishada; tcpm IETF list
*Cc:* Olga Bondarenko
*Subject:* [tcpm] Fwd: New I-D: draft-briscoe-aqm-dualq-coupled-00.txt

tcpm chairs & list.

Cross-posting this announcement to tcpm, given its about evolving TCP and
its interaction with AQMs.

This DualQ Coupled AQM exploits ECN and scalable TCP algos like Data Centre
TCP (DCTCP).  In our extensive testing, it gave zero congestion loss and
about 1ms queuing latency at the 98th percentile, even under high load. It
is designed to allow DCTCP to co-exist with existing TCP Cubic & Reno,
whether mixed within a data centre, on private networks or on the public
Internet.

We believe a WG will need to be found for evolution of DCTCP (there is
currently a non-WG mailing list called [email-masked] for this).
Currently the list of safety mods needed in DCTCP is in an appendix, but it
says that is only a temporary home.

Cheers

Bob, Koen, Olga & Inton

-------- Forwarded Message --------

*Subject: *

New I-D: draft-briscoe-aqm-dualq-coupled-00.txt

*Date: *

Fri, 07 Aug 2015 15:46:35 +0100

*From: *

Bob Briscoe <[email-masked]> <[email-masked]>

*To: *

Scheffenegger, Richard <[email-masked]> <[email-masked]>, Wesley Eddy
<[email-masked]> <[email-masked]>, AQM IETF list <[email-masked]>
<[email-masked]>

*CC: *

De Schepper, Koen (Koen) <[email-masked]>
<[email-masked]>, TSANG Inton
<[email-masked]> <[email-masked]>, Olga
Bondarenko <[email-masked]> <[email-masked]>

AQM Chairs, list,

My co-authors and I have just posted a draft spec of the DualQ Coupled AQM
we presented and demonstrated in Prague under the title "Data Centre to the
Home" (see announcement quoted below).

*Invitation to reimplement / bash*We are not asking for adoption right now.
But we would be happy if others tried to reimplement it using our
description and to test it independently. We are trying to get approval
from employers to release it as open source, but you will see that the
pseudocode is only 15 lines, so it should not be hard to reimplement.

The draft refers out to our 'under-submission' DCttH paper
<http://www.bobbriscoe.net/projects/latency/dctth_preprint.pdf> reporting a
selection of the thousands of experiments we did ourselves. We are
preparing a tech report to record the rest.

Cheers

Bob, Koen, Olga & Inton.

-------- Forwarded Message --------

*Subject: *

New Version Notification for draft-briscoe-aqm-dualq-coupled-00.txt

*Date: *

Fri, 07 Aug 2015 06:41:15 -0700

*From: *

[email-masked]

*To: *

Koen De Schepper <[email-masked]>
<[email-masked]>, Ing-jyh Tsang
<[email-masked]> <[email-masked]>, Bob
Briscoe <[email-masked]> <[email-masked]>, Olga Bondarenko
<[email-masked]> <[email-masked]>, Koen De Schepper
<[email-masked]> <[email-masked]>,
Olga Bondarenko <[email-masked]> <[email-masked]>, Bob Briscoe
<[email-masked]> <[email-masked]>,
[email-masked] <[email-masked]>
<[email-masked]>

IETF repository.

Revision:     00

Title:        DualQ Coupled AQM for Low Latency, Low Loss and Scalable
Throughput

Pages:        22

URL:
https://www.ietf.org/internet-drafts/draft-briscoe-aqm-dualq-coupled-00.txt

Status:
https://datatracker.ietf.org/doc/draft-briscoe-aqm-dualq-coupled/

Htmlized:       https://tools.ietf.org/html/draft-briscoe-aqm-dualq-coupled-00

Abstract:

The IETF Secretariat

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 18 Aug 2015 17:45:44 +0100

Karen,

No, no. I mean Reno and Cubic whether they use RFC3168 ECN or not.

The critical point is that packets sent from a 'scalable' congestion 
control need to be distinguishable from 'classic' traffic like Reno and 
Cubic (whether the latter supports ECN or not).

I have suggested (on the aqm list) that, in the short term, the new L4S 
traffic will need to be distinguished by a combination of non-zero ECN 
field /and/ a local-use Diffserv codepoint.

it would make sense for any classic ECN that is already deployed, or 
gets deployed before L4S is ready, to upgrade to L4S later. So classic 
ECN should disappear over time.

Then, in the short term, operators can sell L4S for local-network only. 
While in the longer term, operators would be able to classify just on 
the ECN field. So we would reach the Nirvana of an e2e L4S service for 
all traffic, without all the interconnection mess of Diffserv.

Cheers

Bob

Terminology (from 
<https://tools.ietf.org/html/draft-briscoe-aqm-dualq-coupled>):
* L4S = low latency, low loss, scalable throughput.
* scalable = as flow rate increases, the gap between losses or ECN marks 
does not widen, as it does with Reno or Cubic.

On 17/08/15 09:51, Karen Elisabeth Egede Nielsen wrote:
>
> Hi Bob,
>
> To me the formulation “existing TCP Cubic & Reno” is not exactly 
> clear. I would have called a TCP following
>
> existing standards RFC3168 and RFC5681 a TCP Reno implementation, but 
> I believe that below
>
> TCP Reno implementations supporting RF3168, with RFC3168 activated, 
> are deployed (do exist) in the internet today
>
> *From:*tcpm [mailto:[email-masked] 
> <mailto:[email-masked]>] *On Behalf Of *Bob Briscoe
> Cubic & Reno, whether mixed within a data centre, on private networks 
> or on the public Internet.
>
> currently a non-WG mailing list called [email-masked] 
> <mailto:[email-masked]> for this). Currently the list of safety 
> mods needed in DCTCP is in an appendix, but it says that is only a 
> temporary home.
>
> Otherwise we expect any WG activity to be in tsvwg and AQM, so for 
> tcpm this is just an FYI email at the moment.
>
>
> Cheers
>
>
>
> Bob, Koen, Olga & Inton
>
>
>
> Bob Briscoe <[email-masked]> <mailto:[email-masked]>
>
> *To: *
>
> 	
>
> Scheffenegger, Richard <[email-masked]> <mailto:[email-masked]>, Wesley 
> Eddy <[email-masked]> <mailto:[email-masked]>, AQM IETF list 
> <[email-masked]> <mailto:[email-masked]>
>
> *CC: *
>
> 	
>
> <mailto:[email-masked]>, TSANG Inton 
> <mailto:[email-masked]>, Olga Bondarenko 
> <[email-masked]> <mailto:[email-masked]>
>
>
>
> AQM Chairs, list,
>
> AQM we presented and demonstrated in Prague under the title "Data 
> Centre to the Home" (see announcement quoted below).
>
> *Invitation to reimplement / bash
> reporting a selection of the thousands of experiments we did 
> ourselves. We are preparing a tech report to record the rest.
>
> Cheers
>
>
>
> Bob, Koen, Olga & Inton.
>
>
>
> [email-masked] <mailto:[email-masked]>
>
> *To: *
>
> 	
>
> <mailto:[email-masked]>, Ing-jyh Tsang 
> <mailto:[email-masked]>, Bob Briscoe 
> <[email-masked]> <mailto:[email-masked]>, Olga Bondarenko 
> <[email-masked]> <mailto:[email-masked]>, Koen De Schepper 
> <[email-masked]> 
> <mailto:[email-masked]>, Olga Bondarenko 
> <[email-masked]> <mailto:[email-masked]>, Bob Briscoe 
> <[email-masked]> <mailto:[email-masked]>, 
> [email-masked] 
> <mailto:[email-masked]> 
> <mailto:[email-masked]>
>
> until the htmlized version and diff are available attools.ietf.org  <http://tools.ietf.org>.
>   
> The IETF Secretariat
>   
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/