Hi Dave,
> On Jun 19, 2016, at 02:53 , Dave Taht <dave.t...@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
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
