bbr->full_bw_reached update time problem

[duckless]

Hello,

I recently encountered an issue while reading the BBR code concerning the timing of the full_bw_reached update.

Consider a scenario:
After running at full capacity for a period, BBR experiences a prolonged increase in bandwidth (for example, in the early stages of using a mobile network with a weak signal, improving as the device moves, and the signal and network become better).

In the bbr_check_full_bw_reached function mentioned above(Code diagram), it is not possible to update the full_bw_reached state promptly. This is because full_bw_reached is set to true in the initial phase, and the current bandwidth continues to grow, preventing its timely update until the first occurrence of bandwidth growth not exceeding the threshold.

The inability to update full_bw_reached promptly leads to distorted evaluations for all conditions using bbr_full_bw_reached().

I have roughly read through the tcp_bbr.c code but haven't identified a solution to this issue. I'm unsure if I overlooked any crucial information.

Looking forward to your response.
Thank you.

[Neal Cardwell]

On Wed, Dec 13, 2023 at 10:10 AM duckless <zhangzhen...@gmail.com> wrote:

Hello,

I recently encountered an issue while reading the BBR code concerning the timing of the full_bw_reached update.

OK. In BBRv1, which it seems you are referencing, please keep in mind that the bbr_check_full_bw_reached() function is only used to decide whether to exit STARTUP.

 

Consider a scenario:
After running at full capacity for a period, BBR experiences a prolonged increase in bandwidth (for example, in the early stages of using a mobile network with a weak signal, improving as the device moves, and the signal and network become better).

In that scenario, with BBRv1 the connection would have set bbr->full_bw_reached "After running at full capacity for a period". And it would not have used the full pipe detection code after that. When the channel improved and "the signal and network become better", then the connection would discover the available bandwidth using the normal PROBE_BW state machine.

 

In the bbr_check_full_bw_reached function mentioned above(Code diagram), it is not possible to update the full_bw_reached state promptly. This is because full_bw_reached is set to true in the initial phase, and the current bandwidth continues to grow, preventing its timely update until the first occurrence of bandwidth growth not exceeding the threshold.

The inability to update full_bw_reached promptly leads to distorted evaluations for all conditions using bbr_full_bw_reached().

I have roughly read through the tcp_bbr.c code but haven't identified a solution to this issue. I'm unsure if I overlooked any crucial information.

It seems the missing piece here may be that in BBRv1 the bbr_check_full_bw_reached() function is only used to decide whether to exit STARTUP? So it is not expected to be a player in the kind of scenario you outline.

Sorry the code/comments do not make that more clear.

In BBRv3 the function works more as you seem to have anticipated, where it can be used to estimate bandwidth saturation at any point in the lifetime of a connection:

  https://github.com/google/bbr/blob/7542cc7c41c0492a0cdbeb77e295cbfdcd9f5e11/net/ipv4/tcp_bbr.c#L1924C13-L1924C38

best regards,

neal

 

Looking forward to your response.
Thank you.

--
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/5c8105ae-5915-4b99-80c7-33d9c06eda88n%40googlegroups.com.

[duckless]

Thank you for your response. However, I still have a small question.

If we continue with the aforementioned hypothetical scenario of 'operating at a low bandwidth steadily for some time and then gaining more bandwidth':

If, during this period, the Probe_RTT state happens to conclude, BBR will enter the Probe_BW state with a pacing_gain of 1.25 for bandwidth probing, rather than the exponential probing with a gain of 2/ln2 in the STARTUP state.

So, in this case, it takes a little longer to reach peak bandwidth, right?

(Corresponding code)

[Neal Cardwell]

On Thu, Dec 14, 2023 at 11:01 AM duckless <zhangzhen...@gmail.com> wrote:

Thank you for your response. However, I still have a small question.

If we continue with the aforementioned hypothetical scenario of 'operating at a low bandwidth steadily for some time and then gaining more bandwidth':

If, during this period, the Probe_RTT state happens to conclude, BBR will enter the Probe_BW state with a pacing_gain of 1.25 for bandwidth probing, rather than the exponential probing with a gain of 2/ln2 in the STARTUP state.

So, in this case, it takes a little longer to reach peak bandwidth, right?

Yes, if the available bandwidth increases after STARTUP has completed, then it takes BBR longer to utilize that available bandwidth than if that had happened during STARTUP. 

Reno and CUBIC have similar trade-offs. If the available bandwidth increases while those algorithms are in steady-state (congestion avoidance) then it takes the connections longer to fully utilize the bandwidth than if the bandwidth increase had happened during the initial slow-start phase.

best regards,

neal

 

To view this discussion on the web visit https://groups.google.com/d/msgid/bbr-dev/27c2b408-33ce-45e5-8af2-6be50b985433n%40googlegroups.com.