From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp104.ord1d.emailsrvr.com (smtp104.ord1d.emailsrvr.com [184.106.54.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 327753CB35 for ; Tue, 2 Apr 2019 10:11:49 -0400 (EDT) Received: from smtp6.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp6.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id BA5EFE0341; Tue, 2 Apr 2019 10:11:48 -0400 (EDT) X-Auth-ID: jfoulkes@evenroute.com Received: by smtp6.relay.ord1d.emailsrvr.com (Authenticated sender: jfoulkes-AT-evenroute.com) with ESMTPSA id 73681E01E2; Tue, 2 Apr 2019 10:11:48 -0400 (EDT) X-Sender-Id: jfoulkes@evenroute.com Received: from jonathans-mbp.lan (h26.135.213.151.dynamic.ip.windstream.net [151.213.135.26]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Tue, 02 Apr 2019 10:11:48 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jonathan Foulkes In-Reply-To: Date: Tue, 2 Apr 2019 10:11:47 -0400 Cc: Mikael Abrahamsson , bloat Content-Transfer-Encoding: quoted-printable Message-Id: References: <47CA8CDA-3060-40C2-AC0A-04899F08C9DE@gmx.de> To: Ryan Mounce X-Mailer: Apple Mail (2.3445.102.3) X-Mailman-Approved-At: Mon, 08 Apr 2019 19:57:16 -0400 Subject: Re: [Bloat] number of home routers with ingress AQM X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 14:11:49 -0000 Hi Ryan, See below > On Apr 2, 2019, at 9:33 AM, Ryan Mounce wrote: >=20 > On Tue, 2 Apr 2019 at 23:35, Mikael Abrahamsson = wrote: >>=20 >> 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. >=20 > 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. >=20 >>=20 >> 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. >>=20 >> Still, the HGW can never solve these problems properly, the egress = shaping >> in the BNG needs to do a proper job. =46rom what I have been told, = there has >> been improvements here in the past few years. >>=20 >> 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. >=20 > 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. >=20 > 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=E2=80=A6 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