Question about constant values in BBR

[ssw]

Hello everyone. First, thanks for using your time to read this question.

I wonder why probeRTT interval is 5 sec in BBR v2(or 10 sec in v1). Is 5 sec meaningful(or 10 sec in v1)? 

Also I wonder that why there are a lot of constant values in BBR(like probeRTT interval). Because I think that if these values are dynamical, there would exist situation that BBR can get more fairness, throughput, rtt or stabillity. (The how should be discussed later..)

[Neal Cardwell]

On Mon, Nov 20, 2023 at 10:29 PM ssw <ssw3...@gmail.com> wrote:

Hello everyone. First, thanks for using your time to read this question.

I wonder why probeRTT interval is 5 sec in BBR v2(or 10 sec in v1). Is 5 sec meaningful(or 10 sec in v1)? 

The basic trade-off is:

+ shorter PROBE_RTT intervals can help in more quickly establishing and then maintaining good min_rtt estimates, and thus keep queuing delays lower and speed convergence toward a fair share

+ longer PROBE_RTT intervals can help in maintaining consistently high throughput and avoiding tail latency issues

There is more discussion, covering more detail, in the appendix of the ACM Queue article about BBRv1:

"BBR was designed to spend the vast majority of its time (about 98 percent) in ProbeBW and the rest in ProbeRTT, based on a set of tradeoffs. ProbeRTT lasts long enough (at least 200 ms) to allow flows with different RTTs to have overlapping ProbeRTT states, while still being short enough to bound the performance penalty of ProbeRTT's cwnd capping to roughly 2 percent (200 ms/10 seconds). The RTprop filter window (10 seconds) is short enough to allow quick convergence if traffic levels or routes change, but long enough so that interactive applications (e.g., Web pages, remote procedure calls, video chunks) often have natural silences or low-rate periods within the window where the flow's rate is low enough or long enough to drain its queue in the bottleneck. Then the RTprop filter opportunistically picks up these RTprop measurements, and RTProp refreshes without requiring ProbeRTT. This way, flows typically need only pay the 2 percent penalty if there are multiple bulk flows busy sending over the entire RTProp window."

Also I wonder that why there are a lot of constant values in BBR(like probeRTT interval). 

The PROBE_RTT interval needs to be constant, so that all active flows can have a reasonable chance of reducing their sending rate at overlapping times, so that the bottleneck queue can drain and all active flows can obtain RTT samples close to their path two-way propagation delay. If the PROBE_RTT interval is dynamic or based on RTT, it's hard for me to see how to make that work well.

Because I think that if these values are dynamical, there would exist situation that BBR can get more fairness, throughput, rtt or stabillity. (The how should be discussed later..)

I agree that making some of the constants dynamic could probably increase throughput or reduce queuing (and thus RTT). However, there would be a cost in complexity. And I doubt that making more parameters dynamic would make things more fair, since different flows would end up with different values, making their behavior diverge, presumably making convergence to a fair share of bandwidth more difficult. Also, it's hard to see how making more parameters dynamic would increase stability. But I am interested to see what the research community comes up with! :-)

neal

 

--
You received this message because you are subscribed to the Google Groups "BBR Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bbr-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bbr-dev/5204e206-52f6-4aea-a761-c2fe38fc6e93n%40googlegroups.com.

[Dave Taht]

I have sometimes wondered what "remy" + BBR could do. I do not know if
that research continued.

https://web.mit.edu/remy/

> To view this discussion on the web visit https://groups.google.com/d/msgid/bbr-dev/CADVnQynf8cyMdjT12VX7cQoy8hwgO0xcJAkhfQ8cYYzX%2BiMSrg%40mail.gmail.com.



--
:( My old R&D campus is up for sale: https://tinyurl.com/yurtlab
Dave Täht CSO, LibreQos

[ssw]

Thanks for answering!

But I got one more curios thing. I wonder why probeRTT phase can makes a risk of high latency.

Is it because of that very small in-flight packets make fast recovery hard in porbeRTT? 

2023년 11월 21일 화요일 오후 10시 43분 34초 UTC+9에 dave...@gmail.com님이 작성:

[Neal Cardwell]

On Wed, Nov 22, 2023 at 4:56 AM ssw <ssw3...@gmail.com> wrote:

Thanks for answering!

But I got one more curios thing. I wonder why probeRTT phase can makes a risk of high latency.

Is it because of that very small in-flight packets make fast recovery hard in porbeRTT? 

The main reason PROBE_RTT phase risks high latency is because it reduces cwnd significantly. With a given amount of data to transfer, the lower the cwnd, the higher the latency to transfer that amount of data.

As you note, there is a secondary issue that there is a smaller amount of in-flight data, which makes fast recovery harder. However, with BBRv2 or v3 allowing half the estimated BDP in flight, and with RACK-TLP being an effective loss recovery technique that can usually utilize fast recovery rather than RTOs, this is a less serious concern. 

best regards,

neal

 

To view this discussion on the web visit https://groups.google.com/d/msgid/bbr-dev/02f31773-2bbf-4718-a0a4-0a37d3c88e8dn%40googlegroups.com.