施工中…

working

问题

手机蜂窝用户、wifi用户，上网速度很慢。虽然基础设施已经有Gbps为单位的带宽了，但是洲际用户却只能得到Mbps的连接。

原因是：TCP将报文丢失视为网络拥塞。这在1980年的时候是正确的，但随着网络硬件技术的发展，带宽从Mbps升级到了Gbps，硬件存储也从KB升级到了GB，报文丢失与网络拥塞的关系变得微妙起来了。

当前的TCP拥塞算法是导致上面现象的原因。例如，当buffer比较大的时候，基于拥塞的算法会尽可能的将buffer撑满，从而引起bufferbloat问题（由于大量报文堆积在buffer中，会造成延迟比较大）；当buffer比较小的时候，基于拥塞的算法会将报文丢失当做网络拥塞，造成吞吐量急剧下降，但实际上只是buffer满丢包而已。

当前TCP拥塞算法无法兼顾这两种情况。要找到一个合适的拥塞控制好算法，需要理解拥塞发生在哪里、是怎么发生的。

Congestion and Bottlenecks

任何时刻，全双工的TCP连接，在两个方向上，都有一个最慢的链路点（link），称其为bottleneck，瓶颈。bottleneck很重要：

  • bottleneck决定了最大的数据传输速率。例如晚高峰的6车道，如果某处因为事故导致只能一条车道通行，那么整条道路的通行速度不会快于单车道的速度。
  • bottleneck是持续排队的地方。队列要变小，只能出大于入，但是对于最慢的link点，显然从上游来的报文要比从该link点出去的报文更快。

不管一个连接经过了多少links，也不管links的速度是否相同，从TCP的角度来看，任意复杂的路径都可以表现为具有相同RTT（往返时间）和瓶颈率的单个链路。RTprop (round-trip propagation time) 和 BtlBw (bottleneck bandwidth)这两个物理约束绑定了传输性能。如果以现实中的管道来类比的话，RTprop类似管道的长度，而BtlBw类似管道的直径，它们一起定义了管道的传输性能。

图一展示了当网络上报文数量变化时，RTT和传输速率的情况。蓝线显示的是RTTprop约束，绿线显示的是BtlBw约束。两个约束将传输分为3个区：app限制、带宽限制、buffer限制。

Figure 1

当管道中数据不多的时候，RTTprop决定行为（RTTprop越小，传输越快）；反之，则由BtlBW主导（BtlBw越大，能传输的报文越多）。

最佳点就是RTTprop和BtlBW相交的位置，此时网络中的报文inflight = BtlBw × RTprop，即BDP（带宽延迟乘积，亦即上面管道的体积）。继续增加管道的报文，当超出管道的容积时，此时报文会在瓶颈点进队列（开始使用buffer），此时管道的带宽不变，但是延迟变大了，即发生了bottlebloat。如果再继续增加管道的报文，当超出队列的容量时，报文会开始被丢失。

基于拥塞的在带宽限制区域右侧（即右边黑竖线）做文章，带来的结果就是高延迟、高丢包率。早期内存比较贵的时候，buffer很小，基于拥塞的算法对延迟的影响比较小；但内存便宜了以后，buffer大幅提升，缓冲队列变的比较大，早期算法就会导致bufferbloat，延迟时间从毫秒级变成了秒级。

带宽限制区左侧（即左边黑竖线）是个更合适的点。1979年Leonard Kleinrock认为这是一个很理想的点，同时具备最大带宽和最小时延。但与此同时Jeffrey M. Jaffe证明了无法创建一个分布式算法来收敛这个点，因此研究方向就转变到了不同的拥塞算法（cubic，reno, …）。

看看bottleneck

若吞吐量最大、并且延迟最小的，则管道中的数据量为：BDP = BtlBw × RTprop.

2个条件

(e.g., a connection sending a BDP in BDP/2 bursts gets full bottleneck utilization, but with an average queue of BDP/4) 怎么算出来的？

RTprop 物理属性，只有链路变化才会变化。 𝛈 ≥ 0 表示由于queue造成的噪声。

WR 时间窗口，表示一段时间内

RTT是TCP要求测量的，但bottleneck bandwidth并不要求。

通过观察时序上的2个ack，可以判断这段时间传送了多少数据，也就是传输速率。

deliveryRate = Δdelivered/Δt

Δdelivered是确定的，但是Δt是不确定的：比如sack，比如ack压缩，但它肯定比实际的时间差要大，所以计算出来的deliveryRate肯定比实际的bottle bandwidth要小。

BBR = Bottleneck Bandwidth and Round-trip propagation time

效果

  • High throughput even with shallow buffers and moderate loss rates
  • Low delay even with deep buffers (“bufferbloat”)

loss-based congestion control

reno, cubic

bufferbloat，缓冲膨胀

bandwidth and propagation delay 无法同时测量

BBR：朕就是这样的汉子，就是能测量的准，就是能最佳化的

状态机切换

       |
       V   +---> STARTUP  ----+   |        |         |   |        V         |   |      DRAIN   ----+   |        |         |   |        V         |   +---> PROBE_BW ----+   |      ^    |      |   |      |    |      |   |      +----+      |   |                  |   +---- PROBE_RTT <--+

计算公式

BBR congestion control computes the sending rate based on the delivery
rate (throughput) estimated from ACKs. In a nutshell:
 On each ACK, update our model of the network path:
    bottleneck_bandwidth = windowed_max(delivered / elapsed, 10 round trips)
    min_rtt = windowed_min(rtt, 10 seconds)
 pacing_rate = pacing_gain * bottleneck_bandwidth
 cwnd = max(cwnd_gain * bottleneck_bandwidth * min_rtt, 4)

Ref: