Re: [Cake] UDP floods and taking advantage of egress signalling at ingress

[David Lang <david@lang.hm>]

On Fri, 6 May 2016, Kevin Darbyshire-Bryant wrote:

> Hi All,
>
> My brain woke up with this idea rattling around in it this
> morning...obviously the subconscious has been busy.  So here it is:
>
> Is there any way to use the egress drop signalling at ingress time to
> drop stuff before it gets into the queue so then we don't have to drop
> it at egress?
>
> Something like: At enqueue if we've a matching flow check to see if that
> flow had been in egress 'fast dropping' state *and* know how much data
> in terms of time it had to fast drop to get the queue back under the
> nominal time threshold.  If say it had to drop 10ms worth of packets to
> get back to the nominal 5ms threshold then it dropped 67% of the
> packets/data.  I'd like to think of that as an 'unresponsive
> flow'...hence could it be possible to use that information at ingress
> time and in essence drop (some? 66%?) of them there, we can also signal
> congestion to the stack at that point to (cake already does this
> signalling when getting to its buffer size limit)
>
>
> Probably a very silly idea.

If it can be done, this would not be a case of dropping packets, but rather 
blocking the write to the network.

my (semi-informed) knee-jerk reaction is that this would be expensive to signal, 
so not something to do for the normal case, but possibly something worth doing 
in the elephant-flow situation as it could slow a local sender down faster than 
dropping packets and waiting for feedback to signal it to slow down.

David Lang