新式拥塞控制漫谈

接上篇：BBR 与 queuing

统计复用的 TCP/IP 网络的统计特征随互联网规模的扩大越发明显，很难单靠连接内闭环的算法控制拥塞。

分析一个 BBR 相关的 case。

BBR 的高带宽利用率来自丢包恢复后随即 undo，背后的道理是，BBR 操作点假设是无拥塞的，丢包非拥塞导致，无论 pacing rate 还是 cwnd，均无需从低点重新探测，直接 undo 到丢包前 BBR 的操作点(即丢包前测得的 maxbw)即可，这和 AIMD 模型完全不同。

这是 BBR 模型动力学的推论。

但在现网环境，丢包可能就是拥塞引起，拥塞可能由于其它流量引发，你的 BBR 流只是被挤兑而丢包，在丢包恢复后 undo，你的 BBR 只是简单地加入挤兑大军，这无疑雪上加霜。BBR 在这个意义上是没有拥塞收敛点的，在静等 10 rounds 的 max-filter 过期间，BBR 持续以 overestimate 的 maxbw 发送数据，在持续丢包，持续重传间乒乓反复，这便解释了 BBR 的高重传率的一种成因。

即便不考虑其它侵入流的干扰，链路本身的干扰也足以打乱 BBR 的状态机转换。本质上由于基于采样的拥塞控制算法没有抗抖动能力，采样噪声总是有，如何降噪是一个几乎无解的问题。

我们不想陷入不可知论，事情还是要去做。

所有流量认同并收敛到同一稳定状态，是未来拥塞控制的目标。

引一篇前文：互联网拥塞控制实践

大致就是这个意思。不基于模型去启发式预测，只根据实际度量结果学习最佳配置，最笨的方法是手工记录并分析散点，最高效但也最复杂的方法就是机器学习。

这是一种适者生存的观点，体验最佳的优质连接的配置将会被记录下来，基于网络流量局部性原理，用当前的优质配置指导未来以附近的流量，将是高尚的。

早在 2013 年，我曾经用网络流量局部性原理做了一个 nf_conntrack 的 percpu cache，在海量连接场景(hash 链表长度大于 5000)下，同等并发，CPU 开销降低 30% ，处理时延降低 10us ，效果非常好。
上面谈到的拥塞控制 issue 与此类似，如果一条流拥有优质配置，该优质配置应用到附近的流，一定也是优质的。

说起局部性，任何连续事物都有局部性特征，数学上，连续性就是用无限邻域局部性定义的，因此才有极限，导数等延伸概念。针对拥塞控制意义上的网络流量，局部性是指：

• 时间局部性：当前流的特征在下一秒依然会延续。比如当前流量是一条视频流，下一秒的流量还属于同一条视频流。时间局部性由人们触发流量的行为决定。
• 空间局部性：以与当前流目标 IP 地址相邻的 IP 地址为目标的流，共享同一幅链路画像，因此可共享拥塞控制配置。空间局部性由 IP 地址的聚合分配原则决定。

与自然选择对应的是体验选择，因此应用程序要有机制将体验反馈到传输层。

我曾经通过徒手写千百个 if 语句干过这个事情，效果很不错，这个思路无疑是正确的。当我在一次公司内部的分享上再次谈起当年勇时，被一个评论惊到了，对，这才是真正“人工”智能。

每当我提起这个，无论人肉方法，还是机器学习，虽然看上去吊吊的，但大家内心还是觉得不靠谱，不认可这是一种"真正的算法"，大家还是希望能得到一个"连接内闭环的算法"，类似 CUBIC，BBR。

总之，依靠大量数据揭示相关性不如依靠自己聪明的大脑推导出相关性。可是当我说"连接内闭环的信息量根本不够做出决策"时，有人反驳我说"你太依赖信息了，真理就在那层布下面，掀开来看就是了"，我仔细想了想，好像也对。

最近看贺凯(美国汉学家 Charles O. Hucker 的汉名)的书，有个观点很有意思。说的是中国传统文化使人不擅长观察和记录，却非常擅长分析孤立事件。这可以解释中国人可以用非常精巧的算法求圆周率，算开方，却无法像第谷那样通过长期观测，积累有关行星运行的大量数据资料。这也解释了我收到的关于本文描述的拥塞控制方法的反馈。

在分析和综合之前，先要观察和记录，我以为。

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