From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (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 32B7E21F1C1 for ; Fri, 12 Jul 2013 11:06:57 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id a11so14091475iee.20 for ; Fri, 12 Jul 2013 11:06:56 -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=VnBMKP/JclKM0Q5eEhputZgo6MUr9rrW96x5CZQpMUM=; b=UIhp6yTft3jfl7ENJsBI15N78uYPZP/dV9Rvi81iIW3qeOG5+gH94M0AjOAAALADNV 56F86CFCq8xsE1ixtIkgRG2v+Iu/O9hJAL8FbEOqcZUq3SemhrUiojEpembBmf/+Mx8o ytIBKVWrghdJoy/hBSxv8NxmNClp4yMR1kXVP+YGrwho0Z16njfvAeWsT0yDfuO8gNQk n3BZauYYx7GbJFyxQMKsJrkZAEO/Xsf6Fm1zU2BlE6E+n3yVJYXObG2SOFpksSVhXSOa 05KzsxTHAmeGc7Rct85CX7iEcvif1HhHM6srqXWd+TgG5Qt5TgNfOijENmpRiLjYlVED rDsQ== MIME-Version: 1.0 X-Received: by 10.42.133.66 with SMTP id g2mr13174447ict.49.1373652416590; Fri, 12 Jul 2013 11:06:56 -0700 (PDT) Received: by 10.64.98.162 with HTTP; Fri, 12 Jul 2013 11:06:56 -0700 (PDT) In-Reply-To: <1373651221.10804.37.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> <1373651221.10804.37.camel@edumazet-glaptop> Date: Fri, 12 Jul 2013 14:06:56 -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 18:06:57 -0000 On Fri, Jul 12, 2013 at 1:47 PM, Eric Dumazet wrot= e: > On Fri, 2013-07-12 at 13:35 -0400, Dave Taht wrote: > >> Against a syn flood attack? > > > Yes. SYNACK messages are in the band 1. SYNACK messages might be > dropped, but your precious management traffic will not. I think I'm beginning to gain clue here, in that 1) in a big outward facing deployment, some work is done to ensure that certain kinds of traffic ends up in the priority queue, by matching against a range of internal ips, etc. Sure, this always happens and is another good argument for a multiband solution, but I note that those deployments have special requirements in general as you've noted from the htb scheme you've had to deal with. And/or 2) there is in-kernel stuff that utilizes skb->priority to ensure t= hat some other in-kernel systems (like the synack defense) do that? Which is what I think you mean... (?) so I'll go poke around there. I have treated that feature as a black box, sorry. I should probably try to return this thread to establishing "a reasonable default for desktops, servers, androids, routers, etc" and having a mechanism to provide that at kernel buildtime... but we're making progress, so... > >> >> > 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. > > Most servers coping with synflood or any kind of traffic flood do not > use openwrt ;) Heh. I have plenty of other servers at linode, I just don't attack them, because then I get nasty notes from their management. I ran operations for a large ISP and later a large banner ad company back i= n the 90s, so my skills are out of date, the hair loss still memorable, and t= he tools I use to protect them (things like xinetd) archaic. I should probably have said merely that syn flooding stuff in sysctl is turned on, and to me, it was a magic option that I (still) have no idea how it works, so if I'm reading your mind correctly about an innate usage of pfifo_fast, cool, I'll go read. I know it's a wild and wooly internet, believe me. I rant on ECN a bit... But I do not as a rule talk about security/attack problems publicly. I should probably note that a reason for wanting a service guarantee for a background queue is part of a half thought out approach towards being able to deal with certain kinds of floods better (ICMP etoobig and related in particular. If it was up to me I'd toss nearly all non-link-local icmp traffic into a background queue) The design goal is "something less horrible than pfifo_fast". It is good to identify features and problems and to figure out what can be solved to move along incrementally. and a mechanism for enabling it (or whatever) > > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html