昨天google在BBR論壇上釋出了，BBR演算法小組的最新進展。連結如下

  修改的內容主要包括以下一個方面：

1. 提高與基於丟包的擁塞演算法(Reno/Cubic)的共存能力。降低BBR演算法的搶佔性，提高不同演算法之間的公平性。
2. 減小排隊丟包和排隊時延的情況。 這裡主要根據丟包率和標記ECN比例來設定inflight的兩個門限值，inflight_hi和inflight_lo。
3. 加快min_rtt的收斂性，增加是將進入Probe_RTT模式的頻率由10s設定到2.5s。
4. 減小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演算法嗎？