On Thu, Apr 9, 2015 at 12:27 PM, Steinar H. Gunderson <[email protected]> wrote: > On Thu, Apr 09, 2015 at 12:24:03PM -0700, Dave Taht wrote: >> disagree with me, thinking that aqm + ecn alone is safe to deploy, and >> obviously I promote fq_codel derived stuff on routers (and sch_fq on >> well protected servers), far more than pie, although I am careful to >> maintain that I can´t wait to see pie (without ecn) on cablemodems one >> day RSN. > > Can you elaborate on what you mean by “well protected”? I usually recommend > sch_fq for end hosts pretty much uncritically, so if there's a snag, I'd love > to hear about it.
I am very impressed with sch_fq overall. However it optimizes overmuch for new connections, with a default quantum of a full IW10, which leaves it vulnerable to DDOS attacks, thus these days I say "well protected" in the expectation that the servers serving data are behind boxes doing better firewall and DDOS management. Recently some mods to sch_fq landed to make it a bit safer to more widely deploy on more kinds of traffic than just web servers, the relevant patch by eric dumazet is: https://www.marc.info/?l=git-commits-head&m=142362949328825&w=3 He is also doing some work to make syn flood handling more robust elsewhere in the kernel but I do not think that has landed yet. In it´s present form, sch_fq is for some kinds of servers, not routers, nor stuff that is generating tons of udp traffic (I think) A VM is a server, but the bare metal underneath is a router. fq_codel is a much safer default for general use, and sch_fq more of a (really nice) specialized option, at this point. Some of this is just my opinion, based on observations of several attacks I made against it with some attack tools - but you know who to ask internally for their opinion and data. I would welcome coherent guidance about how when and where to use sch_fq, AND to deal with DDOSes. I learned more about DDOS stuff from a recent cloudflare preso than I ever wanted to know. I look forward to seeing someone try to add, say "pie", to sch_fq, to make it safer to use in that case, and also to handle the case where sch_fq is turned on in a router when it shouldn´t be. I finally got around to benchmarking sch_fq vs fq_codel vs cake and some other stuff recently in a 115/12Mbit cable emulation, and you can clearly see sch_fq misbehaving as it lets routed queue lengths get out of hand. That latest netperf-wrapper data set is here: http://snapon.lab.bufferbloat.net/~d/cake3-fixed-tests.tgz While I expect cake to fill a very needed niche, we still have not arrived at the one true, all singing, all dancing, queue managment system - but BOY! have we come a long way in a few years. Still, I think better ethernet devices and switch chips are going to be needed in the long term to make our networks faster and loss free, and hope to sink more time into prototyping those every time I get a break from the make-wifi-fast project. (see .sig. :) ) -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/107942175615993706558/posts/N8mZ5F5iSPU _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
