From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 0A2B121F1C1 for ; Fri, 12 Jul 2013 10:35:47 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id f4so21053181iea.11 for ; Fri, 12 Jul 2013 10:35:47 -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=GwWZWfPlEbptjb59qH5GFrLNPyG5SgbyRu1aSlpiVlw=; b=pHcrmCRYDmTGwo2K9Q68fTb3mxpC1DBXLQD6bBMHbG7HUO1if94Rz9aWirqfOW0V3q XfEQaCRktdIxUXFMzLeX8Rsy0aQlCuP/YLgkpVnD4+NUBG5Onlx5+pQxxZFifjQIheac M2c1MiUztkvcgZxqZFVDKIEwqnlOBOex9ANxyCneUXN4BzaXX3Oq+PnKXM+vBUcLHFju 2GZglX1fRMzx+24QL08phX8dCBSx4SsmtZ01J7rRm6v6sUmAXMVUwWbt3/4GFFPVqtUk Az4JRk75funlOAE0h/kohwWpLAacHzG0Hwj79Hjj99SO9LebGEbjKJLEcsgMirASTymI vC9A== MIME-Version: 1.0 X-Received: by 10.42.133.66 with SMTP id g2mr13140395ict.49.1373650547424; Fri, 12 Jul 2013 10:35:47 -0700 (PDT) Received: by 10.64.98.162 with HTTP; Fri, 12 Jul 2013 10:35:47 -0700 (PDT) In-Reply-To: <1373649589.10804.34.camel@edumazet-glaptop> References: <1373564673.4600.55.camel@edumazet-glaptop> <1373568848.4600.66.camel@edumazet-glaptop> <20130712113413.4b601800@redhat.com> <1373642001.10804.18.camel@edumazet-glaptop> <1373647842.10804.28.camel@edumazet-glaptop> <1373649589.10804.34.camel@edumazet-glaptop> Date: Fri, 12 Jul 2013 13:35:47 -0400 Message-ID: From: Dave Taht To: Eric Dumazet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: codel@lists.bufferbloat.net, Jesper Dangaard Brouer Subject: Re: [Codel] hardware multiqueue in fq_codel? X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 17:35:48 -0000 On Fri, Jul 12, 2013 at 1:19 PM, Eric Dumazet wrot= e: > On Fri, 2013-07-12 at 12:54 -0400, Dave Taht wrote: > >> My point was that same program would be just as damaging against >> pfifo_fast. >> >> > Or just think of SYN flood attack. >> >> For which other defenses exist. > > If someone uses pfifo_fast, it needs no particular protection right now > to be able to log in into his machine. Against a syn flood attack? > Thats the point you absolutely missed. Its kind of incredible. I guess I'm still entirely missing it. By default the networks I have are protected by the syn_flood mechanism as enabled in openwrt. I have hit them with attack tools like thc and related stuff, and well, that list is rather incredibly large but not bound to the queue type and I'd rather discuss it offlist. So if you can point me at some code that thoroughly disables fq_codel worse than pfifo_fast (offlist), I'll gladly run it on the testbed here, against everything: http://results.lab.taht.net/ One of the big reasons why I haven't advocated a smaller number of flows by default in fq_codel was due to the attack protection I surmised it + the permuted hash - provided. > If fq_codel could replace pfifo_fast as is, why do you think I did not > submit the patch doing the change ???? I have generally always thought a three tier system was still needed, just far less so. The characteristics of that system are what we are discussing now. The time spent analyzing fq_codel's behavior > > > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html