来自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

能看出点什么吗?看看下面的图示也许就明白了:
来自Google持续更新中的TCP BBR v2.0最新进展_第1张图片

看看是不是很像CUBIC,注意我摘录中的这一句子:If probing higher inflight doesn’t trigger loss/ECN signals , grow probing rapidly,这几乎就是一条下凸曲线,连同inflight_hiinflight_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之下保留一定的空间
      来自Google持续更新中的TCP BBR v2.0最新进展_第2张图片
    2. ProbeMore:采用了类似SlowStart或者Startup阶段的指数级增加探测包的策略,同时在丢包时设置inflight_hi…
      来自Google持续更新中的TCP BBR v2.0最新进展_第3张图片
    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等等)。
来自Google持续更新中的TCP BBR v2.0最新进展_第4张图片


再说说复杂的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是 2ln22.89 2 ln ⁡ 2 ≈ 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还没有放出…



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

你可能感兴趣的:(BBR,BBRv2.0)