<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">The key design goal was to create assured bounds on loss and delay for designated classes during extended periods of load saturation. <div class=""><br class=""></div><div class="">The mechanisms, to some extent, are not the issue - the ability configure it and know a-prori (to a given error bound) what would happen to the traffic flows was our primary goal.</div><div class=""><br class=""></div><div class="">The key point we found as we did this work is (as you remark below) that current systems don’t mange the two degrees of freedom that is present in every queueing system, whereas this one does. As anyone who has done any control theory will tell you that is the first essential step to being able control. </div><div class=""><br class=""></div><div class="">We note that what queueing mechanisms do (with respect to application’s performance outcomes) is share the delay and loss (which occurs when the queueing system is non-empty) between the flows that are in competition at the moment in time - this is what this mechanism does. </div><div class=""><br class=""></div><div class="">If you want a larger evaluation, including what needs to be done when transmission capacity changes (as in 3G/4G/5G etc) take a look at <a href="http://www.pnsol.com/public/TP-PNS-CS-2005-11.pdf" class="">http://www.pnsol.com/public/TP-PNS-CS-2005-11.pdf</a> - it is a much richer scenario and provides some strong motivation for why just managing to bandwidth (and speed) is probably not the right goal for many emerging use cases.</div><div class=""><br class=""></div><div class="">Cheers</div><div class=""><br class=""></div><div class="">Neil</div><div class=""><div><blockquote type="cite" class=""><div class="">On 28 Nov 2017, at 16:16, Jonathan Morton <<a href="mailto:chromatix99@gmail.com" class="">chromatix99@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><p dir="ltr" class="">I read the paper just now, and skimmed through the thesis to determine that it was talking about the same thing using an order of magnitude more space.</p><p dir="ltr" class="">It boils down to a Diffserv implementation using a classifier (details handwaved as usual), policers, shapers, and a strict-priority tail-dropping queue. The only noteworthy feature is that the position of the queue's tail depends on the "cherish" metric of each traffic class, which is used to provide differentiation in loss, leaving the strict-priority mechanism to provide "urgency" (delay) differentiation.</p><p dir="ltr" class="">From the above, you might reasonably conclude that I'm not very impressed.</p><p dir="ltr" class="">The paper includes a test scenario versus a plain FIFO and a DRR system. The DRR was weighted with a-priori knowledge of the relative traffic volumes, which in fact would have degraded its performance in delay management. A DRR++ implementation *without* such knowledge would have outperformed it substantially.</p><p dir="ltr" class="">Toke, reproducing that test load and running it through an unmodified Cake instance would perhaps be enlightening.</p><p dir="ltr" class=""> - Jonathan Morton<br class="">
</p>
<span class="BEGIN-ANTISPAM-VOTING-LINKS"></span><div class="BEGIN-ANTISPAM-VOTING-LINKS" style="display: inline">
<!-- BEGIN-ANTISPAM-VOTING-LINKS -->
<div class=""><span style="font-size: inherit; font-style: normal; font-weight: normal; background-color: white; display: inline;" class="">
<hr class="">
<br class="">
<a rel="nofollow" target="canit_note" href="https://portal.roaringpenguin.co.uk/canit/b.php?c=s&i=04UDsgPAO&m=bd67d1bccf1c&rlm=pnsol-com&t=20171128" class="">Spam</a><br class="">
<a rel="nofollow" target="canit_note" href="https://portal.roaringpenguin.co.uk/canit/b.php?c=n&i=04UDsgPAO&m=bd67d1bccf1c&rlm=pnsol-com&t=20171128" class="">Not spam</a><br class="">
<a rel="nofollow" target="canit_note" href="https://portal.roaringpenguin.co.uk/canit/b.php?c=f&i=04UDsgPAO&m=bd67d1bccf1c&rlm=pnsol-com&t=20171128" class="">Forget previous vote</a><br class=""></span></div>
<!-- END-ANTISPAM-VOTING-LINKS -->
</div><span class="END-ANTISPAM-VOTING-LINKS"></span>
_______________________________________________<br class="">Bloat mailing list<br class=""><a href="mailto:Bloat@lists.bufferbloat.net" class="">Bloat@lists.bufferbloat.net</a><br class="">https://lists.bufferbloat.net/listinfo/bloat<br class=""></div></blockquote></div><br class=""></div></body></html>