From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 76CA621F33D; Thu, 15 May 2014 15:53:51 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id db11so2172588veb.15 for ; Thu, 15 May 2014 15:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/oBZWwADd4Hp+e8V34mq3Vc/C/jJr1d4BbXzyXA8vaI=; b=ty38+V+y5fOtBwAtDTmLZEWRBZ7Cv3MGwQABzaasI9H2ufg8haciG5dgQbegMJiqsa sWSEYqx3RpYImskX5SGdOlBHGSIDrwsLtL6GAcwH6FFDdt5ciK68r/0Hlb8LWXblqTFx /LaGblyEnKjKo5HsdRAlyjAt8AQls6Oly3nyHCp3wmHC4FJQuBMp/zhwdX8huR5Yv20P kOoI5IiBcCs34a+l439mZl5HtpNXBvhf9W0aEST/FVOS3l2vYlPg6Zp0D40VRKD4n/Gj 4sBSkeN7HGjRKvAkDVJoVXUA3f18kW9qJhltybNBFZPqsG146qp5qtW/5mDmRHM7b9NB F7BA== MIME-Version: 1.0 X-Received: by 10.58.179.115 with SMTP id df19mr270767vec.41.1400194430391; Thu, 15 May 2014 15:53:50 -0700 (PDT) Received: by 10.52.14.99 with HTTP; Thu, 15 May 2014 15:53:50 -0700 (PDT) Received: by 10.52.14.99 with HTTP; Thu, 15 May 2014 15:53:50 -0700 (PDT) In-Reply-To: <1400185975.95298344@apps.rackspace.com> 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> Date: Fri, 16 May 2014 01:53:50 +0300 Message-ID: From: Jonathan Morton To: dpreed@reed.com Content-Type: multipart/alternative; boundary=047d7b6730aca3da0c04f9782bb2 Cc: Kathleen Nichols , 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: , X-List-Received-Date: Thu, 15 May 2014 22:53:52 -0000 --047d7b6730aca3da0c04f9782bb2 Content-Type: text/plain; charset=UTF-8 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 --047d7b6730aca3da0c04f9782bb2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

There is, I think, one good way to make Diffserv actually wo= rk. It does require several steps in tandem.

Step one is to accept and admit that differential pricing ba= sed on scarcity economics does not work on the internet. That's going t= o be tough to swallow for the big commercial players.

Step two is to define service levels in such a way that aski= ng for a bonus in one category inherently requires taking a deficit in some= other category. This permits trusting the Diffserv field, wherever it happ= ens to come from.

That part is where the old TOS flags went wrong, because the= y tried to define mutually exclusive characteristics of traffic orthogonall= y. It was possible for traffic to request service that was simultaneously h= igher bandwidth, higher reliability, lower latency, *and* cheaper than serv= ice 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 p= ut up with lower priority relative to traffic which has effectively request= ed low latency, which in turn will find itself throttled to some fraction o= f 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 priorit= y queue. This should be straightforward - a set of 64 TBFs with the special= properties that higher priority buckets refill more slowly, and that spend= ing from a bucket also spends the same amount from all lower-priority bucke= ts. Then at dequeue, take a packet from the highest priority queue with a p= ositive bucket and a waiting packet, then refill each bucket with the appro= priate fraction of the dequeued packet size. (Implementation detail: what t= o 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

--047d7b6730aca3da0c04f9782bb2--