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

[Dave Taht <[e-mail]>]

On Wed, Jan 28, 2015 at 4:55 AM, KK <[e-mail]> 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: [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
>
>



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks