From: Sebastian Moeller <moeller0@gmx.de>
To: Jonathan Foulkes <jf@jonathanfoulkes.com>,
Mikael Abrahamsson <swmike@swm.pp.se>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] number of home routers with ingress AQM
Date: Tue, 02 Apr 2019 18:38:24 +0200 [thread overview]
Message-ID: <1031976F-2DF9-4736-BAFA-437AD2915E9E@gmx.de> (raw)
In-Reply-To: <DB830B93-B27B-48FF-9FC7-D2ADC5743773@jonathanfoulkes.com>
Hi Jonathan,
Thanks for the data.
On April 2, 2019 4:14:34 PM GMT+02:00, Jonathan Foulkes <jf@jonathanfoulkes.com> wrote:
>Responses below
>
>> On Apr 2, 2019, at 8:10 AM, Mikael Abrahamsson <swmike@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.
>
>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.
Sure, but for the most part I have been limited either by the access link/BNG-shaper or limited peering/transit between my ISP and specific target servers, and in the second case I would hate to slow everything to a crawl just because my ISP and say YouTube try to Duke out who should pay for access, content to eyeballs or vice versa...
>
>>
>>> 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.
Excellent, thanks so most of them....
>As for count, well, that’s private.
I had a hunch, that would be the case ;) . Understandable, though.
>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 ;-)
Oh, nice, I fully agree upstream AQM is a case where the goals and incentives for end-users and ISPs seem well aligned.
>
>>
>> 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 Abrahamsson email: swmike@swm.pp.se
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
next prev parent reply other threads:[~2019-04-02 16:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-02 11:38 Sebastian Moeller
2019-04-02 12:10 ` Mikael Abrahamsson
2019-04-02 12:35 ` Sebastian Moeller
2019-04-02 13:04 ` Mikael Abrahamsson
2019-04-02 13:28 ` Sebastian Moeller
2019-04-02 13:33 ` Ryan Mounce
2019-04-02 14:11 ` Jonathan Foulkes
2019-04-02 21:10 ` Ryan Mounce
2019-04-02 14:14 ` Jonathan Foulkes
2019-04-02 14:58 ` Sebastian Moeller
2019-04-02 13:51 ` Jonathan Foulkes
2019-04-02 14:14 ` Jonathan Foulkes
2019-04-02 16:20 ` Jonathan Morton
2019-04-02 16:38 ` Sebastian Moeller [this message]
2019-04-02 13:15 ` Ryan Mounce
2019-04-02 13:34 ` Mikael Abrahamsson
2019-04-02 13:38 ` Ryan Mounce
2019-04-02 14:02 ` Mikael Abrahamsson
2019-04-02 13:34 ` Sebastian Moeller
2019-04-02 23:23 ` Ryan Mounce
2019-04-03 8:16 ` Sebastian Moeller
2019-04-03 10:09 ` Jonathan Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1031976F-2DF9-4736-BAFA-437AD2915E9E@gmx.de \
--to=moeller0@gmx.de \
--cc=bloat@lists.bufferbloat.net \
--cc=jf@jonathanfoulkes.com \
--cc=swmike@swm.pp.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox