Need help

[Sadjida Lebid]

Hello everyone,

I have just start studying the behavior of bbr and I have many questions in mind that might be basic:
1) I didn't understand the choice of the pacing gains, why did you choose these fixed values (1.25, 0.75, 1, 1, 1, 1, 1)?
2) In startup phase, why it waits for the last 3 rounds to switch to drain phase?
3) In RTT probe, why reduce the inflight to "4" packets?

Thank you for helping me  

Best regards

[Neal Cardwell]

On Thu, Dec 1, 2022 at 4:33 AM Sadjida Lebid <sadjid...@gmail.com> wrote:

Hello everyone,

I have just start studying the behavior of bbr and I have many questions in mind that might be basic:

Thanks for the questions! If you have not already, I recommend:

(1) Reading the ACM Queue article about BBR, including the appendix, which gives a detailed overview of the algorithm and the rationale for various aspects.

(2) Watching the video recording of the IETF 97 ICCRG presentation that introduces and summarizes BBR [slides].

1) I didn't understand the choice of the pacing gains, why did you choose these fixed values (1.25, 0.75, 1, 1, 1, 1, 1)?

As noted in the appendix of the ACM Queue article about BBR: "This design allows the gain cycle first to probe for more bandwidth with a pacing_gain above 1.0, then drain any resulting queue with a pacing_gain an equal distance below 1.0, and then cruise with a short queue using a pacing_gain of 1.0. The average gain across all phases is 1.0 because ProbeBW aims for its average pacing rate to equal the available bandwidth and thus maintain high utilization, while maintaining a small, well-bounded queue."

The specific 1.25 value was chosen experimentally; as noted in the ACM Queue article about BBR: "Cellular systems adapt per-subscriber bandwidth based partly on a demand estimate that uses the queue of packets destined for the subscriber. Early versions of BBR were tuned to create very small queues, resulting in connections getting stuck at low rates. Raising the peak ProbeBW pacing_gain to create bigger queues resulted in fewer stuck connections, indicating that it's possible to be too nice to some networks. With the current 1.25 × BtlBw peak gain, no degradation is apparent compared with CUBIC on any network."

 

2) In startup phase, why it waits for the last 3 rounds to switch to drain phase?

This is also discussed in the appendix of the ACM Queue article about BBR: "During Startup, BBR estimates whether the pipe is full by looking for a plateau in the BtlBw estimate. If it notices that there are several (three) rounds where attempts to double the delivery rate actually result in little increase (less than 25 percent), then it estimates that it has reached BtlBw and exits Startup and enters Drain. BBR waits three rounds in order to have solid evidence that the sender is not detecting a delivery-rate plateau that was temporarily imposed by the receive window. Allowing three rounds provides time for the receiver's receive-window autotuning to open up the receive window and for the BBR sender to realize that BtlBw should be higher: in the first round the receive-window autotuning algorithm grows the receive window; in the second round the sender fills the higher receive window; in the third round the sender gets higher delivery-rate samples. This three-round threshold was validated by YouTube experimental data." 

3) In RTT probe, why reduce the inflight to "4" packets?

Please see the "Minimum cwnd for Pipelining" section of the BBR Internet Draft, which says:

   ...BBR imposes a floor of BBRMinPipeCwnd (4 packets,
   i.e. 4 * SMSS).  This floor helps ensure that even at very
   low BDPs, and with a transport like TCP where a receiver may ACK only
   every alternate SMSS of data, there are enough packets in flight to
   maintain full pipelining.  In particular BBR tries to allow at least
   2 data packets in flight and ACKs for at least 2 data packets on the
   path from receiver to sender.

Also please note that in BBRv2 instead of setting the cwnd to 4, in ProbeRTT the algorithm sets the cwnd to half of the estimated BDP. This greatly reduces the throughput penalty of ProbeRTT, as you can imagine. We have active work underway to reduce the throughput penalty even further in common cases.

best regards,

neal

Thank you for helping me  

Best regards

--
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/c2a6205d-0c98-43ac-8381-f8543a5752a1n%40googlegroups.com.