> On Jan 26, 2015, at 6:02 PM, Dave Taht <[email protected]> wrote: > > > I would like to try a dctcp implementation against the aqms as > available today, and to compare the results against the default highly > specialized RED implementation dctcp presently requires.
That would be interesting. The default DCTCP AQM mechanism is RED without the averaging, which is a good thing, but it uses proportional marking. The proportional controller is the "fastest" controller you can design however the drawback is you cannot regulate (control) the delay/queue length to a fixed value. The PI controller fixes this issue. The authors of DCTCP also tried to implement the PI controller however they found the performance was not as good. This shouldn't be a surprise as the design guidelines that the authors used for PI followed our original paper where the dynamics followed vanilla TCP. Since DCTCP follows different dynamics, the PI controller needs to be adjusted accordingly. I am happy to work with you on this if there is interest. > >> That was sort of the whole idea behind the PI controller - something that >> predicts onset of congestion by observing the derivative in the queue length >> as well as the absolute value of the queue. One of the failings of RED that >> we identified in a companion paper to the PI one >> (http://dna-pubs.cs.columbia.edu/citation/paperfile/22/hollot01control.pdf) >> was that RED used _averaged_ queue length as the congestion indicator. That >> introduced a further delay to the feedback loop - by the time your average >> rose and you to decided to "mark" a packet the buffer was already close to >> overflowing. > > There is not a lot of useful information in "average" queue length, yes. > We have argued something stronger - average queue length actively _hurts_ a feedback loop that has significant delays. > keep the pipe fully utilized without needing to drop any packets. You can > also use ECN marks with DiffServ and handle multiclass traffic (voice/real > time streaming vs video downloads etc.) much more efficiently. > > I look forward to seeing a diffserv enabled implementation of pie or > pie-fq. In the "sqm-scripts" package for openwrt and cerowrt, there is > the ability to test variants of a 3 tier classification scheme, with > pie, codel, fq_codel, multiple test *codel variants, sfq, sfb, and > fifo qdiscs. Extensive benchmark results are available, and you are > perfectly welcome to merely run these scripts on any linux distro > shipped in the past 2 years. > Our DiffServ+PI design was published here: http://dna-pubs.cs.columbia.edu/citation/paperfile/31/Chait_02.pdf - I'll take a look at the distribution and see if we can implement our scheme with openwrt. > Essentially this 3 tier scheme is what has deployed in many > aftermarket home router distributions, and in netgear's dynamic QoS. > What streamboost does (partially fq_codel based) is a bit different, > attempting to provide bandwidth garuntees for various services like > netflix, and it's too confusing to describe here. > Our DiffServ design did something very close to that - offered a minimum guaranteed rate (MGR) for the AF service using two-colored marking. > -- > Dave Täht > > thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks -Vishal -- http://www.cs.columbia.edu/~misra/ _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
