On 17/09/16 19:53, Dave Taht wrote:
BBR is pretty awesome, and it's one of the reasons why I stopped
sweating inbound rate limiting + fq_codel as much as I used to. I have
a blog entry pending on this but wasn't expecting the code to be
released before the paper was... and all I had to go on til yesterday
was Nowlan's dissertation:

http://blog.cerowrt.org/papers/bbr_thesis.pdf

are we sure - that's a fairly different algorithm and different expansion of the acronym...

> video streaming experiments ran on a live, production CDN, where clients included real mobile and desktop users

> large, multinational production network

hmm, I suppose...

> ## Acknowledgments ##
>
> Van
> ...
> Eric
> ...


ok, there's clearly some overlap here :-D.


which seemed closer to good than anything I'd read before, but still
wrong in a few respects, which has taken a few years to sort out. I
think reading the upcoming acm queue paper is going to be fun!

I think they have identified the right variables to probe - RTT and
bandwidth, in sequence - for modern congestion control to work much
better.

Still BBR makes a few assumptions that do not hold (or so I think) -
with wifi in the control loop, and it needs wider testing in more
circumstances than just google facing out - like on itty bitty nas's
and media servers - and especially seeing what happens when it
interacts with fq_codel and cake would be good to see. I've watched
youtube be *excellent* for 2 years now, and only had the faintest
hints as to why.

It was quite amusing that the original patchset didn't compile on 32
bit platforms.

And make no mistake - it still makes plenty of sense to apply
fq_codel-like algorithms to routers, and the stuff we just did to wifi
for fq_codel and airtime fairness. Had I thought BBR solved everything
I'd have quit years ago.



On Sat, Sep 17, 2016 at 11:34 AM, Maciej Soltysiak <mac...@soltysiak.com> wrote:
Hi,

Just saw this: https://patchwork.ozlabs.org/patch/671069/

Interested to see how BBR would play out with things like fq_codel or cake.

"loss-based congestion control is unfortunately out-dated in today's
networks. On
today's Internet, loss-based congestion control causes the infamous
bufferbloat problem"

So, instead of waiting for packet loss they probe and measure, e.g. when
doing slow start (here called STARTUP) they don't speed up until packet
loss, but slow down before reaching estimated bandwidth level.

Cake and fq_codel work on all packets and aim to signal packet loss early to
network stacks by dropping; BBR works on TCP and aims to prevent packet
loss.
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Reply via email to