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

[David P. Reed]

Depends on the type of the provider. Most providers now have shared paths to the backbone among users and give a peak rate up and down for brief periods that they will not sustain... In fact they usually penalize use of the peak rate by reducing the rate after that.

So at what point they create bloat in their access net is hard to determine. And it depends on your neighbors' behavior as well.

The number you want is the bloatedness of your path through the access provider.

This is measurable by sending small probes back and forth to a measurement server... Measuring instantaneous latency in each direction and combining that information with one's recent history in a non trivial calculation. 

Note that that measurement does not directly produce provider speeds that can be input to the shapers used in codel. But it does produce a queue size that can.

So it's a plausible way to proceed as long as the operators refuse to fix their gear to manage the actual link that is problematic.

Personally I'd suggest that the gear makers' feet be held to the fire... by not "fixing" it by an inferior fix at the home router. Keep the pressure on them at IETF and among their customers.

On May 24, 2014, "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?
>_______________________________________________
>Cerowrt-devel mailing list
>Cerowrt-devel at lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/cerowrt-devel

-- Sent from my Android device with K-@ Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140524/7346ac09/attachment-0002.html>