From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 51D7E21F2F4; Fri, 16 May 2014 02:38:35 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WlEb1-0006Zh-DL; Fri, 16 May 2014 11:38:31 +0200 Received: from nat-eduroam-01.scc.kit.edu ([195.37.186.61] helo=dfnx-cl-180-64.scc.kit.edu) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WlEb0-0005KQ-LH; Fri, 16 May 2014 11:38:31 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_CF6A5750-3410-47F3-8962-4335E6430059" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Welzl In-Reply-To: Message-Id: <8C6AF77D-259D-4FEA-8533-AE2947A4B775@ifi.uio.no> References: <3583FA43-EF5B-42D7-A79C-54C87AA514D5@gmail.com> <5373EEFF.5030407@pollere.com> <1400161663.82913275@apps.rackspace.com> <5374EC39.7040902@pollere.com> <1400185975.95298344@apps.rackspace.com> To: Jonathan Morton X-Mailer: Apple Mail (2.1874) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 13 msgs/h 9 sum rcpts/h 17 sum msgs/h 11 total rcpts 16416 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F7EFA385CD952DD3B663495B00AB834336065F18 X-UiO-SPAM-Test: remote_host: 195.37.186.61 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 8 total 8 max/h 8 blacklist 0 greylist 0 ratelimit 0 X-Mailman-Approved-At: Fri, 25 Jul 2014 11:16:23 -0700 Cc: cerowrt-devel , bloat Subject: Re: [Cerowrt-devel] [Bloat] fq_codel is two years old X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Fri, 16 May 2014 09:38:36 -0000 X-Original-Date: Fri, 16 May 2014 11:38:28 +0200 X-List-Received-Date: Fri, 16 May 2014 09:38:36 -0000 --Apple-Mail=_CF6A5750-3410-47F3-8962-4335E6430059 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 = wrote: > There is, I think, one good way to make Diffserv actually work. It = does require several steps in tandem. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Codepoint 000000, naturally, corresponds to full bandwidth, minimum = priority traffic, and is the default. >=20 > 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. >=20 > - Jonathan Morton > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --Apple-Mail=_CF6A5750-3410-47F3-8962-4335E6430059 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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://t= ools.ietf.org/html/draft-lai-tsvwg-normalizer-02

<= div>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.:


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
= --Apple-Mail=_CF6A5750-3410-47F3-8962-4335E6430059--