来自Google持续更新中的TCP BBR v2.0最新进展

昨晚，Google Groups “BBR Development” group发出了一个topic，我早上醒来才看到，大致扫了一眼，这又是BBR进化史上的一个里程碑。

先给出slides链接：

1. 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
2. BBR Congestion Control:IETF 102 Update: BBR Startup：https://datatracker.ietf.org/meeting/102/materials/slides-102-iccrg-bbr-startup-behavior-01

然后大致介绍一下这两篇更新里的要点。

在第一个slides中，大致介绍了3个要点：

• 缓解了Startup阶段以及激进发送带来的丢包和时延
• 改善了与传统CC算法并存时的公平性问题
• 重构了PROBE_RTT这个BBR状态的实现

为此，BBR在v2中更改了太多的框架意义上的逻辑，我摘录一段：

BBR v2 model:
- Mostly cruise at an operating point that maintains flow balance and leaves headroom
- inflight_lo: conservative in-flight bound based on recent loss/ECN signals
- Periodically probe beyond flow balance to probe robustly for higher volume, bandwidth
- inflight_hi: max volume flow had in flight before signals of congestion (loss, ECN)
- If probing higher inflight doesn’t trigger loss/ECN signals , grow probing rapidly
- inflight_probe: incremental probe data beyond inflight_hi (during probing)
- At a high level, BBR v2 has the same state machine states as v1
- But many of the mechanism details are new

能看出点什么吗？看看下面的图示也许就明白了：

看看是不是很像CUBIC，注意我摘录中的这一句子：If probing higher inflight doesn’t trigger loss/ECN signals , grow probing rapidly，这几乎就是一条下凸曲线，连同inflight_hi和inflight_lo，这和CUBIC在背后就是同一个思想。那么，区别是什么？

请注意，在Probe More阶段，同样都是下凸曲线，CUBIC所依托的是一个数学上AIMD收敛的三次曲线，这条曲线的推导在CUBIC的Paper上有，我自己也给出过一个自己的推导：
TCP拥塞控制算法-从BIC到CUBIC：https://blog.csdn.net/dog250/article/details/53013410
一切都是数学上的。然而BBR不同，虽然我们看到BBR v2.0也是类似的思想，但是它却不是基于数学的，而是基于测量的。

不管怎么说，BBR v2.0在这个模型上和BBR v1.0完全不同了。如果最终BBR v2.0采纳了这个模型….这该叫BBR v2.0呢，还是应该叫CUBIC v2.1呢？哈哈哈哈…

But many of the mechanism details are new

这个表现在哪里？

• STARTUP
  同样来自CUBIC的SlowStart之hystart的思路，BBR v2.0会根据丢包情况提前退出STARTUP阶段而不必等待带宽稳定，同时设置inflight_hi。
  之前有位朋友说在一定情况下，BBR初始时，一丢可以丢半窗口的包，这下福音了。
• DRAIN
  和BBR v1.0一致，BBR v2.0采用一次性收敛到estimatedBDP的策略，即drain to target。之所以还要强调这个，是因为在ProbeDrain阶段，也是这个策略。
• PROBE_BW
  PROBE_BW变化体现在三方面：
  1. Cruise：不再像BBR v1.0那般保持estimateBDP*1gain这样，而是确保inflight在inflight_hi之下保留一定的空间。
     
  2. ProbeMore：采用了类似SlowStart或者Startup阶段的指数级增加探测包的策略，同时在丢包时设置inflight_hi…
     
  3. ProbeDrain：由于BBR v1.0收敛实在太慢，BBR v2.0采用了一次性收敛的策略。
• PROBE_RTT
  PROBE_RTT这一次改变比较大，本质上，BBR v2.0的PROBE_RTT采取了少食多餐的策略，即：
  1. 进入PROBE_RTT的频率变高些(多餐，不再是10s这么久)；
  2. 进入PROBE_RTT时的反应缓和一些(少食，不再一下子降到4个inflight，而是0.75)。

总之，我们可以看到，BBR v2.0中魔数常量的作用变小了，更多的是基于实际测量值做策略变更，也就是呼应了BBR v2.0的目标需求：

All of these new design principles need an explicit, independent, tight bound on in-flight data

关于公平性，为什么要保留一定的headroom？

嗯，道路行车中，保持车距是一个基本素质，BBR v2.0显然也是这个意思，在填满queue，实际丢包之前，保留一定的空闲带宽空间可以留出一定的反应时间给各CC的始发端进行策略调整。很显然，没有填满带宽是一点需要付出的小代价，然而，收益却是，避免了发生丢包后更大的代价(BBR的停止Probe，设置lo，high，Loss_based CC的MD等等)。

再说说复杂的Startup。

毫无疑问，这个阶段的内在逻辑非常复杂，我曾经跟BBR的作者交流过这个阶段的细节，包括作者在内的大多数人在解释why的时候，也只能简单地说Reno/CUBIC如此，所以BBR也如此之类，只是稍加改进。

但是如果看Startup的代码实现，它却异常简单，保持不变的pacing gain，保持不变的cwnd gain，直到满足带宽稳定不再增加这个条件为止。可见，越是复杂的逻辑，就越是最好不要去动它，从Reno的SlowStart一直保持到BBR Startup，一贯如此…

可是这未免有点太粗糙了。

我们知道，BBR的CC是pacing rate based的，而不是cwnd based的(cwnd gian只是防止ACK聚合而导致发送端失速，只是一个补偿措施)。在Startup阶段检测到丢包只会简单地限制cwnd，但是这个限制却可能对Bufferbloat缓解或者丢包缓解不起作用，因为pacing gain并没有任何改变，依然是大约2.89的样子。

因此，BBR v2.0提出一个建议，即出现丢包时，将pacing gain降低到1.5，这样从根本上限制发送。

接下来还有一个问题，即，保持pacing gain和cwnd gain一致为2.89这件事真的正确吗？

前一段时间，我和温州皮鞋厂老板曾经计算过为什么BBR Startup阶段的gain是
2ln2≈2.89

$dfrac{2}{ln 2}approx 2.89$的问题，后面也和作者交流过，便写了好几篇这方面的文章，参考下面的top以及blog：
bbr-dev topic：https://groups.google.com/d/msg/bbr-dev/TlQG1UgEyyY/6FKB7Ah3AgAJ
TCP BBR之Startup gain的另一种推导法以及最新进展：https://blog.csdn.net/dog250/article/details/80754825
其实全局来看，将cwnd gain也设置成2.89是牵强的。假设这个2.89的cwnd gain只是一个简单贴合pacing gain的一个值，那么很显然它是有问题的，是的，它会造成Bufferbloat。因为在最后的3个RTTs，如此高的cwnd gain会造成queue积压的。

那么，现在的问题是，既然2.89对于cwnd来讲高了，多少合适呢？很显然，仅就cwnd gain而论，不是要保持和传统的SlowStart一致吗？答案便是CWND_gain=2.

Bufferbloat的问题藉此解决，然而新的问题出现。

如果cwnd gain减小为2，那么BBR将可能会面临ACK聚合造成的失速问题，在BBR的PROBE_BW阶段，我们知道要保持cwnd为2倍的BDP，以应对ACK聚集，那么在Startup阶段，同样面临类似的问题，此时cwnd减少为2将会严重加重这个问题，因为和2.89相比，又少了0.89比例的可以发送的数据包限额。

怎么办？

啊哈，这是BBR v2.0的另一个杀手级特性，即BBR Extra-CWND，它依托于extra AKCed。详情参见：
让人们久等了的TCP BBR v2.0快要出炉了！：https://blog.csdn.net/dog250/article/details/80629551
BBR Congestion Control Work at Google IETF 101 Updatehttps://datatracker.ietf.org/meeting/101/materials/slides-101-iccrg-an-update-on-bbr-work-at-google-00

将cwnd gain降低为2我认为是正确的，至于它所带来的新的问题，则是另外的独立的话题，它拥有独立的解决方案，这个也是正确的处理方式。

花了点时间，把BBR v2.0的进展总结了这篇文章，姑且叫做BBR v1.8吧，毕竟真正的v2.0的patchset还没有放出…

…
浙江温州不行了，因为小米已经出皮鞋了，另外还有皮带。