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

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

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 1075 bytes --]

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.


-- 
Thanks,

Kevin@Darbyshire-Bryant.me.uk
M: +44 7947 355344 H: +44 1256 478597


[-- Attachment #2: Type: text/html, Size: 1550 bytes --]

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

[Dave Taht]

On Fri, May 6, 2016 at 12:29 AM, Kevin Darbyshire-Bryant
<kevin@darbyshire-bryant.me.uk> 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.

No, actualy, I'd been thinking about the same thing myself for days.
:) I've always wanted a way to notify userspace that I was dropping
(the heck out of) something on egress to try and stuff it up on
ingress, or do something more intelligent like re-route the traffic
elsewhere.

There was a lot of talk about adding the ability to drop stuff really
fast in the rx ring recently using the jit BPF stuff.

I was at a meeting where tom herbert talked about that, and I confess,
extremely dubious. Then... well, I see lots of drops on ingress
already I don't want, the udp flooding episode made me go look harder
at whole system behavior...

and I can't find the lwn article about it.


>
> --
> Thanks,
>
> Kevin@Darbyshire-Bryant.me.uk
> M: +44 7947 355344 H: +44 1256 478597
>
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>



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

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

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 2834 bytes --]

My asleep brain is better than the awake one :-)

Tcp in essence self servos into equilibrium, udp flows (floods) potentially don't. If the protocol doesn't servo then something else should, ideally before buffer full/memory issues make that happen anyway.

Anyway time to switch brain to dayjob mode :-)


--
Cheers,

Kevin@Darbyshire-Bryant.me.uk<mailto:Kevin@darbyshire-bryant.me.uk>
Sent from my phone, apologies for brevity, spelling & top posting

On 6 May 2016, at 08:39, Dave Taht <dave.taht@gmail.com<mailto:dave.taht@gmail.com>> wrote:

On Fri, May 6, 2016 at 12:29 AM, Kevin Darbyshire-Bryant
<kevin@darbyshire-bryant.me.uk<mailto:kevin@darbyshire-bryant.me.uk>> 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.

No, actualy, I'd been thinking about the same thing myself for days.
:) I've always wanted a way to notify userspace that I was dropping
(the heck out of) something on egress to try and stuff it up on
ingress, or do something more intelligent like re-route the traffic
elsewhere.

There was a lot of talk about adding the ability to drop stuff really
fast in the rx ring recently using the jit BPF stuff.

I was at a meeting where tom herbert talked about that, and I confess,
extremely dubious. Then... well, I see lots of drops on ingress
already I don't want, the udp flooding episode made me go look harder
at whole system behavior...

and I can't find the lwn article about it.



--
Thanks,

Kevin@Darbyshire-Bryant.me.uk<mailto:Kevin@darbyshire-bryant.me.uk>
M: +44 7947 355344 H: +44 1256 478597


_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net<mailto:Cake@lists.bufferbloat.net>
https://lists.bufferbloat.net/listinfo/cake




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

[-- Attachment #2: Type: text/html, Size: 6247 bytes --]

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

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 2065 bytes --]



On 06/05/16 08:38, Dave Taht wrote:
> On Fri, May 6, 2016 at 12:29 AM, Kevin Darbyshire-Bryant
> <kevin@darbyshire-bryant.me.uk> 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.
> No, actualy, I'd been thinking about the same thing myself for days.
> :) I've always wanted a way to notify userspace that I was dropping
> (the heck out of) something on egress to try and stuff it up on
> ingress, or do something more intelligent like re-route the traffic
> elsewhere.

Hi Dave et al,

There's a pretty rough sketch of the 'bright idea' (ha!) on
https://github.com/kdarbyshirebryant/sch_cake/tree/ingressegresslink

It doesn't even compile but there's a sort of framework there.  Pointers
(oh dear, unintended pun) assistance, encouragement, nudges welcome. 
Laughter & derision less so but if I'm being dumb as opposed to ignorant
for crying out loud tell me :-)

I'm struggling (as you can probably tell) in codel5.h on how to obtain
the number of bytes we 'fast dropped' in the 'do...while' loop.

Kevin



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

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

[David Lang]

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