[Cake] UDP floods and taking advantage of egress signalling at ingress
david at lang.hm
Fri May 6 03:50:21 EDT 2016
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.
More information about the Cake