BBR拥塞控制算法 BBR Startup gain

在查看google的BBR算法时，里面出现了一个 startup gain的推到过程：

• For simplicity, let RTT=1 unit of time.
• For smooth traffic to avoid queue pressure, we want the sending rate to be driven by smooth pacing, so that the sending rate is equal to the pacing rate. To find the smoothest, gentlest pacing approach that roughly matches the growth dynamics of unpaced Reno/CUBIC, we want the pacing rate (sending rate) to double each RTT (each unit time interval). So let the pacing rate (sending rate) at a given time be given by some curve that doubles each unit of time

　　　　　　

      We use the constant scaling factor of k because different transport protocol implementations may choose different initial sending rates, depending on the environment or applicable standards.

• Based on the BBR architecture, we also want the pacing rate to be some pacing gain g times the estimated bandwidth:
• 　　PacingRate(t) = g • EstimatedBandwidth(t)

• In Startup, BBR sets the cwnd high enough that sending is governed by the pacing rate. This means that the sending rate is the pacing rate, so we know the rate of sending from (2).  This means that we can calculate the amount of data sent over an interval by integrating  the pacing rate over the time interval in question:　　　 

PacingRate(t) = g • EstimatedBandwidth(t)= g • DataDeliveredInRoundTripUpTo(t)= g • DataSentInRoundTripUpTo(t − 1)

 

 

• The Startup gain that BBR used in its original release was 2 / ln(2) = 2.89 . This derivation of 4 ln(2) = 2.77 is about (2.89 − 2.77)/2.89 = 4% lower than the original value

Validation Via Emulation

　　We have run quick tests using netem, comparing high_gain=2.77 (710 /256 = 2.773) instead of 2.89 (739).They look visually the same, and the Linux TCP BBR throughputs for 2-second transfers over a netem-emulated path with bw=100Mbps, rtt=100ms are quite similar: 78.35M (g=2.89) vs 77.98 (g=2.77), showing less than 0.5% difference in throughput. The delayfrom the first ACK until a bandwidth sample >= 99Mbps was .864 secs with high_gain=2.89, vs .891 secs with high_gain=2.77 (3% longer).