5.3 TCP BBR
Last updated
Last updated
BBR（Bottleneck Bandwidth and RTT）是由 Google 的研究人员开发的一种新的 TCP 拥塞控制算法。与 Vegas 类似，BBR 也是基于延时。这意味着它也会尝试探测网络设备 buffer 的增长来避免拥塞和丢包。BBR 和 Vegas 都使用一段时间内计算得到的最小 RTT 和观察到的瓶颈带宽来作为拥塞控制的主要信号。
图32展示了BBR的基本思想。假设一个网络只有一个瓶颈链路，这个瓶颈链路有部分可用带宽和队列容量。图中从原点开始，随着拥塞窗口的增加，更多的数据会被传输出来。最开始吞吐量会有增加（下图），但是延时（RTT）并没有增加，因为瓶颈链路并没有塞满。之后，随着数据传输速率达到了瓶颈带宽，设备中的队列开始堆积，此时RTT开始增加，同时吞吐量并没有增加。这是拥塞的初始阶段。图32实际上是图29中展示的4.5秒到6秒之间内容的简化版。
与Vegas一样，BBR的目标也需要精确的确定网络设备的队列何时开始堆积，而不是像Reno一样一直填满队列，直到发生丢包。BBR的很多工作都是关于提升确定转折点（注，也就是队列开始堆积的时间）的精确度。这里有很多挑战：带宽和延时的测量有误差；网络本身不是静态的；以及有关BBR和非BBR流之间公平竞争的永恒拷问。
相比与其他我们已经了解的方法而言，BBR一个显著特征是它不仅仅依赖于CongestionWindow来确定可以传输的数据量。其次，BBR也会尽量平滑处理发送速率，以避免突发可能带来的队列堆积。在理想情况下，我们可以正好按照瓶颈的速率发送数据，从而得到最大可能的吞吐量同时又不造成队列的堆积。尽管大部分TCP实现使用ACK的到达来“触发”数据的发送，从而保持在传输中的数据是恒定的，BBR会预估瓶颈带宽并使用一个本地的调度算法来按照预估值发送速率。ACK仍然起了很重要的作用，它被BBR用来更新有关网络的状态，但是他们并不会直接被用来控制数据发送。这意味着延迟的ACK并不会导致数据传输的突发。当然，CongestionWindow仍然会被用来确保发送足够的数据以充分利用网络，以及被用来确保传输中的数据不会多于带宽延时积从而导致队列溢出。
为了确保获得实时RTT和瓶颈带宽，有必要持续探测瓶颈链路带宽。当竞争连接流量下降时，可能会释放更多的可用带宽。除此之外，链路特性的变化（例如无线链路）或者路由的变化也可能带来更多的可用带宽。RTT也可能发生变化，尤其当网络路径发生变化时。为了探测RTT的变化，需要发送更少的流量，以避免队列堆积带来的额外延时增加。为了探测可用的带宽，需要发送更多的流量。因此，BBR会在当前预估的瓶颈带宽值上下进行探测（注，而不是像其他TCP只探测更多的资源）。如果有必要，预估的带宽值会更新，同时也更新发送速率和CongestionWindow。
图33描述了探测可用带宽和最小RTT的流程图。最开始是激进的startup以充分使用网络上的可用带宽，之后是减少发送速率以清空网络设备的队列（注，startup的激进策略可能使得队列堆积）。随后，算法进入了循环，在循环中BBR定时的以更低的速率探测更好的延时，或者以更高的速率探测更好的吞吐量。在足够长的时间之后（几秒），算法进入到ProbeRTT阶段，此时发送速率减半以清空网络设备的队列来测试更低的RTT。
这种方法的一个有趣之处在于，当大的数据流在ProbeRTT阶段急剧减少其发送速率时，这个数据流对于队列堆积带来的影响也下降了，从而导致其他数据流可以看到新的，更低的RTT，并同时更新它们自己对于RTT的预估。因此，当队列实际上为空或接近空时，数据流会趋于拥有相同的RTT预估，这有助于提升预估的准确性。
BBR的研究很活跃，并且演进的也很快，在本书写作的时候，已经提出了第二版。第二版的主要关注点在于公平性。例如，一些早期的实验展示了CUBIC在于BBR竞争时，只能获取100分之一的带宽。一些其他实验也展示了BBR数据流之间的竞争也可能不公平。第一版BBR对丢包不敏感，这可能会导致更高的丢包率，尤其当网络路径上的buffer更少时。随着不同的BBR的实现在不同的环境中的尝试，包括在Google自己的骨干网和互联网上，实际的结果被收集起来用来提升这里的设计。IETF拥塞控制工作组正在讨论相关的设计和实验。
更多阅读：N. Cardwell, Y. Cheng, C. S. Gunn, S. Yeganeh, V. Jacobson. BBR: Congestion-based Congestion Control. Communications of the ACM, Volume 60, Issue 2, February 2017.
