Re: [aqm] ECN: was Control Theoretic Analyses of PI(E)

[KK <[e-mail]>]

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: [phone]






On 1/27/15, 5:30 AM, "Vishal Misra" <[e-mail]> wrote:

>
>
>> On Jan 26, 2015, at 6:02 PM, Dave Taht <[e-mail]> 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/aqm