General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: David Collier-Brown <davec-b@rogers.com>
To: bloat@lists.bufferbloat.net
Subject: [Bloat] Cascading proportionality, not fairness.
Date: Tue, 27 Nov 2012 19:59:51 -0500	[thread overview]
Message-ID: <50B56207.7030905@rogers.com> (raw)
In-Reply-To: <mailman.4220.1354056563.1742.bloat@lists.bufferbloat.net>

Jim Gettys <jg@freedesktop.org> wrote:
> at an ISP, you must to be "fair" between customers; it is best to leave
> the judgement of "fairness" at finer granularity (e.g. host and TCP flows)
> to the points closer to the customer's systems, so that they can enforce
> whatever definition of "fair" they need to themselves.

I too hate the overloaded term, and would argue it's just wrong.
Instead, we are discussing /proportionality/, and what we know about the
ISP is very generally applicable.

The ISP deliver proportional amounts of latency (or freedom from
latency) to a community of customer devices, one of which might be a
home router.

The router delivers the upstream services proportionally to a kid's
machine, to dad and mom, and to the TV or perhaps the dedicated skype phone.

The latter two devices have some fixed requirements: a certain number of
frames per second, a certain number of seconds of audio and the like.
This is the hardest, but it has limits. Delivering much more than X
frames a second over a long period is wasted effort. Delivering less
than X for a short period yields dropouts. Therefor such a service can
be statically provisioned, and rejected if there are already too many
sessions to leave enough resources meet its needs.

Fq_codel only has to deliver its usual guarantees: statically
oversubscribing the link isn't its problem. The router does have to have
the smarts to not commit logical suicide, or over-commit too greatly in
cases where an over-commitment is allowable, but that's a different
problem than fq addresses. That's an issue of capacity planning.

Similarly, delivering a guaranteed minimum of service to each subscriber
isn't a fair queuing or a fairness problem. It's one of setting a policy
and enforcing it. It, like the audio/video problem is one of capacity
planning, and proportionality.  The parents can say "same service to
anyone", or they can say "no A/V during homework hours". Outside of
homework hours, they can say "gaming takes precedence over the PVR, but
not over skype", and so on.

On the kid's machine, we still want to use fq to keep downloads from
messing up gaming and A/V, but the kid has to set the policy as to who
ultimately wins.

Jim is right: this really isn't fairness.  I'd reserve that term for
fq_codel and friends, call all the capacity planning considerations
"proportionality". I'd also assume every node in the net thinks like an
ISP and wants to start off by handing out equal response times to its
entire set of "customers", and change that only if explicitly told to.

--dave

           reply	other threads:[~2012-11-28  0:56 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <mailman.4220.1354056563.1742.bloat@lists.bufferbloat.net>]

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/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50B56207.7030905@rogers.com \
    --to=davec-b@rogers.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=davecb@spamcop.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