From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id D325921F3E9 for ; Thu, 9 Apr 2015 12:45:37 -0700 (PDT) Received: by obbeb7 with SMTP id eb7so121697503obb.3 for ; Thu, 09 Apr 2015 12:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TNpUUOy77nl4vccWnGBqcs5imuGS0e19JGS3DrcpeTI=; b=gDoQp5+fUZtPolWYSuoMlH1Tsd5egVkIyrs5H2oVsaCY7+aAEZlckMALIr3z9eux0u e8SCw3CafFBf9310f1QOpRzRhPsF6lb6hrBt/6Y86qsFNRi2bpKcYtrHcebtg+ROoXEp vbDjd+UjbAxR7eYEANauyMtowMRwVQj6BXfTZrj4z7k/OC1qPhr1X+gpanGiH6xO7Hqn lY23VHz0IIgz5XdUwxiI7rMefGRpOedqJyJnfuJueHA8SoMAe3H0vj2OvPXpb6yXfh/r Obj23g61dATdSYcEg8JAFHjeJXjS9KIoHuHYaQ0DGRnSpOVmzkp1UYQauTUYythtJ3jB bT9g== MIME-Version: 1.0 X-Received: by 10.60.77.38 with SMTP id p6mr6381548oew.75.1428608736278; Thu, 09 Apr 2015 12:45:36 -0700 (PDT) Received: by 10.202.51.66 with HTTP; Thu, 9 Apr 2015 12:45:36 -0700 (PDT) In-Reply-To: <20150409192732.GA27934@sesse.net> References: <473265656416337848@unknownmsgid> <4077D77B-6C1A-47DF-989C-76B4B99AF863@icloud.com> <20150409192732.GA27934@sesse.net> Date: Thu, 9 Apr 2015 12:45:36 -0700 Message-ID: From: Dave Taht To: "Steinar H. Gunderson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: bloat Subject: Re: [Bloat] [aqm] the cisco pie patent and IETF IPR filing X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 19:46:06 -0000 On Thu, Apr 9, 2015 at 12:27 PM, Steinar H. Gunderson 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=C2=B4t wait to see pie (without ecn) on cablemodems = one >> day RSN. > > Can you elaborate on what you mean by =E2=80=9Cwell protected=E2=80=9D? 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=3Dgit-commits-head&m=3D142362949328825&w=3D3 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=C2=B4s 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=C2=B4t 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. :) ) --=20 Dave T=C3=A4ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/107942175615993706558/posts/N8mZ5F5iSPU