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. >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 _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
