From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id EAE863BA8E for ; Wed, 20 Jun 2018 13:27:58 -0400 (EDT) Received: from [172.16.11.169] ([134.76.241.253]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M2cDB-1gNn3J3jbp-00sLsZ; Wed, 20 Jun 2018 19:27:56 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Sebastian Moeller In-Reply-To: <67ee54f6-444e-1568-3419-23c434792157@gmail.com> Date: Wed, 20 Jun 2018 19:27:55 +0200 Cc: bloat Content-Transfer-Encoding: quoted-printable Message-Id: References: <1529339194.276412941@apps.rackspace.com> <1529361825.80979395@apps.rackspace.com> <145517.1529440447@turing-police.cc.vt.edu> <67ee54f6-444e-1568-3419-23c434792157@gmail.com> To: Jan Ceuleers X-Mailer: Apple Mail (2.3445.8.2) X-Provags-ID: V03:K1:IefuV0Nl1CLKljXuDaYTzw8m1KupPXSRR475R6Ev0KNzFyo6JHs eTRhTDtijFJaRlluwqUwkQdRtJFe5ltBPS3k7vp6sarE51OJGKGJELdO0Q/HBsfysU2UAVg LWzb4eZbT/bmfeELPtJHcDo60Ka8OT9h3Em/tt1qPV4RcbL3Fvt6dYyL4qyNMWWw8bZkCST fRjhRDYsbEcgS2KCtygfw== X-UI-Out-Filterresults: notjunk:1;V01:K0:vJqW4U9BjyQ=:vdTCsIcD9eM05hPrZ787dA euN/MUMjyO/MGN130UZjtaTC4TI6BtTfzazK302wS93VsnTUOJNU5O0ck2vraILtp469jRv8e hhkfzFllMl6mEcexQa8iizw5rX3xIQPGLbr8Y7bqPBooxYwlldCA8SIIhHe5yivXw6AqcdeST UOaxyg8kw/5lupbZaqTpwvPN7e34MU6eTQU6kkUMjvcmdVkmsJZ3ZrvZDmtzSrLamvdXbRb7x tmUeeXAJGKG2o/8kIO1T48iK+OZ3ly28mILzqoAcQvtlFKm57D4XcGR93247djNxo14clehzG YivghYwrSquz/GlQXUOhpQ13Gts7yE7caf74F21bELaxFjwZOfj9RnCbMAAxQD37CpyUEhi3x TxCtFkV3/mrOz1Wc7K6jK5A94ChI1r4KMzWw3nsFpKwwGddWPQgfjNoSsvp3KUzSSbHJYbthz A7qcx7vFcE7WfwNNLDJB8s1KSQZMsj9ZomgXBda+PRytRxy40m+DMvLPio+fyUq2V4znbfh7s tBS+FJgcZlrmjSbqjSqBtJleS3ht98yWtwXoeMjrEkK9csGuneG0arX+LcQ+EVD5FRQUO1RZE CMtpqJY+w1Dh44ZomR9FGT7GFMF694vB+ioQ2TemMcgYQArJrS/TwnGnDz5s/HUbBYHNelv5O OlYPLyHMOnabYWsMCnBuaMuy5xQXn+nWfR4sT9XutlcNbyLoQNXpor9vrm0GRThgHAJYEEul9 gDnh9vuwyoJWsIiLCrNzSA8fZE+JVsFgx/bNoE2w5wiCZYaozemp8bdp5h7CS8KjNeyPhpaDc 9l8MKeO Subject: Re: [Bloat] [Cerowrt-devel] Invisibility of bufferbloat and its remedies 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: Wed, 20 Jun 2018 17:27:59 -0000 Hi Jan, > On Jun 20, 2018, at 17:57, Jan Ceuleers = wrote: >=20 > On 20/06/18 01:41, Jonathan Morton wrote: >>> On 19 Jun, 2018, at 11:34 pm, valdis.kletnieks@vt.edu wrote: >>>=20 >>> Do we have a good cookbook on how to determine the set-rate? >>=20 >> On DSL, the sync rates in each direction should usually be readable = from the modem; they are typically reported on the router's status page. = The advertised rate is less reliable, to say the least. >=20 > I'm afraid that my DSL modem doesn't belong to the "usually" case. I > have a BBox3 from Proximus (Belgium). Proximus buys these from two > manufacturers: Technicolor and Sagemcom. I have the Sagemcom variant. I believe the ITU standards actually mandate modems to supply a = specific set of parameters upon query, maybe an snmp query on the modem' = sLAN side might reveal something? (I fear that all the standards mandate = is that the CPE tells the dslam and that communication might be shielded = from endusers; I still hope that european regulators will at one point = require ISPs to reveal all standard mandated values, but I am not = holding my breath...) >=20 > Proximus went out of their way to avoid that end users be able to = query > the modem for its connection parameters. There is still an indirect = way > to do so in the Sagemcom variant (and so I know that my modem provides > 50Mbit/s down and 10Mbit/s up) but for marketing reasons Proxinus = would > prefer its users not to know. The reason is that their principal > competitor, cable operator Telenet (owned by Liberty Global) would win > the game based on raw link speed. But they probably also win on user-measurable goodput and most = likely have done so for at least a decade and still customers did not = abandon DSL, so this logic, while probably true from the ISPs POV, is = also flawed. >=20 > So whereas I have access to the information I need to be able to > configure my queues there are others who do not, and it would be good > for a generic method to exist that derives the correct parameters from > measurements. Sure, I agree, as measuring will also take care of any potential = shapers the ISP might employ upstream of the dslam. But it raises the = question how this measurement can be done without requiring dedicated = reference points somewhere in the network, which in turn means the = actual measurement should only generate minimal traffic itself. >=20 > Kathy put it more succinctly: there is a good case for monitoring. Well that is exactly what Kevin proposed, his approach will = query the modem about the sync rates whenever his device hotplugs (and = on his line any change of sync rate is accompanied by a re-sync as his = ISP does not user seamless rate adaptation/SRA I believe, so the hotplug = approach will reget the actual sync values whenever a change might have = occurred). Nice solution, but way to specialized to help a noticeable = number of people, let alone making a dent into the problem. > Question is what to monitor and how to set/modify the qdisc = parameters. The what seems easy, bandwidth and latency ;) the how escapes = me... Best Regards Sebastian >=20 > Jan > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat