Re: [Bloat] No backpressure "shaper"+AQM

[Benjamin Cronce <bcronce@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2546 bytes --]

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

> > On 24 Jul, 2018, at 11:11 pm, Benjamin Cronce <bcronce@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.

[-- Attachment #2: Type: text/html, Size: 3044 bytes --]