On Sat, Apr 4, 2020 at 1:44 AM Sebastian Moeller <moell...@gmx.de> wrote:
> >> > >> Example 1: the ADSL modem connects at 18 Mbit/s, but the ISP further > >> throttles the speed to 15 Mbit/s because that's what the user pays > >> for, and does so with a shaper that has bufferbloat. Then, the "adsl" > >> keyword is likely not appropriate, because the ISP's shaper operates > >> on the IP level. The bandwidth needs to be set slightly below 15 > >> Mbit/s. > > Let's run the number shall we? I simply make a few assumptions here > to get things started, but the exact numbers really do not matter too much. > With that said, let's assume TCP/IPv4 and ATM/AAL5, PPPoE, LLC/SNAP, RFC-2684; > Overhead (bytes): PPP (2), PPPoE (6), Ethernet Header (14), Ethernet PAD [8] > (0), ATM LLC (3), ATM SNAP (5), ATM pad (2), ATM AAL5 SAR (8) : Total 40 > > Let's see what the link will be able to deliver for "full" MTU 1500 packets > (quotes as the MTU1500 will only carry to the PPPoE endpoint, internet MTU is > going to be 1492) > gross-rate * ((payload size) / (on the wire size)) = net speedtest result > (let's use this as proxy as this is what people can easily verify/check) > > MTU1500: 18.000 * ((1500-20-20-8) / (ceil((1500-8+40)/48)*53)) = 15.410 > MTU150: 18.000 * ((150-20-20-8) / (ceil((150-8+40)/48)*53)) = 8.66037735849 > MTU75: 18.000 * ((75-20-20-8) / (ceil((75-8+40)/48)*53)) = 3.05660377358 > > > Now the IP-level shaper at ~80% of the link-speed, if it does not account for > the ATM/AAL5 "celling" even if it gets the overhead correctly will give the > following: > > MTU1500: 15.000 * ((1500-20-20-8) / (ceil((1500-8+40)/1)*1)) = 14.2167101828 > MTU150: 15.000 * ((150-20-20-8) / (ceil((150-8+40)/1)*1)) = 8.40659340659 > MTU75: 15.000 * ((75-20-20-8) / (ceil((75-8+40)/1)*1)) = 3.78504672897 > > So for large enough packets static accounting for ATM/AAL5 works reasonably > well, but for small packets it fails. > That is why most ISP-grade equipment allows not only to configure the > per-packet-overhead for end-user links but also can deal with ATM/AAL5. And > as far as I understand most competent ISPs actually configure their > traffic-shapers for ADSL links to do this, because DSLAMs are really more > like L2-switches with fancy media-converters attached and deal not terribly > well with overload and queueing into the switch fabric. > > That in turn leads to the following situation: > MTU1500: 15.000 * ((1500-20-20-8) / (ceil((1500-8+40)/48)*53)) = 12.842 > MTU150: 15.000 * ((150-20-20-8) / (ceil((150-8+40)/48)*53)) = 7.217 > MTU75: 15.000 * ((75-20-20-8) / (ceil((75-8+40)/48)*53)) = 2.547 > > which will obviously not cause packet buffering in the DSLAM for any packet > size mix the link might encounter. AND that in turn means that the actual > bottleneck link (the ISP's traffic shaper) still behaves like it would employ > ATM/AAL5 encapsulation, and hence the end-user's SQM instance should do as > well. OK, bad (marginal) example, let's adjust it so that the user pays for 10 Mbit/s. Or replace with a 100BASE-TX link shaped (badly) to 50 Mbit/s by the ISP. The point is that sometimes the ISP shaper is what matters, and ISPs like to sell bandwidth in packages with round numbers. And, is the accounting for ATM/AAL5 the default on equipment that ISPs use for ADSL? P.S. The example actually comes from my experience with the "Globe" ISP in the Philippines during my trip there - I had to specifically ask to increase the speed limit, it was initially 10 Mbit/s and then upgraded to 15 Mbit/s. The modem always connected at 18 - 19 Mbit/s, and there was a 21 Mbit/s value once (when I connected the modem to the powerbank during power outage). And I am not sure that we are always talking about competent ISPs. <snip> > P.S.: I am of the opinion, that > https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details had > very sane and un-cargo-culty advice about the overhead topic: > "Getting [overhead and link layer accounting] exactly right is less important > than getting it close, and over-estimating by a few bytes is generally better > at keeping bufferbloat down than underestimating. With this in mind, to get > started, set the Link Layer Adaptation options based on your connection to > the Internet. " > > I am less sure about the paragraph you added recently, as it does not seem to > consider all the applicable subtleties. Should I undo it? -- Alexander E. Patrakov CV: http://pc.cd/PLz7 _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
