Will BBR behave abnormally due to discontinuous sending flow

[uken chou]

For each flow, the server always sleeps 100-200ms after sending 2MB data.

Will BBR be affected because the measured BtBW/RTT  is not accurate？

[Neal Cardwell]

On Mon, Feb 27, 2023 at 9:48 PM uken chou <zyx104...@gmail.com> wrote:

For each flow, the server always sleeps 100-200ms after sending 2MB data.

To help understand the scenario you are asking about, what do you imagine for:

+ the min_rtt

+ the bottleneck buffer size

+ the bottleneck link bandwidth

+ the number of flows

 

Will BBR be affected because the measured BtBW/RTT  is not accurate？

Why do you say, "the measured BtBW/RTT  is not accurate"? Is that because 100-200ms has elapsed, and the network or traffic may have changed while the flow was idle? Keep in mind that any congestion control algorithm will risk inaccuracy due to this issue. A classic congestion control algorithm (e.g. Reno or CUBIC) will also risk inaccuracy: either the algorithm maintains its cwnd during idle periods, in which case the algorithm runs a significant risk of overestimating the appropriate cwnd; or the  the algorithm resets its cwnd to a default value after an idle periods, in which case the algorithm runs a significant risk of underestimating the appropriate cwnd (or overestimating the appropriate cwnd if the path has a very low BDP).

Furthermore, a classic algorithm that does not pace when restarting from idle is at a massive disadvantage. As noted in the BBR draft:

https://datatracker.ietf.org/doc/html/draft-cardwell-iccrg-bbr-congestion-control#section-4.4.1

The "Restarting Idle Connections" section of [RFC5681] suggests restarting from idle by slow-starting from the initial window. However, this approach was assuming a congestion control algorithm that had no estimate of the bottleneck bandwidth and no pacing, and thus resorted to relying on slow-starting driven by an ACK clock. The long (log_2(BDP)*RTT) delays required to reach full utilization with that "slow start after idle" approach caused many large deployments to disable this mechanism, resulting in a "BDP-scale line-rate burst" approach instead. Instead of these two approaches, BBR restarts by pacing at BBR.bw, typically achieving approximate rate balance and a full pipe after only one BBR.min_rtt has elapsed.¶

best regards,

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/cc9b5817-617e-4570-be5c-74143c96f788n%40googlegroups.com.