端到端拥塞控制的公平性和稳定性

昨天早上环城河跑步时的两三个思考，曾发了朋友圈，简单总结成文。

拥塞控制算法公平性度量要重新评估！仅以带宽公平性做论断是过时且自私的，在全局视角，平衡和稳定一定以某种表现为乘积 “矩” 来保证，比如力矩，跷跷板。在传输领域，这种矩就是 BDP。
以下以 AIMD 演示：

如图，在不同 RTT 下，虽然带宽不公平，但 BDP 恰好公平，这并不是巧合，正是 Buffer 动力学确保了这一点：越大的 RTT 流挤兑带宽的能力越弱。

一个矩形面积为长乘以宽，宽就是带宽，长就是时延，矩形面积就是 BDP，在共享链路的流量中，这个值是一定的。

站在能耗视角看，BDP 公平意味着能耗公平，带宽虽小但距离长时延大，这个 BDP 公平性意味着传输相同比特数的耗能相同，这不是公平本身的诠释吗？如果把拥塞视为能量的无端浪费，能耗的公平性恰就是拥塞控制本身(如果需要对浪费付费的话，这种控制力更加显而易见)。

So? 诸多 cc 旨在提高带宽公平性的手段大可不必，这件事难的原因恰恰因为这件事不值得做，大自然是和谐的，在一个解题过程中只要开始错综复杂，大概率就是路子走错了。BDP 公平性是天然可保证的，简洁，这就够了。一条长 RTT 流必然要付出长的代价，就是带宽，否则分布式长传对短 RTT 流反而不公平。

再看稳定性。

稳定性由收敛度量，如果一个算法可能出现由于不断堆积报文导致不断增长的 queuing delay，且该 queuing 无法通过算法本身的机制释放，该算法就是不稳定的。

以下是一个对 TCP Vegas 的模拟，首先看三条流一起开始：

简直完美，实验室般的完美，但魔鬼躲在细节。

根据算法描述，Vegas 能容忍 α，β 量级的报文在 buffer 中 queuing，如果一条新的 Vegas 流在某时间后进入瓶颈，该瓶颈处已经存在 α 的报文在 queuing，新流的 minrtt 将包含这部分报文导致的 queuing delay，如果所有 sender 都使用 Vegas，这种 queuing delay 将持续增加，增长率取决于 α，β 参数，拥塞将由算法本身促进，看一下 3 流共存，先后加入的模拟：

不光 Vegas，所有 delay-based 几乎都强依赖 minrtt 的测量，如果没有类似 BBR ProbeRTT 的机制，这类 cc 没有任何手段自行获得真实的 rtprop。这就是 vegas 不稳定的根源。

那么，为 Vegas 增加 200ms 的 ProbeRTT？没问题，但 minrtt 的相位差也会影响公平性，而这些都依赖测量手段的实现(这个细节我此前描述过，不再多说)，而不是算法本身。若再看 AIMD，它不依赖任何数据和测量实现，正如范雅各布森所说，buffer 溢出永远不会骗人，分组丢了就是丢了。

最后再看 TCP 友好性。

只要一条流的带宽大于 α√(β/p)，它就是 TCP(指基于标准 Reno 的传统 TCP) 不友好的，包括自家的 BBR 在内，这意味着大吞吐的传输协议不受欢迎，很难被 RFC 标准化，也正因为如此，BBR draft 一直致力于提高对 TCP 的公平性，最终这就是占 BBRv3 大量篇幅的内容。

造成这种情况(其实对于独立开发者和内容提供商而言，没人希望这样)的原因是大量存量服务都基于传统 TCP，因此需要被照顾，如果抢占大量传统服务的资源占用率，将是灾难性的。部分根本原因还在于 TCP 是系统实现的一部分，又与服务程序代码耦合，很难单独升级。但在接入带宽越来越高，随着增量服务逐渐倾向于 BBR，QUIC 等大带宽利用率算法或协议，这种 “大带宽不受欢迎” 的掣肘局面将被改进。

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