[Bloat] Bufferbloat in high resolution + non-stationarity

[Neil Davies]

The key design goal was to create assured bounds on loss and delay for designated classes during extended periods of load saturation.

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.

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.

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.

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 http://www.pnsol.com/public/TP-PNS-CS-2005-11.pdf <http://www.pnsol.com/public/TP-PNS-CS-2005-11.pdf> - 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.

Cheers

Neil
> On 28 Nov 2017, at 16:16, Jonathan Morton <chromatix99 at gmail.com> wrote:
> 
> 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.
> 
> 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.
> 
> From the above, you might reasonably conclude that I'm not very impressed.
> 
> 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.
> 
> Toke, reproducing that test load and running it through an unmodified Cake instance would perhaps be enlightening.
> 
> - Jonathan Morton
> 
> Spam <https://portal.roaringpenguin.co.uk/canit/b.php?c=s&i=04UDsgPAO&m=bd67d1bccf1c&rlm=pnsol-com&t=20171128>
> Not spam <https://portal.roaringpenguin.co.uk/canit/b.php?c=n&i=04UDsgPAO&m=bd67d1bccf1c&rlm=pnsol-com&t=20171128>
> Forget previous vote <https://portal.roaringpenguin.co.uk/canit/b.php?c=f&i=04UDsgPAO&m=bd67d1bccf1c&rlm=pnsol-com&t=20171128>
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20171130/0b2c1a43/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20171130/0b2c1a43/attachment.sig>