On Tue, Jun 24, 2014 at 1:01 PM, Fred Baker (fred) <f...@cisco.com> wrote: > > On Jun 24, 2014, at 12:45 PM, Daniel Havey <dha...@yahoo.com> wrote: > >> So IMHO it really doesn't matter except in the weird corner case where a a >> running flow has already bloated the queue and then we switch on the AQM.
Hmm? In practice, changing the qdisc in Linux, at least, does completely blow up the existing queue: all packets are discarded, the various data structures removed, the new data structures created, then switched. Don't do that. Do it once, at init time, or before address acquisition. Simple schemes can be handled now (linux 3.13 and later) by a single sysctl variable, set either in /etc/sysctl.conf or via sysctl -w net.core.default_qdisc=fq_codel # or pie, or sfq, or fq Arguably this needs to allow for arguments, be more flexible and interface specific. Same goes for enabling ecn or not. (net.ipv4.tcp_ecn=0) More complex implementations, like htb, have a "default" direction things go until things are fully setup. Other linux implementations, like drr and qfq, do not, and result in packet loss until entirely setup. Recently support for a "plug scheduler" was developed in order to assist vm migration, which might make it more possible to switch out qdiscs without interrupting service. > That actually has me a little worried with the 100 ms delay built into codel. "Initial delay" until it finds a sane delay to drop at. >Imagine, if you will, that you have a deep buffer at the bottleneck and a >relatively short RTT, and are moving a large file. I could imagine codel’s >delay allowing a session to build a large backlog and then “suddenly turning >on AQM”. on a 10 MS link with O(200) packets queue depth, for example, you >could build 100 ms plus of data in the queue, spend the delay mostly emptying >it, and then drop the last queued packet because 100 ms had gone by, there was >still data in the queue, and the next packet had sat there longer than 5 ms. Given that pie depends on an estimation window being filled this is not a problem pie has. However needing that window filled is a big problem at low bandwidths for pie. As for codel.... Well there is a specific inhibit in present forms of codel to not drop the last packet in the queue even if it has sat there too long. Codel stops dropping at minbytes (called maxpacket in the code), which is a variable determined from the flow characteristics, and is usually 1MTU in size, but can be larger if TSO or GRO are in operation on the device. The first versions of fq_codel preserved this behavior: it would never drop the last packet in any fq_codel queue. This (still) seems like desirable behavior in the case of having nearly one queue per flow, but it led inevitably to what I had called the horizontal standing queue problem (where we could end up with 1024 queues all with one packet and no longer meeting the latency target(s)). So eric made the backlog maxpacket check global to all queues, and that's what's been deployed ever since. Later work, (I think) is showing, that in practice any inhibit at all hurts on the architectures available, as htb or (bql and the tx-ring) are already buffering up packets below where codel was dropping from near-head. More packets will always be along, later. This patch disables the maxpacket check entirely, and results in a space and cpu savings, without much observable negative or positive effect on latency and utilization on the bandwidths available to me. I remain a bit concerned about what happens with TSO and/or GRO enabled. http://snapon.lab.bufferbloat.net/~cero2/0003-codel-eliminate-maxpacket-variable.patch I'd love it if people tried it. Of higher concern to me has long been more sanely applying hysteresis in the drop rate over wildly varying high bandwidths and loads, but not a lot of work has gone into codel since it's inception, as it was so good to start with and so dramatically improved by fq_codel as to be barely worth debating. But certainly better control laws are welcomed! > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm