[Bloat] Question about fq_codel vs modem buffers

[Sebastian Moeller]

Hi Rich,

On May 2, 2015, at 04:49 , Rich Brown <richb.hanover at gmail.com> wrote:

> I posted a message about using SQM & OpenWrt on Tom's Hardware, and got a response from someone who's somewhat knowledgeable. I'm not sure of the proper response, so I wanted to ask here first. Here's the question that has me stumped.
> 
> http://www.tomshardware.com/answers/id-2615979/high-latency-person-internet.html#15786081
> 
> My thoughts:
> 
> I know fq_codel takes control of the bottleneck by being set to a couple percent below the fastest link speeds observed in each direction.
> 
> The author of the rebuttal says that the (DSL or Cable) modem buffers will fill up if the "upload drops from 3 to 2mbps". I can think of two ways this can happen:
> 	- Actual link bit rate drops

	Yes that can happen, e.g. in oversubscribed cable systems; currently sqm-scripts and or qos-scripts can NOT deal with this, gargoyle arguable can with its active controller (which is ping based and will allow to control reasonably slow bandwidth fluctuations on the order of seconds). This should be quite uncommon for DSL-links (caveat: seamless rate adaptation would make this les rare, but I yet have to see proof f SRA deployment in the field ;) ).

> 	- Congestion/oversubscription in the head end causes effective data rate to drop

	This should not fill up the modem’s buffer, but the DSLAM’s/MMTS's; but no matter where as long as the buffers are badly controlled buffer bloat will rear its ugly head again ;) In my opinion, the poster is right in theory the shaper needs to be set at <= the effective max transmit rate. Now oversubscription of the DSLAM’s/CMTS’s uplink is somewhat tricky to handle as it it will result in wildly fluctuating rates that are hard to track from the CPE side, also I think there is no guarantee that each CPE gets the same % of the uplink, so shaping in the CPE to reduce buffer bloat might result in no latency under load improvement while still sacrificing bandwidth. One really hopes that the head-end manufacturers get fq_codel into those devices (and potentially not in a flow fair, but in a prefix fair way so that all CPEs/customers are treated equally).
> 
> But I don't know enough about the physical characteristics of cable/dsl links to understand how they actually work, nor how fq_codel can (or can't) accommodate degradation.

	So currently we relay on HTB (or in the near future cake) to shape the rate so that we make sure the bottleneck link stays under our control. Neither HTB nor cake have enough insight in the upstream network topology/traffic to adjust their shaper to counter degradation of effective bandwidth. I really should look into gargoyle’s controller to figure out whether we can borrow this easily and include this as an add-on to sqm-scripts (it should not be rocket science, just configure a target-IP for continuous ping probes and react to latency increases above a threshold with rate reductions; the devil will be in the details, like when to open up the bandwidth again, and how much to actually change the throttle, but these should be open to empiric research).

Best Regards
	Sebastian

> 
> Could someone help me shape a response? Thanks.
> 
> Rich
> 
> 
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat