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

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

先给出slides链接：

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
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.892ln⁡2≈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还没有放出…

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

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

让人们久等了的TCP BBR v2 0快要出炉了
分享一下我老师大神的人工智能教程!零基础,通俗易懂!http://blog.csdn.net/jiangjunshow 也欢迎大家转载本篇文章.分享知识,造福人民,实现我们中华民族伟大复兴! 这是连续 ...
基于oAuth2.0开发属于自己的SSO授权服务 - 授权码（Authourization Code）模式 (持续更新中。。。)
此文章篇幅较长,平日上班较少时间写作,请见谅.持续更新中... oAuth2.0系列文章目录 #mermaid-svg-AZMPq56OmFj1I7k0 {font-family:"treb ...
嵌入式相关开源项目、库、资料------持续更新中
学习初期最难找的就是找学习资料了,本贴精心汇总了一些嵌入式相关资源,包括但不限于编程语言.单片机.开源项目.物联网.操作系统.Linux.计算机等资源,并且在不断地更新中,致力于打造全网最全的嵌入式资 ...
面试1：Java、微服务、架构常见面试题（持续更新中）
Java.微服务.架构常见面试题(持续更新中) 文章目录 Java.微服务.架构常见面试题(持续更新中) ==**Java**== 1.Java概述 (1)JVM.JRE和JDK (2)Java特点 ...
linux运维常用命令一句话（持续更新中）
整理收集一些Linux运维管理.系统管理的常用命令,太多了记不住,只能记录下来方便日后查看.也可以和大家分享.如果你有好的一句话命令也贴出来吧.本文持续更新中. 1.linux启动过程开启电源 -- ...
Go语言开发学习笔记（持续更新中）
Go语言开发学习笔记(持续更新中) 仅供自我学习更好的文档请选择下方 https://studygolang.com/pkgdoc https://www.topgoer.com/go%E5%9F% ...
JAVA面试大全(持续更新中...)
本文旨在收集Java面试过程中出现的问题,力求全面,仅作学习交流,欢迎补充,持续更新中-,部分段落选取自网上,部分引用文章已标注,部分已记不清了,如侵权,联系本人 Java基础 1.面向对象的概述面 ...
【Vue全家桶+SSR+Koa2全栈开发】项目搭建过程整合学习目录（持续更新中）
写在开头大家好,这里是lionLoveVue,基础知识决定了编程思维,学如逆水行舟,不进则退.金三银四,为了面试也还在慢慢积累知识,Github上面可以直接查看所有前端知识点梳理,github传送门 ...
2020今日头条面试真题及答案整理最新最全持续更新中~~~~
大家好,我是好好学习天天编程的天天一个整天在互联网上爬虫的程序员,每天给大家分享学习干货的攻城狮 2020今日头条面试真题及答案整理&最新最全&持续更新中~~~~ 2020今日头条面 ...

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

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

最新文章

热门文章