瓶颈带宽和往返传播时间(BBR)是一种TCP拥塞控制算法，由于其提供更高吞吐量的能力，许多内容提供商都报告了这种算法，因此受到了市场的广泛关注。 在这篇文章中，我们在Verizon Media (现为Edgio)的内容交付网络(CDN)工作负载的上下文中评估了BBR (版本1)，该工作负载可提供大量(多Tbps)的软件更新和流视频，并量化对流量的好处和影响。 我们希望在大型CDN上进行此类评估将有助于其他内容提供商为其流量选择正确的拥塞控制协议。
背景
许多内容提供商和学术研究人员发现，BBR提供的吞吐量比其他协议(如tcp-cubic)更大。 不同于基于损耗的拥塞控制算法,如无处不在的TCP-cubic ,BBR有一个不同的操作范式:它会根据会话迄今为止看到的最小RTT持续更新正在运行的数据量,以避免缓冲膨胀。 有关BBR操作的更多信息,请点击此处查看Google的原始出版物。
测量和分析
为了了解BBR在我们的CDN中的潜力，我们在多个阶段评估了BBR，测量了从几个入网点(POPS)对TCP流的影响。 POPS表示位于大都市区域的缓存服务器集中。 最初，我们在流行音乐中进行了一项小规模的BBR测试，并进行了一项完整的流行音乐测试，所有流向运行BBR的客户。 为了确定客户将体验到的好处，我们在测试期间测量了内部代理Web服务器日志的吞吐量以及套接字级别分析。
要评估的指标
我们的多租户CDN可看到各种客户端流量。 许多客户拥有大量的小对象，而其他客户则拥有大得多的多GB对象。 因此，确定能够捕获不同流量模式的实际性能增益的成功指标至关重要。 特别是，在本次评估中，我们将吞吐量和TCP流完成时间确定为成功参数。 在图1中，我们显示了从CDN请求的常见对象大小与服务时间的热图。 颜色渐变表示每个类别中的请求数。 这些是一小部分服务器的代表性数字，足以捕获常见行为。
图1. 显示常见对象大小的热图。
热图让我们了解不同的请求模式。 一般来说，获得更高的吞吐量是性能提升的最佳指标。 但是，作为测量值，吞吐量可能会非常嘈杂，尤其是在对象尺寸较小(少于几MB)的情况下。 因此，根据对哪种大小提供了最可靠的吞吐量评估的单独评估，我们仅使用大于3MB的对象大小进行吞吐量评估。 对于小于3MB的对象，跟踪流完成时间是更好的度量。
作为评估的第一步，我们在洛杉矶的几台服务器上启用了BBR，并监控了所有TCP流的吞吐量和流完成时间。 以下结果分析了几个因特网服务提供商的具体案例研究。
大型无线提供商
图2显示了打开BBR后的差异。
图2. 与立方流量(控制)相比，打开BBR (测试)时大型无线提供商客户端的吞吐量影响。 左侧：两天内的吞吐量测量。 蓝色垂直线表示何时激活BBR。 在这里，我们看到BBR的总体改善约为6-8%。 右：吞吐量的第5百分位数的CDF。 BBR流程显示出显著改善。
对于这家无线提供商，我们一旦启用BBR，平均而言，吞吐量提高了6-8%。 我们也看到TCP流的整体完成时间也更短。 这一发现与Spotify，Dropbox和YouTube的其他报告是一致的，在这些报告中，吞吐量明显增加，在数据包丢失常见的无线网络中，这不一定是拥塞的指标。
大型有线提供商
接下来，我们检查了大型有线提供商的性能。 在这里，我们还看到了使用BBR的吞吐量(对于大型对象)和流完成时间(如图3所示)的改进。
图3. 大型有线提供商完成流程所需的平均时间。 BBR (测试)流显示的抖动更小，完成数据传输所需的时间更短。 这些优点对于较大的对象更具影响力。 但是，我们发现立方体和BBR的大文件大小会出现类似的抖动。
这些测试报告的增益显示客户端流量非常有希望的结果。
由于这些收益是从综合的角度来看的,我们决定深入探究一下,以检查流行音乐中的所有TCP流是否都看到使用BBR的好处;或者,某些TCP流是否受损,以及哪些受损?
在CDN边缘，我们执行四种不同类型的TCP会话：
- 弹出到客户端(如上所示)
- Pop-to-pop (数据中心之间)
- Pop内部通信(在同一Pop的缓存之间)
- 弹出到源站(弹出到客户源站数据中心)
在这项研究中，我们考虑了Pop-to-Client，Pop-pop和Pop-intra-pop流，因为边缘到源站的流量不如其他三种流量高。
Pop到Pop和Pop内部流量
评估对这些TCP流的影响也很重要，因为在许多情况下，这些流是客户端交付(例如动态内容)的拦截器。
对于Pop到Pop和Pop内部流量吞吐量，我们发现性能有很大的回归。 图4显示了同一时间段内流行和流行到流行通信的影响：
图4. 与立方流量(控制)相比，打开BBR (测试)时，POP内部和POP到POP流量的吞吐量影响。 两天内的吞吐量测量。 蓝色垂直线表示何时激活BBR。 使用BBR时，吞吐量减少了大约一半。
之前的调查结果中没有报告流向最终用户的流量和数据中心之间的明显性能差异。 我们需要评估这些特定TCP流为何受到影响；如果这是CDN上的硬件或配置造成的结果；如果是，需要更改哪些调整。
通过使用Web服务器访问日志和服务器端套接字数据进行的进一步调查,发现在RTT流的高和低RTT流的存在下,具有非常低RTT流的TCP流似乎会因使用BBR而受损。 我们进一步评估了数据传输量小于0.5KB的病例，发现在大多数病例中，BBR的表现与立方体相似。
基于这些发现，我们得出结论认为，对于我们的流量模式，在RTT和损耗较低的流行音乐和流行音乐之间的通信中，最好使用Cubic。 对于客户端通信，使用BBR是值得的。
完整的POP测试
为了大规模评估BBR的性能优势，我们在里约热内卢的一个POP对来自该POP的网络的所有面向客户端的流量进行了全面POP测试。 该流行音乐进行了一个有趣的案例研究，因为该地区的位置和对等约束导致客户体验的RTT中位数高于其他地区。
图5. 使用BBR提高客户端的吞吐量，因为这显示高重传输(ASN1)。
我们部署了拥塞控制算法中的更改并监控了性能。 图中显示了使用BBR对Rio前两个ASE (自治系统)观察到的吞吐量的CDF。 如图5所示，总体而言，一个AS看到了BBR的益处，而另一个则没有。
为了调查其背后的原因，我们使用ss实用程序查找测试期间收集的其他TCP度量。 这两个ASE之间的重新传输速率有明显的区别。 即使对于RTT较高的ASE，BBR也只能在重传次数较高的情况下表现良好，换句话说，对于损耗较少的ASE，Cubic没有理由回退，性能优于BBR。 但是,需要注意的是,TCP立方的许多参数已经在我们的CDN上经过了精心调整。
接下来，我们研究了图5所示ASN1的所有连接是否都显示出吞吐量的改善。 图6是不同对象大小的BBR和立方连接所花费的时间图(较低意味着更好的吞吐量)。 在这里,我们看到,BBR只开始显示出较大物体的显著优势,以MBs的顺序。 我们确实看到一个使用BBR的异常实例，但无法将其归因于任何特定的拥塞控制协议相关问题。
图6. 对于显示改进的ASE，BBR的好处在于具有大文件的长时间运行流程。
为什么会发生这种情况？
这些结果有两个维度–立方与BBR和BBR与BBR。
立方体与BBR
BBR在估算瓶颈带宽时对缓冲区大小和RTT具有高度反应性。 对于大型缓冲区，中间框可能会形成队列，BBR的估计RTT会增加。 由于不会丢失数据包，Cubic在这种情况下不会退回，换句话说，即是流行到流行风格的流量，因此Cubic可以实现更高的吞吐量。 在小型缓冲区(如无线客户端)中，缓冲区会迅速填充并导致损失–从而使立方流回落，BBR流性能更好。
BBR与BBR
在这种情况下，当有损失时，没有流量退回。 但是，当两个具有不同RTT的流竞争带宽份额时，具有较高RTT的流也具有较大的最小RTT，因此具有较高的带宽延迟乘积。 因此，该流以比RTT较低的流更快的速度增加其飞行数据。 这会导致带宽按RTT降序重新分配给流，而RTT较高的流填充缓冲区的速度快于RTT较小的流。
在实验室设置中重现结果
为了进一步了解流之间的交互作用，我们在虚拟机中创建了一个测试平台环境，捕获我们在生产中看到的行为。 我们确定了在边缘服务器上模拟不同流量类别的方法，如下所示：
客户端流量延迟设置为~50ms，损失范围为0.001至0.1，瓶颈带宽为50Mbps。 同样，对于仅流行到流行的损耗和延迟，设定为~15毫秒，0.0001~0.01。 对于POP内流量，我们允许虚拟机最大限度地利用可用容量。 最后，使用各种对象大小运行模拟，以捕获流量的多租户性质。 我们将所有三种流量模式与流的指数到达并行运行，以捕获毒性流到达分布。 图7显示了测试台的设置。
此测试的目标是重现我们在生产测试中看到的问题，特别是流行内流量和流行对流行流量的小型RTT流量的吞吐量下降。
图7. 使用KVM，iperf，netem和tc实用程序进行实验设置。
使用此设置，我们使用仿真后台流量(立方和BBR)运行了数百次仿真，并测量了完成流程所需的时间。 后台流量的目标是模拟类似生产的环境。 许多现有的研究侧重于运行几个立方和BBR流,并评估他们的行为。 虽然在这些情况下，了解每流行为很有用，但它很难代表大容量CDN的复杂性。 我们使用客户端流完成时间作为可靠的指标，因为对于小文件大小，吞吐量可能会很嘈杂。
图8. iperf流所需的时间。 左：客户端流。 右侧：弹出式到弹出式流动。 对象大小：3MB。 BBR在模拟客户端流方面的表现优于立方。
我们看到样式也重新出现在我们的测试台中。 在图8中，我们显示了BBR和立方iperf流在两种情况下所花费的时间的CDF：3MB (中等大小)文件的客户端流量和弹出流量。 在低损耗高带宽设置中，BBR流无法赶上立方。 客户端流量(低带宽)有所改善，即BBR流所花费的时间较少。 但是，对小文件的改进是微不足道的。 在测试环境中再现这些行为使我们确信它们是不同流类型之间相互作用的结果。 因此，在CDN上部署任何BBR都必须意识到它可能会对各种流类型产生更广泛的影响。
结论
从我们的评估中，我们观察到BBR流并非在所有情形下都能表现良好。 具体而言，当使用BBR时，数据中心/入网点(POP)内的流量和数据中心(POP到POP)之间的流量都会受到影响。 在某些极端情况下，吞吐量会减少一半。 但是，我们发现弹出到客户端的流量吞吐量提高了6-8%。
在这篇文章中，我们概述了在CDN上下文中对BBR (版本1)的评估。 我们首先在一个POP中对几台服务器进行了小型测试,并评估了我们作为一家大型内容提供商所感兴趣的不同变量。 在大规模的全面流行测试中，我们注意到BBR对重传率较高的ASE的帮助最大，因此建议对大型文件使用BBR是值得的。
我们从这里走向何处？
如果我们在系统级别(所有流量)启用BBR，我们就会面临流行音乐内部和流行音乐到流行音乐的流量遭受吞吐量下降的风险。
但是，BBR在客户端通信方面表现出了潜力，并且性能良好。 这确实促使我们有选择地为客户启用BBR，可能从无线提供商开始。 此外，这些路径具有浅缓冲区和无线丢失，这是BBR比其他立方流性能更好的理想情况。
我们希望这一大纲能让我们清楚地了解大型内容提供商对BBR的使用及其对可能存在瓶颈的不同类型流量的影响。 BBRv2的ALPHA版本现已推出，应该可以解决其中的一些问题。 我们计划继续评估较新版本的BBR，并使用智能交通控制器，为正确的流量类型选择正确的拥塞控制。 我们将在将来与大家分享更多的细节。
感谢组织内各个团队的贡献，使这一分析成为可能！
