BBR论文中文翻译

BBR 论文中文翻译（原文：BBR: Congestion-Based Congestion Control)

译者：林佳烁 邮件：15622383059@163.com Github仓库：https://github.com/yue2388253/BBR-Translation

Measureing bottleneck bandwidth and round-trip propagation time

因为各种原因，今天的互联网并不能像我们所期望的那样很好地传输数据。世界上大部分蜂窝网络用户都会经历几秒乃至几分钟的时延；在公共局域如机场和会议厅等，WIFI质量经常是非常差的。物理和气候学者想要与全球范围内的合作者传输千兆字节级别的数据，但可能会发现他们精心准备的Gbps级别的底层网络在洲际传输中只能达到Mbps级别。

这些问题之所以会发生，是因为在80年代设计TCP拥塞控制的时候，TCP将丢包作为“拥塞”的信号。在那个年代，这个假设确实是正确的，但这是因为受限于技术原因。而当网卡的速率从Mbps级别进化为Gbps级别，内存从KB级别进化到GB级别之后，丢包与拥塞的关系变得不那么紧密了。

今天的这些TCP拥塞控制算法，包括至今为止最好的算法CUBIC，都是基于丢包的。他们是造成这些问题的主要元凶。当瓶颈链路的缓存较大时，这些基于丢包的拥塞控制算法流填满了缓存，造成了bufferbloat。当瓶颈链路的缓存较小时，这些算法会又将丢包作为发生拥塞的信号，从而降低速率导致了较低的吞吐量。为了解决这些问题，必须提出一种不是基于丢包的拥塞控制算法，这需要设计者对网络拥塞是如何并且在哪里产生的有非常深刻的理解。

Congestion and Bottlenecks

在一个TCP连接中，每个传输方向都存在一个最慢的链路，或者说瓶颈链路（bottleneck）。

Bottleneck很重要！这是因为：

1. 它决定了该连接的最大传输速率（举个例子：如果高速公路上的某一段路发生了车祸，将会导致该道上的车速降低至那一段路的车速）。

2. 它是造成队列的元凶！因为只有一个链路的离开速率大于它的到达速率，队列才会缩短。对于一个尽力传输最大速率的连接来说，因为其他的链路速率都比bottleneck大，所以最后会造成bottleneck的队列。

无论一个TCP连接需要穿越多少链路，也无论这些链路的速率各自是多少，从TCP的角度来说，一个及其复杂的路径的行为终究跟一条与它拥有相同RTT和bottleneck速率的简单链路一样。这两个参数，RTprop（Round-trip propagation time）和BtlBw（bottleneck bandwidth），决定了传输的性能。（打个比方，如果将一条网络路径类比为一个管道，RTprop就是管道的长度，BtlBw就是管道中最短的半径。）

图1展示了RTT和发送速率与发送数据大小的关系。图中的蓝线受到了RTprop的约束，绿线受到BtlBw约束，红线受到瓶颈链路的缓存约束。注意阴影区域的部分是不可达的，因为这会至少违反一项约束。这三种约束形成了3不同的区域，分别为app-limited，bandwidth-limited，buffer-limited。在三种区域，流的行为是完全不同的。

图1 发送速率和RTT vs 在外数据

当没有足够的数据来填满管道时，RTprop决定了流的行为；当有足够的数据填满时，那就变成了BtlBw来决定。这两条约束交汇在点inflight=BtlBw*RTprop，也就是管道的BDP（带宽与时延的乘积）。当管道被填满时，那些超过的部分（inflight-BDP）就会在瓶颈链路中制造了一个队列，从而导致了RTT的增大，如图1所示。当数据继续增加直到填满了缓存时，多余的报文就会被丢弃了。拥塞就是发生在BDP点的右边，而拥塞控制算法就是来控制流的平均工作点离BDP点有多远。

基于丢包的拥塞控制算法工作在bandwidth-limited区域的右边界区域，尽管这种算法可以达到最大的传输速率，但是它是以高延迟和高丢包率作为代价的。在存储介质较为的时候，缓存大小只比BDP大一点，此时这种算法的时延并不会很高。然而，当存储介质变得便宜之后，交换机的缓存大小已经是ISP链路BDP的很多很多倍了，这导致了bufferbloat，从而导致了RTT从毫秒级升到了秒级。

工作在bandwidth-limited区域的左边界比工作在有边界好。在1979年Leonard Kleinrock就展示了，无论是对流自身而言，或是对整个网络来说，工作在左边界是最优点，这个点在实现最大传输速率的同时，保持了低时延和低丢包。不幸的是，当时Jeffrey M.Jaffe也同时证明了不可能存在一个分布式算法可以收敛到这个边界点。这使得学术研究不再尝试去设计可以工作在该边界点的分布式算法。

我们谷歌工作组每天花了大量的时间来查看从世界各地发来的TCP报文头部，从而对流的行为机制有了很深的了解。我们通常首先计算出流最重要的两个参数，RTprop和BtlBw，这两个参数都可以从trace中推断出来。这表明Jaffe的结论可能不再适用。他当时做出这个结论是因为测量具有模糊性（例如，RTT的增加有可能是因为流的路径改变了，也有可能是瓶颈链路的带宽减少了，也有可能是因为别的流竞争而导致队列等等）。尽管不可能在单次测量中得到非常可靠的值，但是一个持续时间较长的连接会告诉你很多信息，从中或许可以设法来估计得到一个可靠的值。

使用最近在控制领域中提出的鲁棒伺服环来对这些观测结果进行处理，可以设计出一种分布式拥塞控制协议。该协议可以针对真实的拥塞进行反应，而不是基于丢包或者短暂的队列时延的，它可以大概率收敛到Kleinrock的最优边界点。因此这推动了我们近三年的研究——如何基于这两个观测参数bottleneck带宽及RTT（这就是BBR缩写的来源，bottleneck bandwidth and round-trip propagation time）来设计拥塞控制算法。

Characterizing the bottleneck

当一个连接满足以下两个条件时，它可以在达到最高的吞吐量的同时保持最低时延：

1. 速率平衡：瓶颈带宽的数据到达速率与BtlBw相等；

2. 填满管道：所有的在外数据（inflight data）与BDP（带宽与时延的乘积）相等

其中，第一个约束保证了瓶颈带宽可以得到100%利用。而第二个约束保证了流有足够的数据来填满瓶颈链路而且同时不会溢出（排队）。第一个条件本身并无法保证路径中不存在队列，它只能保证流的速率不发生改变（例如，考虑一个连接在一开始就发送了10个报文到一个BDP只有5个网络中，并且接下来一直保持瓶颈速率发送。这样子会导致在一开始就填满了管道，并且制造了5个报文的队列，并且这个队列永远不会被消灭）。相似地，full pipe条件也不能保证链路中没有队列。比如，一个TCP连接可以以burst方式发送BDP数量的报文，若该连接每次发二分之一BDP，并且发两次，此时full pipe条件得到满足了，然而网络中的平均队列长度是BDP/4。为了最小化网络中的队列长度，唯一的方式是同时满足以上两个条件。

然而，BtlBw和RTprop可能是动态变化的，所以我们需要实时地对它们进行估计。目前TCP为了检测丢包，必须实时地跟踪RTT的大小。在任意的时间t，
$$RT{T}_t=R{T}_{pro{p}_t}+{\eta }_t$$

其中，最后一项表示“噪声”。造成噪声的因素主要有：链路队列，接收方的时延ACK配置，ACK聚合等因素等待。RTprop是路径的物理特性，并且只有路径变化才会改变。由于一般来说路径变化的时间尺度远远大于RTprop，所以RTprop可以由以下公式进行估计：

R T p