> On 19 Jun, 2016, at 03:53, Dave Taht <dave.t...@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

_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Reply via email to