Re: [Cerowrt-devel] qos calculator & paper for htb rate selection

[Jonathan Morton <chromatix99@gmail.com>]

> On 19 Jun, 2016, at 03:53, Dave Taht <dave.taht@gmail.com> wrote:
> 
> I was attracted to reading it because
> it attempted to take our "85%" rule for sqm-scripts on downloads and
> attach some science to it...

At no point in that paper did I see any realisation that the initial burst permitted by a token bucket shaper would typically collect in a downstream dumb queue.  I can forgive them not knowing about deficit-mode shapers which have no initial burst, but they do not even try to adjust the burst size of the token bucket shaper.

Perhaps they considered that with the link fully loaded during each test, and with the physical link capacity unrestricted, the size of the burst was unimportant - but this still meant that a quantity of traffic at the beginning of each test was transmitted at line rate, not at the shaped rate.  This is an inherent hazard with using a token bucket shaper as a bandwidth reference.

They also seemed to devote a lot of space and effort to determining the correct queue size for a dump FIFO “behind” the shaper - something which AQM would handle for them.  When they did add AQM, they measured the delays to individual bulk flows rather than the delays to sparse flows competing with the bulk traffic, and thus obtained results showing AQM giving much larger delays to traffic than an “optimally sized” dumb FIFO.

As for the optimal sizing, it was performed on a LAN without any delay lines introduced to simulate realistic Internet RTTs.  They therefore obtained optimal sizes that were very small, and ended up comparing them against AQMs configured for Internet-scale RTTs, while still in the low-latency LAN environment.  This also gave AQM an unfair handicap.

With all these shortcomings, I can’t trust that any of the results they obtained would have any relevance to a realistic Internet application.

 - Jonathan Morton