From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by huchra.bufferbloat.net (Postfix) with ESMTP id 6AB0821F1C1 for ; Mon, 15 Jul 2013 05:56:40 -0700 (PDT) Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6FCucpC024198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Jul 2013 08:56:38 -0400 Received: from localhost (ovpn-116-55.ams2.redhat.com [10.36.116.55]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r6FCua3Q009319; Mon, 15 Jul 2013 08:56:37 -0400 Date: Mon, 15 Jul 2013 14:56:33 +0200 From: Jesper Dangaard Brouer To: Eric Dumazet , Dave Taht Message-ID: <20130715145633.3c10b646@redhat.com> 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> Organization: Red Hat Inc. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Cc: codel@lists.bufferbloat.net 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: Mon, 15 Jul 2013 12:56:40 -0000 On Fri, 12 Jul 2013 10:19:49 -0700 Eric Dumazet wrote: > 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. I actually like your SSH use-case better than, the high-avail heartbeat use-case, as the HA guys should just change the qdisc by-hand, as they (should) know what they are doing (setting up their complicated configs). Then I say: Not if the attacker also sets the TOS bits. Then you say: But the TOS bits should be stripped at the border-gateway. Then I say: But my server is at a cloud provider, thus I'm logging remotely and the cloud provider is stripping my SSH TOS bits. Thus, its not helping me... ;-) You SSH use-case is more valid, but when we are under real hard SYN DoS-attacks then all CPU are pinned down on the listen-spinlock problem... troll running away hiding ;-) ps. I usually have a separate NIC on the machine for management/SSH (using ip rule, routing tables to ensure this NIC have a seperate default gateway). -- Best regards, Jesper Dangaard Brouer MSc.CS, Sr. Network Kernel Developer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer