[Bloat] No backpressure "shaper"+AQM

Benjamin Cronce bcronce at gmail.com
Tue Jul 24 16:48:35 EDT 2018


On Tue, Jul 24, 2018 at 3:33 PM Jonathan Morton <chromatix99 at gmail.com>
wrote:

> > On 24 Jul, 2018, at 11:11 pm, Benjamin Cronce <bcronce at gmail.com> wrote:
> >
> > The problem that I'm getting is by adding my own shaping, a measurable
> amount of the benefit of their AQM is lost. While I am limited to Codel,
> HFSC+Codel, or FairQ+Codel for now, I am actually doing a worse job of
> anti-bufferbloat than my ISP is. Fewer latency spices according to
> DSLReports.
>
> We do know that applying SQM at the entry to the bottleneck link works
> much better than at the exit.  It's a fundamental principle.
>
> > That's when I thought of a backpressure-less AQM. Instead of having
> backpressure and measuring sojourn time as a function of how long it takes
> packets to get scheduled, predict an estimated sojourn time based on the
> observed rate of flow, but allow packets to immediately vacate the queue.
> The AQM would either mark ECN or drop the packet, but never delay the
> packet.
>
> It's a reasonable idea.  The key point is to use a deficit-mode
> scheduler/shaper, rather than the credit-mode ones that are common (mainly
> TBF/HTB).  The latter are why you have such a big, uncontrolled burst from
> the ISP in the first place.
>
>  - Jonathan Morton
>

>From what I understand, the ISP is shaping on the core router and they're
using whatever algorithm so happens to be implemented. It has been a few
years since I last talked to anyone from there and it does seem to be
acting differently, so I am not sure if they purposefully made any changes,
but when I did talk to them last time, they said they did not do any
purposeful configurations to combat bufferbloat and whatever I was seeing
was entirely arbitrary. When their shaping was worse, it very much acted
like a sliding window in that it pretty much like line rate 1Gb/s through
until ~200ms, at which point it started to clamp down very quickly and
reach a healthy steady state in ~2 seconds. But during that transition,
loss spikes were pretty bad. Now it feels like the window is just much
larger. I no longer see it hitting line rate anymore, but it does seems to
be capped around 2x provisioned. When I was at 150Mb, It maxed out around
300Mb/s and slowly dropped to 150Mb. Now it maxed out about 500Mb and
roughly the same slope down to 250Mb.

Here is an example of what I'm seeing
https://www.dslreports.com/speedtest/36310277
While there are a few spikes on the download, when running many tests in a
row, I see fewer and smaller spikes than if I do my own shaping.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20180724/5fc41dd1/attachment-0002.html>


More information about the Bloat mailing list