Re: [Bloat] geoff huston's take on BBR

["Bless, Roland (TM)" <roland.bless@kit.edu>]

Hi Geoff,

Am 13.06.2018 um 01:02 schrieb Geoff Huston:
>> On 13 Jun 2018, at 1:58 am, Bless, Roland (TM) <roland.bless@kit.edu> wrote:
>>>
>>> no - I started the flows at 10, 20 and 30 seconds after the initial flow started.
>>
>> This is nevertheless advantageous for BBR, since it performs its
>> ProbeRTT phase every 10s. So using 11, 23, and 34 seconds may
>> make a difference in convergence speed (that was at least observed
>> in our experiments).
> 
> 
> I’m not sure that I follow this - It was my understanding that BBR used the RTT interval as its control timer, and maintained a constant send rate for 6 successive RTTY intervals, then inflated the sending r4ate by 25% for the next RTT interval and deflated it by the same amount for the next RTT interval. I don’t believe that there is any absolute timer in BBR along the lines of a 10 second timer that you appear to be suggesting here.

I didn't write that BBR uses a 10s timer, but BBR actually uses a time
window of 10s. What you describe is BBR's ProbeBW phase, where
it probes for more bandwidth. However, your understanding is not
quite correct. Since BBR uses a maximum filter (windowed by 10RTTs),
it actually increases its sending rate _immediately_ if the 1.25
pacing gain achieved a higher delivery rate (which is nearly always the
case if multiple flows are present).
So depending on where the pacing_gain is raised in the gain cycle (it
starts randomly), BBR will increase its sending rate even within this
gain cycle of 8 RTTs and keep it for further 10 RTTs. BBR will
decrease its sending rate only after 10 RTTs. That is why
multiple BBR flows together are sending always faster than the
bottleneck rate in total.
I would recommend that you check https://queue.acm.org/detail.cfm?id=3022184
again.

Now for the 10s interval. You are correct that it's not
a 10s timer, but I wasn't suggesting that either.
The RTprop estimate is defined on page 7 of the article
and  described as
"Since path changes happen on time scales >>RTprop, an unbiased,
efficient estimator at time T is
...= min(RTT_t) \forall t \in [T-W_R,T]
i.e., a running min over time window W_R (which is typically
tens of seconds to minutes)."
and on p. 31:
"BBR flows cooperate to periodically drain the
bottleneck queue using a state called ProbeRTT. In any
state other than ProbeRTT itself, if the RTProp estimate
has not been updated (i.e., by getting a lower RTT
measurement) for more than 10 seconds, then BBR enters
ProbeRTT and reduces the cwnd to a very small value
(four packets)."
So it's basically a time window and also implemented like that.
A concise BBR description can be also found in our paper in
section II (http://doc.tm.kit.edu/2017-kit-icnp-bbr-authors-copy.pdf).

Regards,
 Roland