Hi Jonathan,
> On Jun 2, 2016, at 17:10 , Jonathan Morton <[email protected]> wrote:
>
>
>> On 2 Jun, 2016, at 17:59, moeller0 <[email protected]> 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
>
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
