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