Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
Cc: Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] diffserv3 vs diffserv4
Date: Sat, 25 Jul 2020 19:18:48 +0200	[thread overview]
Message-ID: <4E86E73D-2ACE-4952-8A2A-B8DAAD4CD262@gmx.de> (raw)
In-Reply-To: <0CCA78BD-201C-4668-A013-24A3F6F4EC87@darbyshire-bryant.me.uk>

Hi Kevin,


> On Jul 25, 2020, at 12:12, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
> 
> 
> 
>> On 24 Jul 2020, at 18:42, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
>> 
>> 
>> The move from diffserv4 to diffserv5 WAS about de-prioritization.
> 
> It was also about minimum bandwidth allocations:
> 
> LE: 1/64th

That is 6 binary orders of magnitude, on a slow link, LE is effectively starved and there will be no real forward progress. For real scavenger services this might well be a sane policy, but this requires the very selective with assigning flows to this tin ;)

> BK: 1/16th
> BE: 1/1
> VI: 1/2
> VO: 1/4

So I see 1/64 + 1/16 + 1/1 + 1/2 + 1/4 = 1.828125 which seems excessive for actually guaranteed minimums. I was under the naive? impression the minima should add up to <= 1, no?


> 
> So worst case, best effort should get 11/64ths in the extreme case of all other tins in use.

	This seems only true, if on overload the lowest prioritiers tiers get their allotment first, no?

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...)

Best Regards
	Sebastian

> 
> Cheers,
> 
> Kevin D-B
> 
> gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A
> 
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake


  reply	other threads:[~2020-07-25 17:18 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 [this message]
2020-07-25 17:47       ` Jonathan Morton
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=4E86E73D-2ACE-4952-8A2A-B8DAAD4CD262@gmx.de \
    --to=moeller0@gmx.de \
    --cc=cake@lists.bufferbloat.net \
    --cc=kevin@darbyshire-bryant.me.uk \
    /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