Re: [Cake] cake/tc - removal of atm/ptm/ethernet specific overhead keywords

[moeller0 <moeller0@gmx.de>]

Hi Jonathan,

> On Jun 2, 2016, at 17:10 , Jonathan Morton <chromatix99@gmail.com> wrote:
> 
> 
>> On 2 Jun, 2016, at 17:59, moeller0 <moeller0@gmx.de> wrote:
>> 
>> As I tried to convey before the matter is far from simple. For example my ISP, DTAG, has at least 4 different sets of per packet overhead (ATM versus PTM, BRAS versus BNG) so even for this one ISP there is not one solution to the issue. And with BRAS/BNG shaping as used by say DTAG the actual VDLS2 related overhead becomes irrelevant compared to the overhead setting of that applied policer. I believe trying to simplify this complexity will lead to false overhead recommendations. I would rather direct people to better documentation how to deduce the overhead by measurements and research…
> 
> I think we can make a couple of usefully simplifying assumptions:
> 
> 1: The encapsulation overhead on the wire is the same in both directions.

	That seems reasonable.

> 
> 2: The BRAS is irrelevant, because we need to set an ingress qdisc below the line rate anyway in order to exert control, and the BRAS doesn’t apply on upload.

	Not at all, either the BRAS shaper is set above the XDSL link capacity (in which case it does not matter) or it is set below link capacity and then ONLY the BRAS shaper matters. As an example DTAG changed their DSLAMs/MSANs to alway sync as high as possible, so my Modem syncs at 109/38Mbps, but I have 50/10Mbps plan, all the shaping is happening at the BNG/BRAS, the parameters of the VDSL2 links do not matter at all anymore. It seems that the BNG shaper effectively limits the brutto rate and then they use dual-VLAN tags and the pppoe overhead, so that the shapers overhead in practice is equal to the PTM link’s. But even if the would not account for any overhead the difference between 50 and 100 is large enough to make the real VDSL2 overhead irrelevant. At least for DTAG’s BNG rollout the shaping/policing happens in the BNG both for upstream and downstream.
	I believe this illustrates why we should not try to sugarcoat this complexity. Instead of telling the user our best guess of his/her specific overhead, we would do them a greater service by explaining how to actually measure their overhead…

Best Regards
	Sebastian


> 
> Does that help at all?
> 
> - Jonathan Morton
>