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

Yuchung,

On 08/08/15 00:54, Yuchung Cheng wrote:
> On Fri, Aug 7, 2015 at 7:46 AM, Bob Briscoe <ietf@bobbriscoe.net> 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?
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...

> 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 ...

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, 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: internet-drafts@ietf.org
>> To: Koen De Schepper <koen.de_schepper@alcatel-lucent.com>, Ing-jyh Tsang <ing-jyh.tsang@alcatel-lucent.com>, Bob Briscoe <ietf@bobbriscoe.net>, Olga Bondarenko <olgabnd@gmail.com>, Koen De Schepper <koen.de_schepper@alcatel-lucent.com>, Olga Bondarenko <olgabnd@gmail.com>, Bob Briscoe <ietf@bobbriscoe.net>, ing-jyh.tsang@alcatel-lucent.com <ing-jyh.tsang@alcatel-lucent.com>
>>
>>
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> aqm mailing list
>> aqm@ietf.org
>> https://www.ietf.org/mailman/listinfo/aqm
>>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm

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