Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>,
	Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] diffserv3 vs diffserv4
Date: Sat, 25 Jul 2020 20:47:58 +0300	[thread overview]
Message-ID: <6A1D79C2-1666-4879-BF90-A58088F4C9FE@gmail.com> (raw)
In-Reply-To: <4E86E73D-2ACE-4952-8A2A-B8DAAD4CD262@gmx.de>

> On 25 Jul, 2020, at 8:18 pm, Sebastian Moeller <moeller0@gmx.de> wrote:
> 
> I am confused... but I am also confused by cake's output:
> 
>                   Bulk  Best Effort        Voice
>  thresh       3062Kbit       49Mbit    12250Kbit"
> 
> as far as I can tell, Bulk's 3062Kbit must be the minimum, while BE and Voice give their maxima... That, or I am missing something important...
> (I wonder whether it would not be clearer to give both min and max for each tin, then again I probably missing all the deyails of the actual implementation...)

Cake delivers from the highest-priority tin that both has data to send and is "behind" its local schedule, defined by the threshold rate.  If no tin with data to send is behind schedule, then some tin that does have data to send is chosen (so Cake as a whole is work-conserving, modulo its global shaper).  IIRC, it'll be the highest priority such tin.

The notion of which tin is highest priority is a little counter-intuitive.  One tin must be at the global shaper rate, and will be the lowest priority tin - and normally that is the "best effort" tin.  So the BK tin is actually at a higher priority, but only up to its very limited threshold rate.  To avoid starving the best effort tin under all possible combinations of traffic, it is necessary and sufficient to ensure that the sum of all higher-priority tins' threshold rates is less than the global rate.

In the case of Diffserv3, the BK and VO tins both have higher priority than BE and sum to 5/16ths of the global rate. So with all tins saturated, the BE traffic gets 11/16ths which is pretty respectable.  If the BE and VO traffic goes away, BK is then able to use all available bandwidth.

 - Jonathan Morton


  reply	other threads:[~2020-07-25 17:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-24 15:56 Justin Kilpatrick
2020-07-24 17:42 ` Kevin Darbyshire-Bryant
2020-07-25 10:12   ` Kevin Darbyshire-Bryant
2020-07-25 17:18     ` Sebastian Moeller
2020-07-25 17:47       ` Jonathan Morton [this message]
2020-07-25 17:48     ` David P. Reed
2020-07-25 17:54       ` Kevin Darbyshire-Bryant
2020-07-25 19:35         ` David P. Reed
2020-07-25 20:04           ` Sebastian Moeller
2020-07-25 21:33             ` Kevin Darbyshire-Bryant
2020-07-25 21:27           ` Jonathan Morton
2020-07-25  3:13 ` Jonathan Morton
2020-07-25 17:05   ` David P. Reed

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=6A1D79C2-1666-4879-BF90-A58088F4C9FE@gmail.com \
    --to=chromatix99@gmail.com \
    --cc=cake@lists.bufferbloat.net \
    --cc=kevin@darbyshire-bryant.me.uk \
    --cc=moeller0@gmx.de \
    /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