Re: [Codel] hardware multiqueue in fq_codel?

[Dave Taht <dave.taht@gmail.com>]

On Fri, Jul 12, 2013 at 1:19 PM, Eric Dumazet <eric.dumazet@gmail.com> 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.

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


>
>
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html