From: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
To: Dave Taht <dave.taht@gmail.com>
Cc: <cake@lists.bufferbloat.net>
Subject: Re: [Cake] UDP floods and taking advantage of egress signalling at ingress
Date: Tue, 10 May 2016 10:05:35 +0100 [thread overview]
Message-ID: <5731A45F.5070109@darbyshire-bryant.me.uk> (raw)
In-Reply-To: <CAA93jw6i8MEk9HUwffF=eW7S9C5+ykjdc7JJR4gKm_7gyeQTmQ@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2016-05-10 9:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-06 7:29 Kevin Darbyshire-Bryant
2016-05-06 7:38 ` Dave Taht
2016-05-06 7:48 ` Kevin Darbyshire-Bryant
2016-05-10 9:05 ` Kevin Darbyshire-Bryant [this message]
2016-05-06 7:50 ` David Lang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5731A45F.5070109@darbyshire-bryant.me.uk \
--to=kevin@darbyshire-bryant.me.uk \
--cc=cake@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox