On Wed, Jan 28, 2015 at 4:55 AM, KK <[email protected]> wrote: > 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
It is finally easy to test that! Long held in outdated, hard to use, out of tree patches, DCTCP entered the linux mainline kernel recently: http://www.ietf.org/mail-archive/web/aqm/current/msg00804.html And related support infrastructure for finer grained per-route ecn landed shortly thereafter: http://comments.gmane.org/gmane.linux.network/337395 Given the fragility of the needed infrastructure configuration (need ecn on, need dctcp enabled, need the routers and switches on the path configured properly) it is a certainty that someone will accidentally test dctcp in the wan scenario, and it would be good to get an idea for what happens non-accidentally. There is at least one patch, I think, still out of tree, that improved tcp ecn fallbacks for syns. DCTCP also is now available in freebsd: http://lists.freebsd.org/pipermail/freebsd-net/2014-February/037915.html > 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 On short RTTs... with TSO enabled... with GRO enabled... with incast... with short flows... with long flows... with competing traffic.... > 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 > > -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
