[Bloat] number of home routers with ingress AQM

[Sebastian Moeller]

> On Apr 2, 2019, at 16:14, Jonathan Foulkes <jf at jonathanfoulkes.com> wrote:
> 
> Hi Ryan,
> 
> See below
> 
>> On Apr 2, 2019, at 9:33 AM, Ryan Mounce <ryan at mounce.com.au> wrote:
>> 
>> On Tue, 2 Apr 2019 at 23:35, Mikael Abrahamsson <swmike at swm.pp.se> 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
>> Bloat at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
> 
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat