On Fri, Aug 7, 2015 at 7:46 AM, Bob Briscoe <i...@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?
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 ...
>
>
>
> 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-dra...@ietf.org
> To: Koen De Schepper <koen.de_schep...@alcatel-lucent.com>, Ing-jyh Tsang
> <ing-jyh.ts...@alcatel-lucent.com>, Bob Briscoe <i...@bobbriscoe.net>, Olga
> Bondarenko <olga...@gmail.com>, Koen De Schepper
> <koen.de_schep...@alcatel-lucent.com>, Olga Bondarenko <olga...@gmail.com>,
> Bob Briscoe <i...@bobbriscoe.net>, ing-jyh.ts...@alcatel-lucent.com
> <ing-jyh.ts...@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
