[Cerowrt-devel] Ideas on how to simplify and popularize bufferbloat control for consideration.

[Sebastian Moeller]

Hi R, hi List,

On May 24, 2014, at 16:12 , "R." <redag2 at gmail.com> wrote:

>>> I should point out that another issue with deploying fq_codel widely is that it requires an accurate measurement (currently) of the providers bandwidth.
> 
> Pardon my noobiness, but is there a technical obstacle that prevents
> the creation of a user-triggered function on the router side that
> measures the provider's bandwidth?
> 
> Function, when (luci-gui?) triggered, would:
> 
> 1. Ensure that internet connectivity is present.
> 2. Disconnect all clients.
> 3. Engage in DL and UL on a dedicated web server, measure stats and
> straight up use them in fq_codel -- or suggest them in appropriate
> QoS-gui user-boxes.
> 
> Further, this function could be auto-scheduled or made enabled on
> router boot up.
> 
> I must be missing something important which prevents this. What is it?

	Well, I see a couple of challenges that need to be overcome before this could work. 

In your step 3 you touch the issue of measuring the current stats; and somehow what is trickier than one would think:

1) what to measure precisely, a "dedicated web server" sounds like a great idea, but who is dedicating it and where is it located relative to the link under test?
	Rich Brown has made a nice script to measure current throughput and give an estimate on the effect of link saturation on latency (see betterspeedtest.sh from https://github.com/richb-hanover/CeroWrtScripts), but using this from Germany gives:
2014-05-24 15:44:47 Testing against demo.tohojo.dk with 5 simultaneous sessions while pinging gstatic.com (60 seconds in each direction)
	Download:  12.06 Mbps
	Upload:  1.99 Mbps
against a server in Europe, but:
 	Download:  10.42 Mbps
 	Upload:  1.85 Mbps
against a server on the east side of the USA. So the router would need to select a close-by server. Sites as speedtest.net offer this kind of server selection by proximity but do not have a very reliable way to load the link and do not measure the effect of link saturation on the latency… but the whole idea is to find the highest bandwidth that foes not cause indecent increase of latency under load. (Also speed tests are quite stereotypic in observable behavior and length so some ISPs special case these to look good; but that is a different kettle of fish…)
	Note that there is also the question where one would like to measure the linkspeed; for example for DSL there is the link to the DSLAM, the link from the DSLAM to the next network node, sometimes a PPP link to a remote BRAS system (that might throttle the traffic). All of these can be the bottlenecks of the ISP connection (depending on circumstances). My take is that one would like to look at the link between modem and DSLAM as the bottleneck, but the opinions differ (and then there is cable with its shared first segment...). 

2) Some links have quite peculiar properties that are hard to deduce from quick speed tests. For example ATM based ADSL links (this includes all ADSL1, ADSL2 and to my knowledge all existing ADSL2+ links) will show a packetize dependent link speed. In short ATM uses an integer number of 48 byte cells to transport each packet, so worst case it adds 47 bytes to the payload for small packet that can effectively double the size of the packet on the wire, or stared differently half the link speed for packets of that size. (Note thanks to the work of Jesper Brouer and Russel Stuart the linux kernel can take care of that issue for you, but you need to tell the kernel explicitly.)

3) many links actually do not have a constant wire speed available. For docsis (basically cable) the local segment is shared between many users and transmit timeslots are shared between requestors, giving effectively slower links during peak hours. For DSL a resync between DSLAM and modem can (significantly) change the negotiated speed; something cerowrt does not get any notice of…

	I guess buffer bloat mitigation needs to move into the modems and DSLAMs to get rid of the bandwidth guessing game. For cable at least the modems are getting better (thanks to PIE being part of the docsis 3.1? standard), but for DSL I do not think there is any generic solution on the horizon…


Best Regards
	Sebastian






> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel