Re: [Bloat] number of home routers with ingress AQM
Responses below > On Apr 2, 2019, at 8:10 AM, Mikael Abrahamsson wrote: > > On Tue, 2 Apr 2019, Sebastian Moeller wrote: > >> I just wondered if anybody has any reasonable estimate how many end-users >> actually employ fair-queueing AQMs with active ECN-marking for ingress >> traffic @home? I am trying to understand whether L4S approach to simply >> declare these as insignificant in number is justifiable? > > If more than 0.01% of HGWs did this I'd be extremely surprised. My observation is that the number is very small, even devices with SQM services, rarely see them enabled, and when they are, are set to sub-optimal values. I see Sebastian doing a valiant, even heroic effort at addressing technical users questions on forums, but even those users seem confused at times. > >> I know in openwrt with sqm that is the default, but I have no idea about > > To configure ingress shaping you actually have to know the speed and > configure it. It's not the default. Also, it's useless if the transport > network queues the packets at lower rate than at what you receive it. When I > used my DOCSIS connection it routinely forwarded packets at lower rates than > what I bought (and had configured the ingress shaper for). As noted in other responses, the actual throughput needs to be measured and then monitored to ensure the ingress shaping is aligned with current capacity of the link. And not just the HGW to BNG, but just as importantly, account for any constraints in backhaul from the BNG. > >> the number of devices that actually use sqm in the field; @Jonathan: does >> evenroute have numbers you are willing to share, like total numbers or % of >> iqrouters with ecn-marking ingress routing active? @Sebastian, 100% of IQrouters running firmware 3.x (which uses Cake as the default AQM) respect/use ECN. This has been shipping since September, 2018. All existing v2 IQrouters (first ship January 2017) may upgrade to 3x (user initiated, but one-click). As for split, 70% of deployed IQrouters are doing ECN today. As for count, well, that’s private. But the good new is we have ISP customers rolling them out at a good clip. Turns out that having a sane traffic manager at the HGW on every node of a DSLAM is very good for the DSLAM, the backhaul and the actual users, who quit screaming at the ISP ;-) > > ISP networks typically looks like this in the ISP->HGW direction: > > BNG->L2->L2->HGW > > This is the same regardless if it's DSL, DOCSIS, FTTH/PON or whatever. So > shaping is done egress on BNG and it tries to send at lower rate than any of > the L2 devices. Generally there is no ingress shaping of any kind on the HGW, > it doesn't even know what speed the subscription is. > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se > ___ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] number of home routers with ingress AQM
Hi Ryan, See below > On Apr 2, 2019, at 9:33 AM, Ryan Mounce wrote: > > On Tue, 2 Apr 2019 at 23:35, Mikael Abrahamsson 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. > >> >> 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@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
