[Codel] hardware multiqueue in fq_codel?

[Dave Taht]

On Fri, Jul 12, 2013 at 1:47 PM, Eric Dumazet <eric.dumazet at gmail.com> wrote:
> 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 that
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 in
the 90s, so my skills are out of date, the hair loss still memorable, and the
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)

>
>



-- 
Dave Täht

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