Re: [Bloat] [Cerowrt-devel] Invisibility of bufferbloat and its remedies

[Sebastian Moeller <moeller0@gmx.de>]

Hi Jan,


> On Jun 20, 2018, at 17:57, Jan Ceuleers <jan.ceuleers@gmail.com> wrote:
> 
> On 20/06/18 01:41, Jonathan Morton wrote:
>>> On 19 Jun, 2018, at 11:34 pm, valdis.kletnieks@vt.edu wrote:
>>> 
>>> Do we have a good cookbook on how to determine the set-rate?
>> 
>> 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.
> 
> 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...)


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


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

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

> 
> Jan
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat