[Bloat] [aqm] the cisco pie patent and IETF IPR filing

[Dave Taht]

On Thu, Apr 9, 2015 at 12:27 PM, Steinar H. Gunderson
<sgunderson at bigfoot.com> 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