[Bloat] number of home routers with ingress AQM

[Ryan Mounce]

On Wed, 3 Apr 2019 at 00:41, Jonathan Foulkes <jfoulkes at evenroute.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?

These attributes are tacked onto the requests towards the ISP - so
unfortunately they're not of any use to configure a shaper on the home
gateway side.

> 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.

Yeah, I did something similar for a family member stuck on ADSL.
Scraped the sync speed from the cheap bridged TP-Link modem and used
it to configure cake - with periodic updates in case of a resync.

> > 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?

Yep. The wholesaler provides the modem (also integrating a reverse
power supply to the mini DSLAM / "DPU") so the customer demarcation
point is a gigabit ethernet port - abstracting the xDSL side of things
from the customer's equipment. Apparently they're working on making
real time sync speeds available ISPs that want to query them as part
of service diagnostics, and haven't even got that contrived solution
working yet. And then you still need to get that info from your ISP,
fortunately mine has just added the unique ability to trigger your own
service diagnostics and retrieve the results so it may be possible to
scrape it this way. Quite the kludge at that point.

Fortunately the mini DSLAM is typically less than 50m from your
property boundary and spliced directly into the lead-in cable, so it
is normally capable of syncing above the maximum 100/40 rate that's
offered and thus limited by the consistent policer rather than the
variable line rate. Unless it rains - then all bets are off. Isn't
copper great?

>
> 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.