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

[Alan Jenkins <alan.christopher.jenkins@gmail.com>]

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

On 21/09/16 10:39, Dave Taht wrote:
> On Wed, Sep 21, 2016 at 2:06 AM, Alan Jenkins
> <alan.christopher.jenkins@gmail.com> wrote:
>> are we sure - that's a fairly different algorithm and different expansion of
>> the acronym...
> Yes it is very different,

My cryptic conclusion was a common group of names were involved in both 
projects (including "Neal" as well).  If there wasn't _some_ connection, 
I think they'd have suggested changing the project name to avoid confusion.

>   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!

I guess you're referring to PROBE_RTT.  PROBE_RTT seems so obvious 
though, but I guess that's true of all the best ideas :).

I thought I saw a few other technical links.  The rate measurement is a 
similar idea.

> can't wait for the paper!

excite!

Aside: just reading the code I think PROBE_RTT will synchronize with 
other BBR instances sharing the same bottleneck.  Very cool if it works 
that way.

(And after PROBE_RTT it randomizes the next PROBE_BW phase, to avoid the 
harmful kind of synchronization).

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



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