漫话拥塞控制：BBRv3 来啦

周一(2023/07/31)临近午夜刚准备睡觉，收到 bbr-dev 一封邮件：

贴出 IETF CCWG 大会链接：IETF117-CCWG-20230725-2200 以及 bbr3 幻灯片：BBRv3: Algorithm Bug Fixes and Public Internet Deployment，更详细信息以及讨论：https://github.com/ietf-wg-ccwg/wg-materials/tree/main/ietf117。

注解：本次大会主要围绕 RFC5033，RFC2914 以及几个具体 cc 展开。

写个短评：

1. bbr 调参的方式非常勉强，就像统计学(热力学)发展之前用牛顿刚体力学的方式测量气体温度。
2. bbr 过于关注参数过程的细节，疏忽了终态的稳定性，更缺少稳定性的证明。
3. 折腾，陷进细节，怎么折腾还是老样子，不看好。种子埋错了，执念反而相害。
4. 不过也许有人会觉得 nice，尊重。

我无意纠缠，只发了一个朋友圈评论：最基本的，信息量不足以精确刻画链路画像时，试图精确测量带宽和 rtt 是徒劳的，所以要保留一定浮动空间，以 buffer 思想来调参。要让算法在统计期望附近有效，或者有能力自己调自己，而不是从外界纠结是 3.1918 还是 3.2764。cubic 标准选择一条特定曲线，并不是说这条曲线是 “正确” 的，而是这条曲线在统计意义是 “可接受” 的，如果按照 bbr 的性子调教 cubic，在任何 “特定” 场景下，基于特定三次曲线生成的代码，都能提一个派池。

有人说 “如果不折腾就没有饭吃”，有人说 “为了进 RFC”，这两方面大概是真的，除了这两方面，单纯从技术上看，我有些不同看法。

之前我评论过，“特定场景” 是实验室数据和现实之间差异的根源，早在 1990 年代，来自萨莉弗洛伊德的 Why We Don’t Know How To Simulate The Internet 最早系统化了这观点。

理论上，每个场景对应一组最优参数，而互联网场景数量不可穷举，neal 在大会演讲被问到调整 2.25X cwnd_gain 时对环境的假设(且取决于经验)时，仅提到 fifo 和 tail drop，但背后肯定有一套精确推导和计算，这并不是统计复用的调参风格。But … The proposed algorithms should be assessed in difficult environments…proposed alternate congestion controllers should be assessed in a range of environments.(RFC5033 Guidelines)

bbr1，bbr2，直到 bbr3，参数的生效过程似乎越来越精确，背后的数学推导也越来越明确，人们追求在特定场景的最优效果，并且为此花费了大量时间和精力，但我认为这并不是全局拥塞控制的正确发展方向。

两个极端的两条路，一个是在单一场景或少许几组自认为典型的环境上不断精确计算参数，直到达到最好效果，但这组参数显然无法用于其它场景，bbr 大概在这条路上越走越远。毋宁说 G 家的 B4 就是个大型数据中心，具有固定的时延和丢包率。

另一个极端是让算法自己调自己，言外之意是放弃任何假设，简单说，算法不针对任何场景，没有假设意味着信息量的损失，适应性用精度来换。具体做法也不难，仍以 bbr 为例，cwnd_gain = 2 只做初始值，在传输过程中若检测到 (rtt_max- rtt_min)*bw 超过 inflight_max，则增加 cwnd_gain 的值，即 cwnd_gain = f(rtt, bw)，如果用大数据猛灌，有点 AI 调参的意思，就更高尚了。

cubic 介于两极端之间，选择一组参数，在统计意义上可接受，结果怎么也不会太差，cubic 均衡在一个典型的马鞍：如果继续调参，统计性能将往两边下跌，如果试图继续优化它，则要在正交的方向艰难攀爬。

拥塞控制不单单是调参，甚至不单单是技术问题，在一个多样性，异构网络组成的互联网上，天知道拥塞控制到底需要做到哪些才是完备的。上周我的评论如下：

网络拥塞控制和主机网络完全不同，拥塞控制处理的是复杂系统而不是计算机，跟社会学，博弈论，控制论，复杂网络这些更接近，这个强调了不止一次。
多年前第一次做这个，写了一个模块，上线，观察一周，发现效果比没上线好不少，结果另一个工人同样的环境打了我的脸，该工人没有上线任何新东西，指标也比上周好，难道我要把观测周期拉长到一个月吗，我要准备多少对照组，这根本就是错误的方向。拥塞控制难在往往解法就在那里你就是看不到，当你看到时，可能只需要改了配置参数。我们在 bbr 发布前很久就发现了 bw/min_rtt 模型，只是因为重传率太高以为那个模型是错的，但 google 推出 bbr 后，我 c！这个模型真的就是错的，它是个单机模型，单靠修修补补的小派池(patch)怎么收敛，大方向不对，怎么都不对，你看 bbr2 重新引入 aimd，但吞吐不行了，就又有人叫了。
曾经有个工人(也可能是我自己，但我怕争议)对我说，其实那些中医治好病的案例，绝大多数都是病人自愈，你看，大家都明白什么意思，但我还是没把话说死，绝大多数的意思至少有所保留。大概拥塞控制就是这意思，有什么都不做，可能比你乱打一通王八拳还好，但王八拳也不孬，所以，经验越多，越觉得 cubic 最好。
但扁鹊和蔡桓公又给了另一种启示，如果一个厂商让你买他家的 cdn 服务，告诉你如果不买你的客户会因你的服务太卡而流失，跟你去医院问医生我这个要不要做手术，医生肯定会说不治将恐深，因为手术是暴利啊，但也有偶尔的情况，商家是对的，你不听，最终司命之所属，无奈何也。
现在网络传输就是这种情况，别家堵塞网络，你不多发点报文，你就永远过不去，你的用户真的会流失，所以还是要做点什么的，也不能什么都不做，这个角度看，可能 cubic 还真就不行，但改改它可能就好了。

bbr3，简单说两件事。

bbr3 又把 inflight_hi 导致的问题过程搞激进了，这种事我去年就做过一版：BBRv2 对 inflight_hi 的补偿，把 inflight_hi 再提上去，避免它限制 probe，但怎么证明这举措的全局影响。后来我扔了它。

不过总体上看，bbr3 的这个 fix 还算 OK。neal 提到的循环依赖是个固有问题，基于 bw/rtt 测量的算法必会经历，必须让 inflight 过载，才能测得实际 bw，反之，必须排空 inflight 以至 bw 同步衰减，才能测得 min_rtt，否则正交变量就是阴阳两隔，此在 probe up 阶段尤其重要。

另一个，bbr3 在 probe up 时将 cwnd_gain 增加了，还是那个问题，如果 buffer 大，bbr3 流会以递减的加速比挤压其它流的 capacity，如果 buffer 小，这举措反而可能造成丢包重传，你怎么知道 buffer 是大是小，还不如自己调自己。

bbr3 的这个 fix 不太 make sense，加上 probe drain gain 从 0.75 改为 0.9，会被挑战。我记得当时还有个推导，为什么 probe drain 使用 0.75 gain。

大概就是这意思，buffer 是统计复用理论基础排队论的现实物件，给个 buffer 而不是给个精确的 quota 是统计复用的精髓，意思就是给你这么多的自由度，折腾去吧，背后的原因就是统计复用的固有属性。比如，无法确定容器内特定分子的速度和动能，但整个容器的温度却是明确的，而这个容器同样也是一个 buffer。

以一个信息精确性和充分性问题结束本短评。

平滑掉抖动的算法只平滑掉了表征抖动的数据而不是抖动本身，这恰恰丢失了信息，和以往非平滑计算方法算相比，这仅仅方便了计算，基于测量的复杂计算方法恰恰要放大每一次抖动而不是抹掉它们，试图内窥这个 rtt 突增时到底发生了什么。

精确性之外，如果信息不充分，预测依然存在很大变数。要么你的典型场景真的很典型，这似乎不可能，要么就去寻找典型场景，给出 RFC8312-5.1，5.2 类似的穷举 benchmark，而不是在单一场景下精确计算。

浙江温州皮鞋湿，下雨进水不会胖。