> On Apr 2, 2019, at 16:14, Jonathan Foulkes <[email protected]> wrote:
>
> Hi Ryan,
>
> See below
>
>> On Apr 2, 2019, at 9:33 AM, Ryan Mounce <[email protected]> wrote:
>>
>> On Tue, 2 Apr 2019 at 23:35, Mikael Abrahamsson <[email protected]> wrote:
>>>
>>> I've read rumours about some ISPs implementing interaction with the VDSL
>>> DSLAM where there is an estimation of the current link-speed for each
>>> individual customer and then it tries to set the BNG egress shaper
>>> appropriately.
>>
>> NBN here in Australia do this for their wholesale FTTN/B VDSL2
>> product, injecting the downstream and upstream sync speed into
>> PPPoE/DHCP requests. This still depends on the retail service
>> providers to make use of these attributes from their BNG to configure
>> the shaper.
>
> Very interesting, and extremely useful that they surface the sync rate in the
> PPPoE/DHCP exchanges. How are those externalized in something like OpenWRT at
> this time?
>
> FYI- The IQrouter supports the notion of a tightly coupled modem from which
> current sync rates (as well as other SNR / Atten stats) can be dynamically
> queried, which in turn are used in the AQM settings computations. Works
> wonders on flaky DSL lines that vary sync rate with time of day and weather.
> If that VDSL2 sync rate relayed is exposed in the system somehow, it would
> make dynamic adjustments possible.
IMHO the ISP should be mandated make machine readable dynamically
updated information about a links limits available. Grossrate, unavoidable
overhead and potentially additional encodings like (ATM's 48/53, or PTM's
64/65). With BNG-shapers/policers the synch-rate alone does not help except for
allowing an estimate of the upper bound.
Best Regards
Sebastian
>
>
>>
>>>
>>> I am very happy about my FTTH solution I have now since from what I can
>>> see the L2 network is almost never a limiting factor (much better than my
>>> DOCSIS connection) so my bidirectional SQM with CAKE seems to work very
>>> well.
>>>
>>> Still, the HGW can never solve these problems properly, the egress shaping
>>> in the BNG needs to do a proper job. From what I have been told, there has
>>> been improvements here in the past few years.
>>>
>>> What I am more worried about is the egress shaping from the HGW. I talked
>>> to several vendors at BBF and they talked about ingress policing being
>>> commonly used on the BNG. This means no ingress shaping at all (just
>>> packet drops if they exceed the configured rate). I don't know about
>>> buffering on the HGW though and how the policed rate is set compared to
>>> the L2 rate the HGW can send via.
>>
>> NBN is an example again. Their documented behaviour is to police
>> traffic in both directions. Most ISPs then shape in the downstream -
>> and it's up to a tightly managed (TR-069 ?) ISP HGW or a diligent end
>> user to shape traffic in the upstream. Many - probably even most users
>> have no shaping whatsoever in the upstream, only a policer.
>>
>> And then there is their new FTTdp product, where it is not currently
>> possible to determine the real VDSL2 sync speed. If there's a drop of
>> rain it will resync at a lower speed in the upstream, and then
>> everything ends up queuing inside the supplied modem…
>
> Oh, so they regressed from their other offering, not exposing sync rates?
>
> BTW- this hole notion of the BGM relaying the provisioned or current sync
> rates should be a mandated requirement, as it has huge benefits for AQMs. Not
> that it can be relied on 100%, but at least it makes a good starting point.
>
>
>> _______________________________________________
>> Bloat mailing list
>> [email protected]
>> https://lists.bufferbloat.net/listinfo/bloat
>
> _______________________________________________
> Bloat mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
