On Tue, Jan 27, 2015 at 12:02 PM, Dave Taht <[email protected]> wrote: > On Tue, Jan 27, 2015 at 9:34 AM, Vishal Misra <[email protected]> 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.
I think I have described that tweak here before. What happens in that version of test codel is that if a drop happens for any reason, the very next packet is attempted to be marked with ECT, if ECN is available. This provides an immediate signal of congestion, while still shedding actual load. If you only hit one flow, you've done that. If you hit two flows, all the better. It works, but real differences in behavior are hard to discern at the typical rates and RTTs I work at, with the benchmarks I have. The same idea could be easily applied to pie. At the moment anything that treats ECN as substantially different to drop in the aqm layer is kind of anathema to me as the control logic has to run very, very fast, and some folk even begrudge the needed packet inspection and if statements required to do the ecn check at all. I do feel, that preserving the current ECN behavior(s) of pie or fq_codel, and exploring different TCP variants on the endpoints to how they react to a mark, might be fruitful more short term and further improvements evolve in sync with the many, many improvements that have happened in TCP over the last few years. >>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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/aqm > > > > -- > Dave Täht > > thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
