《BBR evaluation at a large CDN》
解决的问题
通过在 (CDN) ((Content Delivery Network)) 的环境中对 (BBR) 算法进行评估，量化其带来的好处以及对网络流量的影响，从而帮助内容提供商选择正确的拥塞控制算法。
方法
使用多个策略对 (BBR) 进行评估，先在一个 (POP) ((Points of Presence))上进行一个小规模的 (BBR) 测试（a large wireless provider, a large wireline provider, PoP-to-PoP and intra-PoP traffic），最后进行了一个全面的 (POP) 测试。
该作者使用了两个评测指标，一个是吞吐量，一个是 (TCP) 流的完成时间，之所以采用两个评估指标，是由于在发送目标数据大小很小的时候，再去用吞吐量去评估，可能不够精确，存在很多噪声。因此，作者定量当发送数据大小小于3(MB) 时候，追踪流的完成时间，是更好的指标；当发送数据大小大于3(MB) 时候，使用吞吐量进行衡量。
A large wireless provider
在无线提供商的环境中，启用 (BBR) 算法有了一个明显的提高(6%-8%)，如上图所示，(test) 蓝线代表 (BBR) ，(control) 红线代表 (CUBIC) 。对于左图，我们可以发现，当在垂直蓝线时刻，激活 (BBR) 算法之后，(BBR) 算法的吞吐量很明显高于 (CUBIC) 算法的吞吐量。对于右图，在当 (CDF) ((cumulative distribution function))概率相同的时候，即同一纵坐标时，(BBR) 算法的吞吐大于 (CUBIC) 算法的吞吐量。
不过作者认为，由于无线环境中，丢包率较高，因此并不能确定该包的丢失是由于拥塞所引起的，从而对 (BBR) 算法的实验结果也有一定的质疑。
A large wireline provider
作者在有线环境中，根据不同发送数据的大小下所完成传输的时间对 (BBR) 做了评估，如上图所示，我们可以看见 (BBR) 在发送同等大小的数据时，抖动很小，并且完成的时间相比于 $CUBIC $ 算法也更短。不过，也会存在和 (CUBIC) 算法类似的抖动。总体而言，(BBR) 的性能是很好的。
不过作者认为，(BBR) 算法的增益，是从 (POP-to-Client) 的聚合视图所得出来的，无法确定该算法是否对所有的(TCP) 流都有增益。因此，进行了更加细化的评估。
PoP-to-PoP and intra-PoP traffic
作者更为细致的在 (poP-to-poP and intra-poP) 中使用 (BBR) 算法进行了实验评估，从上图我们可以发现，当在垂直蓝线时刻处激活 (BBR) 算法后，(BBR) 的吞吐量远不如 (CUBIC) 算法的吞吐量。
为什么在(POP-to-Client) 和 (poP-to-poP and intra-poP) 中，(BBR) 算法的性能会有如此大的差异呢？
作者后面通过服务器日志发现，(BBR) 在较高 (RTT) 和 重传率下会有很好的性能表现，而 (poP-to-poP and intra-poP) 中，由于是低 (RTT) 和低 重传率，因而比较适合 (CUBIC)
Full PoP test
作者最后进行了一次完整的 (PoP) 测试，使用了两个 (ASes) ((Autonomous Systems))，如上右图所示，两个网络的 (RTT) 都比较高，其中 (ASN1) 的重传率较高，(ASN2) 的重传率较低。从上图左边两幅 关于(throughput) 的 (CDF) 可知，在关于 (ASN1) 的 (CDF) 图中，(BBR) 的性能较好，而在关于 (ASN2) 的 (CDF) 图中，(CUBIC) 的性能较好。因此，可以发现，即便在 (RTT) 较高的环境中，(BBR)也只适用于 重传率较高的情况下，才能有较好的性能表现。
接下来作者想要评测在(ASN1)中 (BBR) 是否对于所有的连接都有吞吐量的提升。
从上图分析可知，(BBR) 算法也只有刚开始的时候，性能优于 $CUBIC $ 算法。
结果分析
作者认为原因还是归根于 (BBR) 的公平性问题上。
(CUBIC) 与 (BBR)
在一个高缓存的情况下，中间设备(路由器等)可能会存在排队的情况，而 (BBR) 的的估计的(RTT) 可能会增加。而 (CUBIC) 则是基于丢包来判断拥塞，因此会倾向于填满缓存，导致 (CUBIC)能够抢占更多的带宽，从而表现较好。而在一个浅缓存的情况下，缓存容易被填满，导致缓存溢出，从而容易丢包，(CUBIC) 算法会轻易去降低自己的拥塞窗口，因此 (BBR) 能够获得更多带宽。
(BBR) 与 (BBR)
当两个不同 (RTT) 的 流竞争共享带宽时，(RTT) 较高的流可能会估量得到更高的最小 (RTprop)，因此会获得更大的 (BDP)，从而占有更多的带宽份额。
在实验室中去复现结果
作者在虚拟机上搭建了测试平台环境，在边缘服务器上去模拟不同流量类别（Client、P2P、Intra-PoP）的方法。
作者重现了 (BBR) 在不同类别下的行为表现，在 (client-smallbw) 情况下 (BBR) 流完成的时间比 (CUBIC) 流所完成的时间更短；由于 (client) 环境为 较高延迟，丢包率较高，因此 (BBR) 性能表现更好。
所以在(CDN) 上进行 (BBR) 的任何部署都必须意识到它可能对混合流类型产生更广泛的影响。
结论
(BBR) 在 (poP-to-poP and intra-poP) 这种低重传率的环境下，会存在降低吞吐量的风险。但是在客户端表现良好，所以可以从 (wireless providers) 开始去启用 (BBR) 拥塞控制算法，因为无线环境中存在浅缓存和丢包率较高的情况，所以(BBR) 算法会很有优势。
首先CUBIC与BBR共存于共享链路，在瓶颈带宽被占满之后，CUBIC会继续发包填充队列，造成BBR被动排队。由于BBR的被动排队，所以rtt也会显著上升。但是这在短时间内不会影响BBR的发包，因为BBR的测量RTT的是10秒内的最小RTT。也就是说，只要BBR能够坚持10s不划走，CUBIC一旦丢包就会出现乘性减窗。BBR在回复到干净状态的同时也可以迅速占据空闲的带宽，从而达到压制CUBIC的效果。而相反在另一种情况，如果队列足够深，rtt足够长，足以让CUBIC填充10s还不满时，CUBIC丢包前BBR就退到4个包发送速度了，这反而说CUBIC压制了BBR。
所以这里可以顺理成章地得出结论结论是，浅队列时，CUBIC受BBR的影响比较小，深队列时，BBR会受到CUBIC的影响。
《When to use and not use BBR》
这一篇博客主要也是分析了 (BBR) 地公平性问题，同样认为 (BBR) 算法比较适用于浅缓存，重传率较高地情况下，不过作者对丢包率做了定量分析。
当丢包率超过20%的时候，(BBR)算法的吞吐量有一个断崖式的下跌，而右边的图说明了这个断崖点是与 (pacing\_gain)有密切关系的，所以作者认为(BBR) 的性能对参数是非常敏感的，可以使用参数的自动调整，以应对不同的网络环境。
