BBR_v2.0真的要来了！ - 好文

昨天google在BBR论坛上发布了，BBR算法小组的最新进展。链接如下

* BBR Congestion Control Work at Google IETF 102 Updates：
https://datatracker.ietf.org/meeting/102/materials/slides-102-iccrg-an-update-on-bbr-work-at-google-00

<https://datatracker.ietf.org/meeting/102/materials/slides-102-iccrg-an-update-on-bbr-work-at-google-00>
* BBR Congestion Control:IETF 102 Update: BBR Startup：
https://datatracker.ietf.org/meeting/102/materials/slides-102-iccrg-bbr-startup-behavior-01

<https://datatracker.ietf.org/meeting/102/materials/slides-102-iccrg-bbr-startup-behavior-01>
修改的内容主要包括以下一个方面：

* 提高与基于丢包的拥塞算法(Reno/Cubic)的共存能力。降低BBR算法的抢占性，提高不同算法之间的公平性。
* 减小排队丢包和排队时延的情况。这里主要根据丢包率和标记ECN比例来设置inflight的两个门限值，inflight_hi和inflight_lo。
* 加快min_rtt的收敛性，增加是将进入Probe_RTT模式的频率由10s设置到2.5s。
* 减小Probe_RTT模式带来的带宽的波动，进入到Probe_RTT不在是等待in_flight小于等于4。

BBR_v2.0对Start_up、Probe_bw以及Probe_RTT模式都做了相应的修改，改动最大的是PROBE_BW模式中的探测部分。下面分别对各个模式所做的修改进行介绍。

BBR_v1.0的Start_up模式的退出条件是进行连续三轮探测，最大带宽没有增加25%，探测出来的带宽值趋于平稳。而BBR_v2.0在BBR_v1.0的基础上增加了一个退出路径。当某一轮的丢包率超过1%并且丢包个数超过8个，或者某一轮中收到路由器标记ECN的比例超过50%，则可以退出Start_up模式，并且将inflight_hi更新为最大in_flight值。

Start_up模式的其他修改是将拥塞窗口增益由2.89改为2，并考虑到ack聚合情况下，会增加一些额外的窗口值。BBR作者也在BBR论坛中说过为什么pacing_gain是2.89，是为了确保pacing_rate能够每隔一轮RTT增加一倍，理论理想值计算出来的pacing_gain为2.77左右，而cwnd_gain的设置是为了能让cwnd能每隔一轮RTT增加一倍，只要每次收到ack确认几个包，拥塞窗口就能增加几个包，也就是设置的cwnd_gain计算出来的target_cwnd要超过当前的in_flight值，如果出现ack聚合现象，探测出来的带宽就会偏小，不能连续增加，target_cwnd就会限制cwnd的增加。因此将cwnd_gain设置为2时，需要考虑ack聚合情况增加额外窗口。

BBR_v1.0版本中，Probe_RTT是个BBR公平性的体现，但是min_rtt收敛的速度许需要20-30s的时间，并且每次进入到Probe_RTT模式，都会带来吞吐率大幅降低，因为这时将拥塞窗口降低到4，保证了链路的通畅不出现排队，才能探测出准确的min_rtt。因此，估计很多厂商都直接不进入到Probe_RTT或者将进入到Probe_RTT的频率调低。

v2.0版本则将进入到Probe_RTT模式进入的条件改为2.5s没探测到更小的min_rtt，并且Probe_RTT模式是从in_flight
小于0.75BDP开始算起。通过这种“暴饮暴食”到“少食多餐”变化，避免了过大的带宽波动，以及更好的收敛性。

BBR_v1.0两条流的竞争情况

BBR_v2.0两条流的竞争的情况

从上面两图可以看到，BBR_v2.0可以让两条流更快的到达平均共享10M链路带宽，并且进入到Probe_RTT带来的网络整体的吞吐量降低的幅度更小。

Probe_Bw模式的改动较大，v1.0中是将Probe_Bw以min_rtt为基准分为8个周期，第一个周期为探测周期，pacing_gain设置为1.25，第二周期为清空周期，pacing_gain设置为0.75，之后六个周期为平稳周期，将pacing_gain设置为1.0，平稳发送。更大的带宽探测是通过第一周期加快了发送速率带来的探测。各个探测周期的退出条件分别为：

* 探测周期：in_flight > 1.25*BDP或者发生丢包并且需要时间超过min_rtt.
* 清空周期：in_flight <= BDP 或者时间超过min_rtt.
* 平稳周期：时间超过min_rtt.

BBR_v2.0中也类似将Probe_Bw模式分为三个周期，UP周期、DOWN周期以及CRUISE周期，并且增加了两个门限值，inflight_hi以及inflight_lo，inflight_hi用于UP周期，inflight_lo用于CRUISE周期。

UP周期中类似BBR_v1.0探测周期，用于探测出一个更大的带宽，但探测的过程中分为平稳探测和指数增加探测两个部分，主要区分是in_flight
是否大于inflight_hi。平稳探测阶段为v1.0中方式，通过控制发送速率的增加来增加in_flight的值，当in_flight大于inflight_hi之后进入指数探测阶段，in_flight的值每轮增加1,2,4,8...直到退出UP周期。

UP周期退出条件为 in_flight超过1.25*BDP，某一轮丢包率超过1%并且丢包个数超过8或者某一轮标记ECN的数据包个数超过50% 。

DOWN周期与v1.0没有多大区别，只是退出条件变为了in_flight 小于BDP。

CRUISE周期类似v1.0的平稳周期，为了让出部分带宽，增加了inflight_lo，进入时初始化为min(BDP,
0.85*inflight_hi)最小值，inflight_hi为之前估算管道最多缓存的数据包个数，乘以一个0.85是让出一部分的管道缓存让其他流来探测。并且inflight_lo值也会根据丢包和标记某一轮标记ECN数据包比例来动态调整。退出条件为时间。

Probe_Bw周期的时长不在是8倍min_rtt，而是两个时间min(T_bbr,
T_reno)的最小值，T_bbr是时间范围为2-5s，如何计算不得而知，T_reno是min（BDP,
50）*RTT的时长。Bw过期时间不在是过去的十轮，而是更长的2个Probe_Bw周期时长。

BBR_v2.0与BBR_v1.0相比，改动较大，但整体方向是往保守的方向进行改动，尤其是Probe_Bw阶段的改动，为了照顾Reno/Cubic这类算法增长较为慢的问题，整个探测周期较大的延长了，不在是每隔8*min_rtt时间进行一次探测，并且中国这种浮躁的环境下，改激进变得有侵略性，各个厂商肯定能马上推进，之前BBR_v1.0出来后，组里都各种加班加点，争取早日用上这种高大上的算法。而BBR_v2.0这种为CUBIC算法让出带宽，"我为人人"的拥塞算法，除了用于降低重传比，降低成本可能会使用，真的能替换BBR_v1.0算法吗？

热门工具换一换