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

[Dave Taht <[e-mail]>]

On Tue, Jan 27, 2015 at 9:34 AM, Vishal Misra <[e-mail]> wrote:
>>
>>   We should (IMHO) note that it's many years since its use in congestion
>> control could possibly be "the same as packet drop" -- and by the nature
>> of AQM, packets need to be ECN-marked before anything must be dropped
>> due to buffer overflow.
>>
>>   Obviously (IMHO), an ECN-capable packet which encounters buffer
>> overflow needs to be dropped: not held until it can be ECN-marked and
>> forwarded.
>>
>
> John,
>
> Couldn't agree more.

Actually what happens on overflow in fq_codel is a packet from the
largest flow is dropped from
it's head, regardless of it's ecn marking. The ingress packet is
always accepted in the current implementation. It is certainly
possible to change this behavior, but as overflow is a very rare case
with the default packet limit, it does not seem to be a problem in
practice.

ecn is enabled by default in fq_codel. Some notes on actual use I've
seen are that it is entirely possible to have a fully utilized, low
latency, drop free network, and that at typical or long RTTs drop/mark
percentages decrease proportional to the rate of transmittal to
inconsequential values, while still preserving low latency and
throughput.

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 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.

http://www.pollere.net/Pdfdocs/QrantJul06.pdf page 14.

> With a PI(E) like scheme you can proactively ECN mark packets, keep the delays low but still

I note that the pie implementation in linux does, indeed, implement
ecn. (it is not enabled by default, you can enable it by specifying
the ecn parameter at instantation) However, due to the method it uses
for avoiding overflow, it will still drop ecn marked packets, when
perhaps it shouldn't, due to the randomized time it reacts within. I
have plenty of packet captures showing ecn and non ecn behaviors for
all the proposed aqm and packet scheduling schemes.

The current linux codel's ecn implementation is fully deterministic,
as is fq_codel's. I have a version under test that is also
deterministic but more explicitly handles the more dramatically out of
bounds  conditions by dropping, rather than marking ecn-marked
packets, before the overall queue limit is hit. That portion of the
revised algorithm works well, but there is another tweak that isn't
working, and no further development has been funded.

>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.

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.

Since there seemed to be no interest in the ietf for documenting what
has deployed, I have not taken this draft any further,
http://snapon.lab.bufferbloat.net/~d/draft-taht-home-gateway-best-practices-00.html

Work proceeds slowly on "cake", which incorporates what works so far
in the above deployments in pure C, and adds full diffserv support to
multiple levels of fq_codel. Patches for that are available on
request. I am told there are several wfq + codel implementations being
developed, and there is out there somewhere, an fq-pie.

> -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