From: Jonathan Morton <chromatix99@gmail.com>
To: dpreed@reed.com
Cc: Kathleen Nichols <nichols@pollere.com>,
cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] [Bloat] fq_codel is two years old
Date: Fri, 16 May 2014 01:53:50 +0300 [thread overview]
Message-ID: <CAJq5cE2BPf+fqeigY==BE-6etqHv-ns2GbxAcxK2o5K3E=AHJQ@mail.gmail.com> (raw)
In-Reply-To: <1400185975.95298344@apps.rackspace.com>
[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]
There is, I think, one good way to make Diffserv actually work. It does
require several steps in tandem.
Step one is to accept and admit that differential pricing based on scarcity
economics does not work on the internet. That's going to be tough to
swallow for the big commercial players.
Step two is to define service levels in such a way that asking for a bonus
in one category inherently requires taking a deficit in some other
category. This permits trusting the Diffserv field, wherever it happens to
come from.
That part is where the old TOS flags went wrong, because they tried to
define mutually exclusive characteristics of traffic orthogonally. It was
possible for traffic to request service that was simultaneously higher
bandwidth, higher reliability, lower latency, *and* cheaper than service
without any flags set. This was obviously nonsensical.
My suggested definition is a straight trade-off of priority for bandwidth.
If you want maximum bandwidth, you're going to have to put up with lower
priority relative to traffic which has effectively requested low latency,
which in turn will find itself throttled to some fraction of the available
bandwidth in return for that priority. It forces whoever is setting the
flags to make a genuine engineering trade-off, and happily it can trivially
be made compatible with the legacy Precedence interpretation of the
Diffserv field.
Codepoint 000000, naturally, corresponds to full bandwidth, minimum
priority traffic, and is the default.
To implement it, we're going to need a throttled priority queue. This
should be straightforward - a set of 64 TBFs with the special properties
that higher priority buckets refill more slowly, and that spending from a
bucket also spends the same amount from all lower-priority buckets. Then at
dequeue, take a packet from the highest priority queue with a positive
bucket and a waiting packet, then refill each bucket with the appropriate
fraction of the dequeued packet size. (Implementation detail: what to do if
no such packet exists; also, what fraction to use for each bucket.)
Naturally, each TBF can and should support a child qdisc such as fq_codel.
- Jonathan Morton
[-- Attachment #2: Type: text/html, Size: 2343 bytes --]
next prev parent reply other threads:[~2014-05-15 22:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ACF89699-67A0-4853-843F-CAC9BDE97CCB@gmail.com>
2014-05-14 21:01 ` [Cerowrt-devel] " Rich Brown
2014-05-14 22:32 ` [Cerowrt-devel] [Bloat] " Kathleen Nichols
2014-05-15 1:25 ` Dave Taht
2014-05-15 13:47 ` dpreed
2014-05-15 16:32 ` Kathleen Nichols
2014-05-15 20:32 ` dpreed
2014-05-15 22:53 ` Jonathan Morton [this message]
2014-05-16 9:38 ` Michael Welzl
2014-05-16 14:52 ` Valdis.Kletnieks
2014-05-16 16:06 ` Jim Gettys
2014-05-16 20:17 ` dpreed
2014-05-15 23:46 ` David Lang
2014-05-16 1:01 ` dpreed
2014-05-16 1:13 ` Dave Taht
2014-05-16 1:15 ` David Lang
2014-05-16 3:16 ` David P. Reed
2014-05-16 3:23 ` David Lang
2014-05-16 12:33 ` David P. Reed
2014-05-16 14:21 ` 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/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJq5cE2BPf+fqeigY==BE-6etqHv-ns2GbxAcxK2o5K3E=AHJQ@mail.gmail.com' \
--to=chromatix99@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=dpreed@reed.com \
--cc=nichols@pollere.com \
/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