<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 24, 2018 at 3:33 PM Jonathan Morton <<a href="mailto:chromatix99@gmail.com">chromatix99@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> On 24 Jul, 2018, at 11:11 pm, Benjamin Cronce <<a href="mailto:bcronce@gmail.com" target="_blank">bcronce@gmail.com</a>> wrote:<br>
> <br>
> 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.<br>
<br>
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.<br>
<br>
> 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.<br>
<br>
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.<br>
<br>
 - Jonathan Morton<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Here is an example of what I'm seeing <a href="https://www.dslreports.com/speedtest/36310277">https://www.dslreports.com/speedtest/36310277</a></div><div>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. </div></div></div>