Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: Benjamin Cronce <bcronce@gmail.com>
Cc: cake@lists.bufferbloat.net, Felix Fietkau <nbd@nbd.name>
Subject: Re: [Cake] cake work needed for openwrt merge
Date: Tue, 8 Sep 2015 09:20:20 +0200	[thread overview]
Message-ID: <C7FE1926-1916-45FA-9EE3-4C466B62D5E3@gmx.de> (raw)
In-Reply-To: <CAJ_ENFH3mNzSSkWaeTbav5YKmaDi05XKSdyBEGLUAwObo=71hg@mail.gmail.com>

Hi Benjamin,


On Sep 8, 2015, at 00:31 , Benjamin Cronce <bcronce@gmail.com> wrote:
> [...] 
> It may be easier to use a distance based naming. Instead of something like "High(250ms) RTT" be like "Inter-continental", medium(100ms) RTT may be "Intra-continental", and low(50ms) RTTs may be "Local Region". "Region" can be a bit ambiguous, but I figured if given two options "Local Region" and "Intra-continental", that the idea of what "region" represents in this context is clear enough. Satellite links would only need one option because the latency of the satellite will be greater than the latency from all of the terrestrial links combined. As for the actual variable name and not the option names. hmmm. Assuming similarly named options, "Optimize for"?
> [...]

For the crowd on this mailing list any names will do, but for novices that just heard of buffer bloat and its remedies, I believe we need simple unambiguous names. The challenge with distance is that while geographical distance should not be too hard to figure out, path distance is much trickier (aka true user will need i measure). If I recall correctly, codel is actually pretty robust against deviations of true RTTs from interval, but I do not remember any data showing this on a per true RTT basis or for fq_codel (where I assume the issue might be more pronounced, as the different RTT flows will be separated unlike in codel where all is mixed).


Best Regards
	Sebastian

  parent reply	other threads:[~2015-09-08  7:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-06 22:35 Dave Taht
2015-09-07  7:35 ` Sebastian Moeller
2015-09-07 10:45 ` Dave Taht
2015-09-07 11:21   ` Sebastian Moeller
2015-09-07 19:43     ` Benjamin Cronce
2015-09-07 20:35       ` Sebastian Moeller
2015-09-07 20:37         ` Dave Taht
2015-09-07 22:31         ` Benjamin Cronce
2015-09-07 22:44           ` Jonathan Morton
2015-09-08  7:20           ` Sebastian Moeller [this message]
2015-09-09 23:54             ` Benjamin Cronce
2015-09-29 13:41 ` Sebastian Moeller

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=C7FE1926-1916-45FA-9EE3-4C466B62D5E3@gmx.de \
    --to=moeller0@gmx.de \
    --cc=bcronce@gmail.com \
    --cc=cake@lists.bufferbloat.net \
    --cc=nbd@nbd.name \
    /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