[Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Fred Stratton]

VDSL2 uses PTM. In the UK, the regulator has mandated that VDSL2 must be 
run over fibre, normally to an MSAN within 200-300 metres of the user.

So what is the fibre in your cable and fibre category?

Is it FTTC/FTTH as I describe, or fibre using some other transmission 
protocol?


On 18/12/13 10:33, Sebastian Moeller wrote:
> Hi David,
>
> On Dec 18, 2013, at 05:34 , David Lang <david at lang.hm> wrote:
>
>> On Tue, 17 Dec 2013, Rich Brown wrote:
>>
>>> - From what you’ve said, I don’t have much hope for doing it automagically. But maybe we can provide clues to help the customer do to the right thing. Perhaps the first dropdown could be “Link Layer Adjustments (used on DSL or ATM)” with options for “None/ADSL/SDSL/VDSL over PTM/VDSL over ATM/PPPoATM” and maybe others. CeroWrt could automatically set the proper link layer adaptations for each. We could also include a link to the wiki for a flow chart for setting each of these cases, especially the questions they should ask their ISP.
>> Let's start with the first question, what is the difference between these as far as what the config should be?
> 	1) ATM based carriers (ADSL1, ADSL2, ADSL2+, potentially VDSL1): link layer has to be set to ADSL
> 	2) PTM based carriers (VDSL2): link layer has to be set to ethernet
> 	3) cable, GPON (fiber): link layer has to be set to ethernet
>
> 	1) and 2) typically have additional overhead to account for, 3) may or may not
>
> 	Only 3) with no overhead is fine with no link layer adaptation mechanism.
>
>> forget the GUI or automated settings. If I am configuring a Cerowrt box mmanually, what should I set differently for the different types of configs?
> 	Current GUI settings (might change)
> A) ATM based transports:
> 	1) Which link layer adaptation mechanism: tc_stab
> 	2) link layer: ADSL
> 	3) overhead: see http://ace-host.stuart.id.au/russell/files/tc/tc-atm/  (section: Overhead and MTU Calculations)
> B) PTM based transports:
> 	1) Which link layer adaptation mechanism: tc_stab
> 	2) link layer: ethernet
> 	3) overhead: unclear but see:http://www.dslreports.com/forum/r27565251-Internet-Per-packet-overhead-on-Bell-s-VDSL-ATM-based-
>
> C)  cable, GPON (fiber):
> 	1) Which link layer adaptation mechanism: none, assuming no per packet overhead
> otherwise
> 	1) Which link layer adaptation mechanism: tc_stab
> 	2) link layer: ethernet
> 	3) overhead: unclear but see:http://www.dslreports.com/forum/r27565251-Internet-Per-packet-overhead-on-Bell-s-VDSL-ATM-based-
>
> There should be no need to fiddle with the advanced link layer options, unless you link MTU is >> 1500. Note for link layer ethernet no size table is constructed unless MPU > 0.
>
>
>> What is the impact of getting it wrong? (if it's like VPN overhead where setting the rate just slightly too high results is lots of wasted 'airtime' by setting it too low results is a amall amount of wasted 'airtime' then a low enough value to be reasonalbe everywere is a good default)
> 	User on an ATM based link without link layer adaptation: The shaper will underestimate the relevant wire seize of each packet and hence will not shape enough to avoid filling the potentially bloated buffers of the DSL modem. This effect gets worse the more the packet length distribution is skewed towards small packet (the estimate can be off by around 50% worst case, so this is not good.) But note this basically is the "status quo" for most users (as far as I know no router/modem sets these options correctly, but I do not claim to know all such systems). ALSO this in theory is testable, on such a system buffer bloat/latency increase should be more severe if one tries to fill the nominal transmit rates with small than with large packets. Misjudging the overhead either wastes bandwidth or also if too large or increases the likelihood to see buffer bloat by overestimating the effective link capacity.
>
> 	Users on a  PTM based link, when running with link layer ADSL, will waste 10% of the bandwidth right there (for taking the 48 in 53 encapsulation into consideration). Plus they will overestimate the effective size of small packets and will waste up to 50% of the remaining bandwidth there. Overhead misjudging has the same effect as on ATM (except overheads on PTM typically should be smaller I guess so this effect might not be too relevant).
>
> 	To summarize, using the wrong link layer adaptation will hurt the user, ATM users will suffer buffer bloat, but will use all available bandwidth (well more actually since that creates the bloat), PTM users will suffer severe packet-size-dependent bandwidth decreases. The "status quo" is more or less fine for groups 2) and 3), not so good for 1). I think most people in 1) caring enough reduced the shaped rates by a larger amount than people in groups 2) and 3) and just accepted that depending on the packet size mix latencies got more variable.
>
> 	Getting it wrong is not advisable… Getting it right requires some non-obvious information from one's ISP. While VDSL will become more prominent in the future, ADSL variants will not disappear for a long time, as VDSL only works (well)
> on short loops, so people far away from the DSLAM will stay on ATM (or one day a new ADSL might learn to use PTM, but I will not hold my breath)
>
> Best Regards
> 	Sebastian
>
>> David Lang_______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel