From: "Luis E. Garcia" <luis@bitamins.net>
To: cake@lists.bufferbloat.net, codel@lists.bufferbloat.net
Subject: Re: [Cake] Proposing COBALT
Date: Fri, 20 May 2016 10:37:37 -0600 [thread overview]
Message-ID: <CALnBQ5mNgHgFoTcvLxppv2P9XODc4D-4NObKyqbZJ0PccVkwiA@mail.gmail.com> (raw)
In-Reply-To: <857AEE56-E7DB-4981-B32E-82473F877139@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2387 bytes --]
Jonathan,
I think this would be a great idea to implement and test.
Can COBALT's behavior be easily implemented to test it using the OpenWRT or
LEVE ?
Regards,
Luis
On Fri, May 20, 2016 at 8:36 AM, Jonathan Morton <chromatix99@gmail.com>
wrote:
> >> If the relative load from the flow decreases, BLUE’s action will begin
> to leave the subqueue empty when serviced, causing BLUE’s drop probability
> to fall off gradually, potentially until it reaches zero. At this point
> the subqueue is naturally reset and will react normally to subsequent
> traffic using it.
> >
> > But if we reach a queue length of codel’s target (for some small amount
> of time), would that not be the best point in time to hand back to codel?
> Otherwise we push the queue to zero only to have codel come in and let it
> grow back to target (well approximately).
>
> No, because at that moment we can only assume that it is the heavy
> pressure of BLUE that is keeping the queue under control. Again, this is
> an aspect of Codel’s behaviour which should not be duplicated in its
> alternate, because it depends on assumptions which have been demonstrated
> not to hold.
>
> BLUE doesn’t even start backing off until it sees the queue empty, so for
> the simple and common case of an isochronous flow (or a steady flood
> limited by some upstream capacity), BLUE will rapidly increase its drop
> rate until the queue stops being continuously full. In all likelihood the
> queue will now slowly and steadily drain until it is empty. But the load
> is still there, so if BLUE stopped dropping entirely at that point, the
> queue would almost instantly be full again and it would have to ramp up
> from scratch.
>
> Instead, BLUE backs off slightly and waits to see if the queue *remains*
> empty during its timeout. If so, it backs off some more. As long as the
> queue is still serviced while BLUE’s drop probability is nonzero, it will
> back down all the way to zero *if* the traffic has really gone away or
> become responsive enough for Codel to deal with.
>
> Hence BLUE will hand control back to Codel only when it is sure its extra
> effort is not required.
>
> - Jonathan Morton
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
[-- Attachment #2: Type: text/html, Size: 2928 bytes --]
next prev parent reply other threads:[~2016-05-20 16:37 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-20 10:04 Jonathan Morton
2016-05-20 11:37 ` moeller0
2016-05-20 12:18 ` Jonathan Morton
2016-05-20 13:22 ` moeller0
2016-05-20 14:36 ` Jonathan Morton
2016-05-20 16:03 ` David Lang
2016-05-20 17:31 ` Jonathan Morton
2016-05-20 16:37 ` Luis E. Garcia [this message]
2016-05-20 16:43 ` Jonathan Morton
2016-05-20 16:55 ` Luis E. Garcia
2016-05-23 18:30 ` Jonathan Morton
2016-05-23 19:11 ` Luis E. Garcia
2016-05-24 13:47 ` [Cake] [Codel] " Jeff Weeks
2016-05-24 14:07 ` Jonathan Morton
2016-05-24 15:52 ` Dave Täht
2016-05-24 15:56 ` Jonathan Morton
2016-05-24 16:02 ` Dave Taht
2016-05-25 6:40 ` Loganaden Velvindron
2016-05-25 12:00 ` Benjamin Cronce
2016-05-26 12:33 ` Jonathan Morton
2016-06-03 19:09 ` Noah Causin
2016-06-03 19:34 ` Jonathan Morton
2016-06-04 1:01 ` Andrew McGregor
2016-06-04 6:23 ` Jonathan Morton
2016-06-04 13:55 ` Jonathan Morton
2016-06-04 14:01 ` moeller0
2016-06-04 14:16 ` Vincent Frentzel
2016-06-04 14:16 ` Jonathan Morton
2016-06-04 15:03 ` moeller0
2016-06-04 17:10 ` Noah Causin
2016-06-04 17:49 ` Eric Dumazet
2016-06-04 19:55 ` Jonathan Morton
2016-06-04 20:56 ` Eric Dumazet
2016-06-27 3:56 ` Jonathan Morton
2016-06-27 7:59 ` moeller0
2016-06-27 15:18 ` Kevin Darbyshire-Bryant
2016-06-28 2:51 ` Jonathan Morton
2016-06-28 8:40 ` Kevin Darbyshire-Bryant
2016-06-28 15:33 ` Jonathan Morton
2016-06-28 17:37 ` Kevin Darbyshire-Bryant
2016-06-29 15:22 ` Kevin Darbyshire-Bryant
2016-06-30 8:16 ` Kevin Darbyshire-Bryant
2016-06-28 15:44 ` Dave Taht
2016-05-20 13:41 ` [Cake] " David Lang
2016-05-20 13:46 ` moeller0
2016-05-20 14:04 ` David Lang
2016-05-20 15:12 ` Jonathan Morton
2016-05-20 16:05 ` David Lang
2016-05-20 17:06 ` Jonathan Morton
2016-05-20 16:20 ` [Cake] [Codel] " Rick Jones
2016-05-20 16:35 ` Jonathan Morton
2016-05-20 17:01 ` Rick Jones
2016-05-20 17:07 ` Jonathan Morton
2016-05-20 17:21 ` Rick Jones
2016-05-20 17:26 ` David Lang
2016-05-20 17:33 ` Jonathan Morton
2016-05-20 14:09 ` [Cake] " Jonathan Morton
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=CALnBQ5mNgHgFoTcvLxppv2P9XODc4D-4NObKyqbZJ0PccVkwiA@mail.gmail.com \
--to=luis@bitamins.net \
--cc=cake@lists.bufferbloat.net \
--cc=codel@lists.bufferbloat.net \
/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