BBR_v2.0真的要来了!

发布时间:2018-07-25 16:01  浏览次数:56

  昨天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算法吗?

 

标签

归档

阅读排行

支付宝搜索“559315787”,天天领红包