[Bloat] number of home routers with ingress AQM

[Sebastian Moeller]

HI Mikael,


> On Apr 2, 2019, at 14:10, Mikael Abrahamsson <swmike at swm.pp.se> 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.

	Me too, but still I want to see numbers, plus those are likely those end-users that could be won-over by L4S as theses obvipusly would be receptive for the "low-latency" for all pitch of the L4S project. 

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

	As a first approximation knowing your speed just requires to run a single (decent) speedtest, as the reported TCP/IPv[4|6]/HTTP[s]-Goodput numbers can be feed directly into any shaper (shapers typically desire gross rates, but since net < gross net rates will just do fine if the aim is to keep latency under control). Deutsche Telekom actually sends crude estimates of the achievable goodput via PPPoE-ACK messages that AVM's FritzBox routers (quite popular in Germany for those unhappy with the ISP supplied gear) evaluate to configure up- and downstream shaping. Which due to lack of proper documentation of the PPPoE-ACK message is a bit of a hit and miss job.

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

	Sure, that is not a solution for congestion outside of the access link, but that is an impossible problem to solve. But getting the access link debloated often is an important first step even if it does not fix the whole internet ;)

> When I used my DOCSIS connection it routinely forwarded packets at lower rates than what I bought (and had configured the ingress shaper for).

	Gotta love oversubscribed segments ;) Gargoyle firmware has an adaptive method that tries to tackl;e that poroblem, and eventouter, IIUC, actually runs multiple bandwidth measures per day to track the actually achievable bandwidth. But these are just work-arounds. Now if your cable ISP acctually had used a competent QoS system you might not have had to suffer bad latency with bad bandwidth. But I believe cablelabs has identified that as a problem and is actively working on it (and sooner or later their flow-queueing in disguise will do the right thing ;) ). Flow-queueing in disguise, I hear nobody ask, well sure they mandate a DualPI2 solution but also mandate in Annex P Queue Protection Algorithm (Normative) of CM-SP-MULPIv3.1-I17-190121 something that must come close to flow queuueing in cost, to cite from the source "The algorithm maintains per-Microflow state that holds a “queuing score” representing how much each Microflow was responsible for recent queuing." I asked about the cost but have not heard an answer yet.

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

	Yes, I know, and there are good reasons for doing it that way.

> Generally there is no ingress shaping of any kind on the HGW,

	That is part of my question....

> it doesn't even know what speed the subscription is.

	See above how Deutsche Telekom deals with that issue, at least in the German market.

Thanks for your insights, much appreciated

Best Regards
	Sebastian



> 
> -- 
> Mikael Abrahamsson    email: swmike at swm.pp.se