Re: [Cerowrt-devel] BBR congestion control algorithm for TCP in net-next

[Dave Taht <dave.taht@gmail.com>]

On Wed, Sep 21, 2016 at 2:06 AM, Alan Jenkins
<alan.christopher.jenkins@gmail.com> wrote:
> 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...

Yes it is very different, but it appears to have had the germ of at
least one of the good ideas in the soon to be published BBR.

"BBR detects bufferbloat by comparing its calculated correlation to a
configurable threshold (e.g., 90%) and declaring bufferbloat whenever
the value exceeds the threshold."

"Upon detecting bufferbloat, BBR immediately sets the TCP cwnd to the
window estimate, rather than gradually reducing the sending rate as
in, for example, Proportional Rate Reduction [19]. Immediately
changing the cwnd has two advantages. 27 First, it stops packet
transmissions immediately and prevents further exacerbating the delay.
When the transmissions resume with the reduced cwnd, they should
experience shorter queuing delay.

*Second, drastic changes in sending rate should result in sharp
differences in observed RTT, increasing the signal-to-noise ratio in
the observations and improving the correlation calculation*."

I dunno, I'm just reading tea leaves here!

can't wait for the paper!



>> 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 <maciej@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.



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org