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

[moeller0]

Hi Dave,


> On Jun 19, 2016, at 02:53 , Dave Taht <dave.taht at 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel