<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 21/09/16 10:39, Dave Taht wrote:<br>
<blockquote
cite="mid:CAA93jw5hR7bjxYNgzWQOSAtKWG+0oUGLFk+dmvmSMgkx5YTzuA@mail.gmail.com"
type="cite">
<pre wrap="">On Wed, Sep 21, 2016 at 2:06 AM, Alan Jenkins
<a class="moz-txt-link-rfc2396E" href="mailto:alan.christopher.jenkins@gmail.com"><alan.christopher.jenkins@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">are we sure - that's a fairly different algorithm and different expansion of
the acronym...
</pre>
</blockquote>
<pre wrap="">
Yes it is very different,</pre>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAA93jw5hR7bjxYNgzWQOSAtKWG+0oUGLFk+dmvmSMgkx5YTzuA@mail.gmail.com"
type="cite">
<pre wrap=""> 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!</pre>
</blockquote>
<br>
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 :).<br>
<br>
I thought I saw a few other technical links. The rate measurement
is a similar idea.<br>
<br>
<blockquote
cite="mid:CAA93jw5hR7bjxYNgzWQOSAtKWG+0oUGLFk+dmvmSMgkx5YTzuA@mail.gmail.com"
type="cite">
<pre wrap="">can't wait for the paper!</pre>
</blockquote>
<br>
excite!<br>
<br>
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.<br>
<br>
(And after PROBE_RTT it randomizes the next PROBE_BW phase, to avoid
the harmful kind of synchronization).<br>
<br>
<blockquote
cite="mid:CAA93jw5hR7bjxYNgzWQOSAtKWG+0oUGLFk+dmvmSMgkx5YTzuA@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">video streaming experiments ran on a live, production CDN, where
clients included real mobile and desktop users
</pre>
</blockquote>
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">large, multinational production network
</pre>
</blockquote>
<pre wrap="">
hmm, I suppose...
</pre>
<blockquote type="cite">
<pre wrap="">## Acknowledgments ##
Van
...
Eric
...
</pre>
</blockquote>
<pre wrap="">
ok, there's clearly some overlap here :-D.
</pre>
</blockquote>
</blockquote>
<br>
<br>
</body>
</html>