昨天早上环城河跑步时的两个思考，发了朋友圈，简单总结成文。
拥塞控制算法公平性度量要重新评估！仅以带宽公平性做论断是过时且自私的，在全局视角，平衡和稳定一定以某种表现为乘积 “矩” 来保证，比如力矩，跷跷板。在传输领域，这种矩就是 BDP。
以下以 AIMD 演示：
如图，在不同 RTT 下，虽然带宽不公平，但 BDP 恰好公平，这并不是巧合，正是 Buffer 动力学确保了这一点：越大的 RTT 流挤兑带宽的能力越弱。
一个矩形面积为长乘以宽，宽就是带宽，长就是时延，矩形面积就是 BDP，在共享链路的流量中，这个值是一定的。
站在能耗视角看，BDP 公平意味着能耗公平，带宽虽小但距离长时延大，这个 BDP 公平性意味着传输相同比特数的耗能相同，这不是公平本身的诠释吗？如果把拥塞视为能量的无端浪费，能耗的公平性恰就是拥塞控制本身(如果需要对浪费付费的话，这种控制力更加显而易见)。
再看稳定性。
稳定性由收敛度量，如果一个算法可能出现由于不断堆积报文导致不断增长的 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 溢出永远不会骗人，分组丢了就是丢了。
浙江温州皮鞋湿，下雨进水不会胖。