Yuchung,
On 08/08/15 00:54, Yuchung Cheng wrote:
On Fri, Aug 7, 2015 at 7:46 AM, Bob Briscoe <[email protected]> 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: [email protected]
To: Koen De Schepper <[email protected]>, Ing-jyh Tsang <[email protected]>, Bob
Briscoe <[email protected]>, Olga Bondarenko <[email protected]>, Koen De Schepper
<[email protected]>, Olga Bondarenko <[email protected]>, Bob Briscoe
<[email protected]>, [email protected] <[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
--
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
