<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 2, 2016 at 3:32 PM, Jonathan Morton <span dir="ltr"><<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 2 Dec, 2016, at 21:15, Aaron Wood <<a href="mailto:woody77@gmail.com">woody77@gmail.com</a>> wrote:<br>
><br>
> So, how is this likely to be playing with our qos_scripts and with cake?<br>
<br>
</span>Cake’s deficit-mode shaper behaves fairly closely like an ideal constant-throughput link, which is what BBR is supposedly designed for.</blockquote><div><br></div><div>Great. Yes, that's right: BBR's favorite case is a constant-throughput link or shaper, since that's the easiest to model.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  I haven’t read that far in the paper yet, but it shouldn’t trigger any “bucket detection” algorithms, because it doesn’t have a “bucket”.  It is capable of bursting, but only to the minimum extent required to reconcile required throughput with timer resolution and scheduling latency; I’ve tested it with millisecond timers.<br></blockquote><div><br></div><div>That's also good to hear. If it doesn't have a "bucket" or allow unsustainable bursts, then it should work well with BBR, and shouldn't trigger the long-term/policer model.</div><div><br></div><div>Of course, if we find important use cases that don't work with BBR, we will see what we can do to make BBR work well with them.</div><div><br></div><div>cheers,</div><div>neal</div><div><br></div></div></div></div>