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

From: Bob Briscoe <[email-masked]>
Date: Fri, 07 Aug 2015 15:46:35 +0100

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 queuing latency is 
even smaller

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.

*Change**s**
*The algo is unchanged, but hopefully the explanation is a considerable 
improvement on the unofficial draft I had posted on my personal Web site 
during the Prague meeting ('cos I missed the deadline by a minute). To 
save you time if you read that one, here's the diff 
<http://www.bobbriscoe.net/projects/latency/Diff:%20draft-briscoe-aqm-dualq-coupled-00-DIFF-00a.html>.

Thanks to Anil Agarwal for all the help in making the pseudocode 
explanation understandable - previously we had described pseudocode of 
the code optimised for the Linux kernel, whereas now we describe 
pseudocode "optimised for explanation", then explain how it was designed 
to be optimised for integer arithmetic etc.

We have also added three optional approaches for overload handling 
(chosen by policy), to ensure the priority queue does not make the 
Classic queue suffer more than it would have if there had been just one 
FIFO.

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: Yuchung Cheng <[email-masked]>
Date: Fri, 7 Aug 2015 16:54:01 -0700

On Fri, Aug 7, 2015 at 7:46 AM, Bob Briscoe <[email-masked]> wrote:
>
> 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 queuing latency is even smaller
>
> The draft refers out to our 'under-submission' DCttH paper reporting a selection of the thousands of experiments we did ourselves. We are preparing a tech report to record the rest.
>
> Changes
> The algo is unchanged, but hopefully the explanation is a considerable improvement on the unofficial draft I had posted on my personal Web site during the Prague meeting ('cos I missed the deadline by a minute). To save you time if you read that one, here's the diff.
>
> Thanks to Anil Agarwal for all the help in making the pseudocode explanation understandable - previously we had described pseudocode of the code optimised for the Linux kernel, whereas now we describe pseudocode "optimised for explanation", then explain how it was designed to be optimised for integer arithmetic etc.
>
> We have also added three optional approaches for overload handling (chosen by policy), to ensure the priority queue does not make the Classic queue suffer more than it would have if there had been just one FIFO.
>
> Cheers
Interesting work. Do the queues share the same memory pool?

I hypothesize that with current ECN deployment, the bad (reno) guy
will take up C_Q. What happens when the nice guy (dctcp) knocks the
door when the house is full? the strict priority policy in the doc
isn't clear about which butt to boot ...

> Subject: New Version Notification for draft-briscoe-aqm-dualq-coupled-00.txt
> 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]>
>
>
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm
>

---

From: John Leslie <[email-masked]>
Date: Sat, 8 Aug 2015 07:40:33 -0400

> Interesting work. Do the queues share the same memory pool?

   I don't believe the draft says one way or the other; but the concept
would seem to call for separate memory.

> isn't clear about which butt to boot ...

   The pseudocode in Appendix A isn't the easiest to read; but it
does show that the L4S queue goes out first (with CE marking) before
the Classic queue.

   The draft is also clear that the example applies AQM on exit from
the queues. Thus the Classic queue (in this example) could easily fill
available memory; so your question is appropriate.

   The draft is a bit hand-wavy about what happens when there's too
much L4S traffic. IMHO, _one_ necessary feature would be to limit the
size of the L4S queue and drop L4S traffic that won't fit.

--
John Leslie <[email-masked]>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 10 Aug 2015 09:09:37 +0000

Hi Yuchung, Bob,

(w/o chair hat)

Wouldn't be a sensible reaction, in the scenario sketched by Yuchung, to have at least one MSS memory available at all times for L4S queues, and drop from the classic queue if that cann't be guaranteed earlier?

Best regards,
  Richard

> -----Original Message-----
> From: aqm [mailto:[email-masked]] On Behalf Of John Leslie
> Sent: Samstag, 08. August 2015 13:41
> To: Yuchung Cheng
> Cc: Bob Briscoe; AQM IETF list
> Subject: Re: [aqm] New I-D: draft-briscoe-aqm-dualq-coupled-00.txt
> 
>    The pseudocode in Appendix A isn't the easiest to read; but it does
> show that the L4S queue goes out first (with CE marking) before the
> Classic queue.
> 
>    The draft is also clear that the example applies AQM on exit from the
> queues. Thus the Classic queue (in this example) could easily fill
>    The draft is a bit hand-wavy about what happens when there's too much
> L4S traffic. IMHO, _one_ necessary feature would be to limit the size of
> the L4S queue and drop L4S traffic that won't fit.
> 
> --

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 14 Aug 2015 10:04:17 +0100

Yuchung,

> Interesting work. Do the queues share the same memory pool?
It's implemented in Linux as a multiqueue qdisc, so the kernel allocates 
memory between the subqueues. But, before buffer memory is exhausted, we 
have overload code that determines which queue will be hit...

> isn't clear about which butt to boot ...

If the classic traffic (e.g. Reno) is responsive, it's going to be hard 
to overflow the buffer unless there's a huge number of Reno flows, 
because there's a pretty decent AQM in there. It certainly could 
overload with just Reno flows, but perhaps a more pressing scenario 
would be  "What if unresponsive classic traffic exceeds the link rate?"

Whatever, overload handling (with either class of traffic) is explained 
in section 4.1.
<https://tools.ietf.org/html/draft-briscoe-aqm-dualq-coupled-00#section-4.1>
We separated overload out, because different operators will have 
different views on which traffic is more important to protect during 
overload. And there are different qualities to protect (e.g. drop vs delay).

If you had already read 4.1 and you meant it wasn't clear, what exactly 
wasn't clear?

If you meant the pseudocode Appendix wasn't clear on this point, we know 
(there's a note in the appendix saying overload pseudocode is "ToDo"). 
The policies are very simple to implement, however we wanted to fully 
test them before recommending anything. Koen is on vacation for another 
week, then when we've done the testing, we will add the overload 
pseudocode. But we also have a long list of other items to test as well, 
so I cannot yet promise when.

HTH

Bob

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