Because of DCTCP¹s differences in the approach to marking and the different control reaction at the end-system, I have wondered about 2 things: 1) How it interoperates with the flows that have to go over the WAN - where you may have a different marking method, and end-systems that have the traditional TCP end-system reaction 2) What are the limits for the feedback delay with the marking based on the instantaneous queue state that is used - and the proportional controller employed. Thanks, -- K. K. Ramakrishnan Professor Dept. of Computer Science and Engineering University of California, Riverside Rm. 332, Winston Chung Hall Tel: (951) 827-2480
On 1/27/15, 5:30 AM, "Vishal Misra" <[email protected]> wrote: > > >> 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.p >>>df) 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 _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
