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

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

[Dave Taht]

I do keep hoping that one day we'll just be able to plug values into
an equation and come up with the right "thing".

Anyway, this paper had some pretty graphs and some severe flaws - like
only using long flows, not emulating longer RTTs, nor experimenting
with speeds greater than 40mbit. Some of the results, I think, hold,
but I'd have to think about it. 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...

http://sci-hub.bz/10.1109/TNET.2014.2366496

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

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

[Jonathan Morton]

> 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

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

[Dave Taht]

I liked the question they tried to answer, if not their results. :)

As I push a downstream shaper closer to 95% I have been able to get to
where there is sufficient buffering one hop away to where it takes 10s
of seconds or forever for an aqm to drain the result. Your efforts
towards measuring smoothness seemed like a partial start to having
some other trigger to get back minimum queuing, but not quite.

The fact that the 85% number is essentially folklore rather than
science is bothersome. I've spent a lot of time over the last 5 years
researching various models, queue theories, statistical distributions,
and so on, and don't feel like I'm any further better off than I was
when I started. There's always things that look promising (see, for
example "hopf bifurcation" for something I'm trying to understand
currently), other things like alternate statistical distribution
methods, which seem to show a tantalizing hint of working, and they
always peter out...

There are a lot of people that believe in policers, also, and I have
had such bad results with those as to give up. It would be nice to
*prove* that policers didn't work or establish the bounds of their
range, also.

I go back and I read how clearly understood some things could be back
in the 90s, and I envy those people - but I imagine those things were
just as confusing at the time those papers were being written as clear
as they may now seem.

Another paper "sticking with me is:"

https://plus.google.com/u/0/107942175615993706558/posts/gC6oahMETvr

and yet:

This is the best book on bloat I've read yet:
https://plus.google.com/u/0/107942175615993706558/posts/adye5CKrPMF

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

[moeller0]

Hi Dave,


> On Jun 19, 2016, at 02:53 , Dave Taht <dave.taht@gmail.com> wrote:
> 
> I do keep hoping that one day we'll just be able to plug values into
> an equation and come up with the right “thing".

	Well, define “right” and “thing” first ;)

> 
> Anyway, this paper had some pretty graphs and some severe flaws - like
> only using long flows, not emulating longer RTTs, nor experimenting
> with speeds greater than 40mbit. Some of the results, I think, hold,
> but I'd have to think about it. 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…

	Oh, I have a theory about that. As far as I can see when the “folk” recipes evolved a lot of folks were using ADSL links, and the 48/53 encoding of ATM cells eats up 100-100*48/53 = 9.43 % of the available bandwidth right there. Add to this the typical ADSL overheads of say 32 bytes past the 1500 MTU limit you end up incurring another 100-100*1500/1532 = 2.09% of overhead for a total of around 11.4% (well actually it is 100-100*1500/1536 = 2.34 % due to the fact that in AAL5 each packet gets an integer number of ATM cells). So any shaper set to more than 100*1500/(32*53) = 88.44% of link bandwidth should not have been very effective; combined with the observations that a) people prefer round numbers and b) that especially downstream shaping/policing works better with more than the minimum required shaping anyway 15% seems like a reasonable recommendation. 
	I would guess that this probably developed by pure observation without being backed by “math". Now people on other link technologies than ADSL might have sacrificed a bit more bandwidth than absolutely necessary*, but since that would still lead to a working configuration, I assume no one cared deeply enough?

Tl;dr: The 85% has some backing in real link technologies used, that the paper completely glosses over… 
	Now I might be somewhat “obsessed” with trying to understand how per-packet-overhead and encapsulations affect on-the-wire bandwidth for different traffic patterns on different link technologies, but a bit more research in the reality home-users face, might have improved the applicability of the proposed solutions… AND they also do not consider the case typical for bit-torrent situations where a stampeding herd of shortish ingress flows cause sufficient back-pressure to actually flood the real bottleneck links under-managed buffers… The weird thing is they mention that their solution should work for DSL links, while I am certain it can not, given that at the upper end of ADSL links, like 16Mbs for AnnexJ the recommended shaper percentage of 87.5748 %  is really to close to the effectively available link bandwidth of around 88.4% that their solution will not offer much safety margins… and at an adsl bandwidth of 22 Mbps (as far as I know the theoretical maximum for ADSL) the recommended 89.7557% will not work at all. Now the authors could assume that users do link layer accounting first and only apply their shaper rate to the “real” user visible bandwidth, but then 88.4*0.897557 = 79.3440388 is damn close to the 80% recommendation they just tried to debunk…
As so often, I have to admit I am confused…


Best Regards
  M.


*) I just started looking into what happens on DOCSIS links, and all I can say right now is that DSL starts to look logical ;)

> 
> http://sci-hub.bz/10.1109/TNET.2014.2366496
> 
> -- 
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> http://blog.cerowrt.org
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel