On 21/09/16 10:39, Dave Taht wrote:
On Wed, Sep 21, 2016 at 2:06 AM, Alan Jenkins
<alan.christopher.jenk...@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.


_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Reply via email to