<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi,<div><br></div><div>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.</div><div><br></div><div>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: <a href="http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-02">http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-02</a></div><div><br></div><div>Cheers,</div><div>Michael</div><div><br></div><div><br></div><div><br></div><div>(*) - the oldest example I know of is the Alternative Best Effort Service <a href="http://infoscience.epfl.ch/record/223">http://infoscience.epfl.ch/record/223</a> , slightly newer we have e.g.:</div><div><a href="http://people.networks.imdea.org/~sergey_gorinsky/pdf/RD_Services_SIGCOMM_2008.pdf">http://people.networks.imdea.org/~sergey_gorinsky/pdf/RD_Services_SIGCOMM_2008.pdf</a></div><div><br></div><div><br></div><div><br><div><div>On 16. mai 2014, at 00:53, Jonathan Morton <<a href="mailto:chromatix99@gmail.com">chromatix99@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><p dir="ltr">There is, I think, one good way to make Diffserv actually work. It does require several steps in tandem.</p><p dir="ltr">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.</p><p dir="ltr">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.</p><p dir="ltr">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.</p><p dir="ltr">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.</p><p dir="ltr">Codepoint 000000, naturally, corresponds to full bandwidth, minimum priority traffic, and is the default.</p><p dir="ltr">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.</p><p dir="ltr"> - Jonathan Morton<br>
</p>
_______________________________________________<br>Bloat mailing list<br><a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>https://lists.bufferbloat.net/listinfo/bloat<br></blockquote></div><br></div></body></html>