tcp bbr pacing 的对与错

前面提到 pacing 替代 burst 是大势所趋，核心原因就是摩尔定律逐渐失效，主机带宽追平交换带宽，交换机不再能轻易吸收掉主机突发，且随着视频类流量激增，又不能以大 buffer 做带宽后备。因此，主机必须 pacing。

再看一下到底什么是 bufferbloat。bufferbloat 不是一个瞬时行为，而是持续行为。举个例子就能明白。为什么中国大河流域大湖少，因为中国地形东西落差太大，百川东到海，势能足够，吞吐就够大，足以抹平任何堰塞：

对任何流体，特别是大突发流体，buffer 一旦填充，除非上游主动排空，buffer 很难排空，只要有填充态 buffer 就必然增加时延。一般倾向是，buffer 无论多大，若不加干涉，总会被填满。不加干涉的流体本质就是 capacity-seeking，不信你自己挖一个水平的渠道，中间某些地方加宽一点，然后从一端灌水观察一下。

aimd 只能事后解决 bufferbloat 后的可用性收敛问题，解决不了 bufferbloat 本身，即使在大流量下，统计意义上，所需 buffer 数量也和流数量的 1/2 次方成正比，而且还要配合复杂的 red aqm 等技术。

所以，解决 bufferbloat 要么下游加大带宽，要么上游减少突发。端到端标准建议是后者，即从主机开始就 pacing，而 bbr 是一个 “如何计算主机 pacing rate” 的一个实例。至于加大带宽，端到端无力干涉，未来可能会是链路并行化，而这必然导向多路径，但这是后话，本文不谈。

说到底，主机似乎必须 pacing。但这引入另一个关于 bbr 的问题：

• 端到端的全链路是 n 跳而非 1 跳链路，而主机 pacing 只能影响第一跳 buffer 状态，但 bbr pacing 计算则基于全链路 bottleneck 带宽。

很简单的一个 use case：如果共享第一跳 a 的流 1 的 bottleneck bw 大于 流 2 的 bottleneck bw，它们都在 a 获得 bottleneck bw，而流 2 和流 3 共享最后一跳 b：

除非所有 bbr 一起 probe，否则 bbr 的状态机非常脆弱，它不是稳定的。bbr probe 效果并非如论文所说为探测空闲资源，现实中，在多流共享全链路场景不得已的行为，系统本身不稳定，bbr 需要不停 probe 扶正，而计算的代价非常大，这也不是算不算的准的问题，而是不得不计算，胡乱写一个 probe gain 系数都 ok，但必须做。

主机 pacing 的问题在于，一旦堆积 buffer，pacing rate 越小 buffer 占比越低，结果是获得带宽越小。交换机要考虑多流带宽复用，让交换机根据 buffer 状态和排队规则分配带宽才是正解，因为主机计算的 pacing rate 到了交换机并不算数，交换机根本无视这个 pacing rate，它是无效的。

为什么我说每条流跟踪 max(bw / rtt)->b 和 minrtt 并基于此控制自己的 inflight 是对的：

• b * minrtt 意味着不主动堆 buffer，b 不一定最大，但 b / rtt 一定最优；
• inflight += (minrtt / rtt) * beta 增加固定余量动态发现带宽变化，这 buffer 堆积算是动态自适应的代价；
• (minrtt / rtt) 修正 minrtt 本身的 buffer 堆积，因为 minrtt 本身也是统计最小值，不意味着不排队。

理论上，所有流的 (minrtt / rtt) * beta 就是整个网络中所有 buffer 的和，至于每条流的 bdp 余量到底堆积在哪，由整个网络的当前状态决定，这个状态是个统计状态，本质上是概率问题，上述三点保证全网收敛，但千万别精确计算。

去掉 bbr 不合理的假设就都合理了，也变简单了。bbr 的问题在于试图在统计环境中通过计算描述一个确定状态，相当于控制风力和风向时计算每个空气分子动量，显然，只需要控制单位面积的空气分子总量和外力方向就可以了。

那主机可以不 pacing 吗，显然不可以，为了降低第一跳突发减少第一跳 bufferbloat，所有主机固定 pacing 也不是不行，比如 500mbps pacing，而不是以主机能力突发。至于后面的跳，主机控制不了，只能交换机做。如果交换机为提高出口能效，塞住出口 10ms，buffer 占有率达到一定量再批量发送，拦了一座大坝，那就谁也没办法。

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