From: Michael Welzl <michawe@ifi.uio.no>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: 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 09:38:36 -0000 [thread overview]
Message-ID: <8C6AF77D-259D-4FEA-8533-AE2947A4B775@ifi.uio.no> (raw)
In-Reply-To: <CAJq5cE2BPf+fqeigY==BE-6etqHv-ns2GbxAcxK2o5K3E=AHJQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3166 bytes --]
Hi,
I completely agree that this service differentiation was wrong from the beginning. The idea of using bits to implement a trade-off that doesn't involve prioritization between users is old (*), and has always been the right approach in my opinion.
At least one proposal in this direction is currently being made in the IETF, and I definitely think that this is the right way to go: http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-02
Cheers,
Michael
(*) - the oldest example I know of is the Alternative Best Effort Service http://infoscience.epfl.ch/record/223 , slightly newer we have e.g.:
http://people.networks.imdea.org/~sergey_gorinsky/pdf/RD_Services_SIGCOMM_2008.pdf
On 16. mai 2014, at 00:53, Jonathan Morton <chromatix99@gmail.com> wrote:
> 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
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
[-- Attachment #2: Type: text/html, Size: 4042 bytes --]
next prev parent reply other threads:[~2014-05-16 9:38 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
2014-05-16 9:38 ` Michael Welzl [this message]
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=8C6AF77D-259D-4FEA-8533-AE2947A4B775@ifi.uio.no \
--to=michawe@ifi.uio.no \
--cc=bloat@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=chromatix99@gmail.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