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
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
