[Codel] fq_codel_drop vs a udp flood

[Dave Taht]

On Sun, May 1, 2016 at 10:59 AM, Eric Dumazet <eric.dumazet at gmail.com> wrote:
> On Sat, 2016-04-30 at 20:41 -0700, Dave Taht wrote:
>> >>>
>> >>>     45.78%  [kernel]       [k] fq_codel_drop
>> >>>      3.05%  [kernel]       [k] ag71xx_poll
>> >>>      2.18%  [kernel]       [k] skb_release_data
>> >>>      2.01%  [kernel]       [k] r4k_dma_cache_inv
>>
>> The udp flood behavior is not "weird".  The test is wrong. It is so filling
>> the local queue as to dramatically exceed the bandwidth on the link.
>
> Well, just _kill_ the offender, instead of trying to be gentle.

I like it. :) Killing off a malfunctioning program flooding the local
network interface (intentionally or unintentionally) seems like a
useful idea.

it will break some test tools that deserve to be broken, too.

> fq_codel_drop() could drop _all_ packets of the fat flow, instead of a
> single one.
>
> It is too cpu intensive to be kind to the elephant, since under pressure
> fq_codel_drop() needs to be called for every enqueue.

A somewhat gentler approach might be drop 3 packets or more per
fq_codel_drop round - or "nearly" the entire flow (all but the last
packet).

But sure, dropping *all* of an unresponsive elephant (as more will be
arriving), in the event of the extreme overload that hitting
fq_codel_drop represents, sounds pretty good.

> Really, we should not try to let inelastic flows hurt us.

+10.

>
> I can provide a patch.

Killing the bad program, and dropping all of the fattest flow strike
me as two patches.[1]

This approach is akin to some of the thoughts in here:

https://tools.ietf.org/html/draft-ietf-tsvwg-circuit-breaker-14 [2]

... all that said, is there any way to exert flow control on a udp
socket from down in these layers?

[1] what sort of error code should a program killed for flooding the network
 return?

[2] I don't actually agree with some of the thinking in the circuit
breakers doc, but.... this is something of an outgrowth of the
obsolete and wrong source quench idea, which might be useful history
for someone: https://tools.ietf.org/html/rfc6633.






-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org