Home 技术文章 大型CDN上的BBR评估
Applications

About The Author

Outline

瓶颈带宽和往返传播时间(BBR)是一种TCP拥塞控制算法,由于能够提供许多内容提供商所报告的更高吞吐量,因此受到了市场的高度关注。 在这篇文章中,我们在Verizon Media (现在是Edgio)的内容交付网络(CDN)工作负载的背景下评估BBR (版本1),该工作负载提供大量(多Tbps)的软件更新和流视频,并量化对流量的好处和影响。 我们希望在大型CDN上进行这样的评估将有助于其他内容提供商为其流量选择正确的拥塞控制协议。

背景

许多内容提供商和学术研究人员发现BBR比其他协议(如TCP立方协议)提供更大的吞吐量。 与基于丢失的拥塞控制算法(如无处不在的TCP立方)不同,BBR具有不同的操作模式:它根据会话到目前为止看到的最小RTT不断更新可以传输的数据量,以避免bufferbloat。 有关BBR操作的更多信息,请查看Google的原始出版物 此处

测量和分析

为了了解我们的CDN上BBR的潜力,我们在多个阶段评估了BBR,测量了几个存在点(PoPS)对TCP流的影响。 POPS代表位于大型城域区域的缓存服务器集中。 最初,我们在一个Pop上进行了一个小规模的BBR测试,还进行了一个完整的Pop测试,所有流都流向运行BBR的客户端。 为了确定客户将会体验到的好处,我们在测试期间从内部代理Web服务器日志以及套接字级别分析中测量了吞吐量。

要评估的指标

我们的多租户CDN可以看到各种客户端流量。 许多客户拥有大量小对象,而其他客户则拥有更大的万兆字节对象。 因此,确定成功指标以捕获不同流量模式中的实际性能增益至关重要。 特别是在本次评估中,我们将吞吐量和TCP流完成时间确定为成功参数。 在图1中,我们显示了从CDN请求的常见对象大小与提供这些对象所需时间的热图。 颜色梯度表示每个类别中的请求数。 这些是来自一小组服务器的代表性数字,足以仅捕获常见行为。

1 显示常见物体大小的热图。

热图让我们了解不同的请求模式。 通常,获得更高的吞吐量是性能增益的最佳指标。 但是,作为测量值,通量可能非常嘈杂,尤其是在物体尺寸较小(小于几MB)的情况下。 因此,根据对其大小提供最可靠的吞吐量评估的单独评估,我们仅使用大于3MB的对象大小进行吞吐量评估。 对于小于3MB的对象,跟踪流完成时间是更好的度量。

作为评估的第一步,我们在洛杉矶的一家Pop公司的几台服务器上启用了BBR,并监视了所有TCP流的吞吐量和流完成时间。 以下结果分析了一些互联网服务提供商的具体案例研究。

大型无线提供商

图2显示了打开BBR后的差异。

2 与立方流量(控制)相比,打开(测试) BBR时对大型无线提供商客户端的吞吐量产生影响。 左侧:两天内的吞吐量测量。 垂直蓝线表示BBR何时激活。 在这里,我们看到BBR的总体改善约为6%-8。 右:第5百分位数的CDF吞吐量。 BBR流显示出显著改善。

对于这家无线提供商,我们启用BBR后,平均吞吐量提高了6%-8。 我们也看到TCP流完成时间总体较短。 这一发现与Spotify,Dropbox和YouTube的其他报告一致,在这些报告中,数据包丢失很常见的无线网络中吞吐量明显增加,但这并不一定是拥塞的指标。

大型有线提供商

接下来,我们检查了一家大型有线提供商的性能。 在这里我们也看到了吞吐量(对于大型对象)和流完成时间(如图3所示)。 使用BBR的改进。

3 大型有线提供商完成流程所需的平均时间。 BBR (测试)流显示更低的抖动和完成数据传输所需的时间。 对于较大的物体,其优势更具影响力。 但是,对于立方和BBR的大文件大小,我们确实会看到类似的抖动。

从这些测试中报告的增益对客户端流量显示出非常有希望的结果。

由于这些增益是在汇总视图上实现的,因此我们决定深入研究一下,以检查Pop上的所有TCP流是否都看到了使用BBR的好处;或者某些TCP流是否受到影响,以及哪些?

在CDN边缘,我们执行四种不同类型的TCP会话:

  • 弹出到客户端(如上所示)
  • 弹出到弹出(数据中心之间)
  • Pop内部通信(同一Pop的缓存之间)
  • 弹出到源服务器(弹出到客户源服务器数据中心)

在这项研究中,我们考虑了弹出到客户端,弹出和弹出内流,因为边缘到源并不像其他三种流那么大。

Pop到Pop和Intra-Pop流量

评估对这些TCP流的影响也很重要,因为在许多情况下,这些流是阻止客户端交付(如动态内容)的因素。

对于Pop到Pop和Pop内的流量吞吐量,我们看到性能大幅下降。 图4显示了在同一时间段内对Pop内部和Pop到Pop流量的影响:

4 与立方流量(控制)相比,打开BBR (测试)时,对Pop内部和Pop到Pop流量的吞吐量影响。 两天内的吞吐量测量。 垂直蓝线表示BBR何时激活。 使用BBR时,吞吐量减少了约一半。

在以前的调查结果中,没有报告到最终用户的流和数据中心之间的这些明显的性能差异。 我们需要评估为什么这些特定TCP流会受到影响;如果这是我们CDN上硬件或配置的产物;如果是,则需要更改哪些调整。

从使用Web服务器访问日志的进一步调查和对服务器端套接字数据的评估来看,在存在高和低RTT流的情况下,具有非常低RTT的TCP流因使用BBR而受到影响。 我们进一步评估了传输的数据少于0.5KB的病例,发现在大多数病例中,BBR的表现与CUBIL相似。

根据这些调查结果,我们得出结论,对于我们的流量模式,最好在RTTs和损耗较低的Pop内部和Pop到Pop通信中使用CUBAL。 对于客户端流量,使用BBR是值得的。

完全弹出测试

为了大规模评估BBR的性能优势,我们在里约热内卢的一家POP上对来自我们的网络的所有面向客户端的流量进行了全面的POP测试。 这一流行趋势是一个有趣的案例研究,因为该地区的位置和对等制约因素导致客户体验的中位RTT高于其他地区。

5 对客户端使用BBR提高吞吐量,因为它显示了高重传率(ASN1)。

我们部署了拥塞控制算法的更改并监控了性能。 图中显示了在Rio使用BBR与CUBAR对前两个ASE(自治系统)观察到的吞吐量CDF。 如图5所示,一个整体认为BBR的益处,而另一个则没有。

为了调查其背后的原因,我们使用ss实用程序查找了测试期间收集的其他TCP指标。 这两种ASE之间的重新传输速率有明显的区别。 即使对于具有较高RTTs的ASE,BBR也只能在具有较高重传次数的情况下表现良好,换言之,对于损失立方较少的ASE,没有理由回退,性能优于BBR。 但是,需要注意的是,TCP Cubic的许多参数已在我们的CDN上仔细调整。

接下来,我们调查了图5中所示的来自ASN1的所有连接是否都显示了吞吐量的提高。 图6是不同对象大小的BBR和立方连接所用时间(越低意味着吞吐量越高)的图。 在这里,我们看到BBR只是开始显示出较大的对象的明显的好处,在MBs的顺序。 我们确实看到一个使用BBR的异常实例,但无法将其归因于任何特定的拥塞控制协议相关问题。

图6 对于表现出改进的分析系统,BBR的优势在于具有大型文件的长期运行流。

为什么会发生这种情况?

这些结果有两个维度–立方与BBR和BBR与BBR。

立方与BBR

BBR在估计瓶颈带宽时对缓冲区大小和RTT有高度反应。 在缓冲区较大的情况下,中间人可能会聚集一个队列,BBR的估计RTT会增加。 由于不存在数据包丢失,Cubic在这种情况下不会恢复,换言之,是弹出式通信,因此Cubic实现了更高的吞吐量。 在小型缓冲区(如无线客户端)的情况下,缓冲区会快速填充并导致损失,从而使立方流回退,BBR流性能更好。

BBR与BBR

在这种情况下,当出现损失时,不会有流量回流。 但是,当两个具有不同RTTs的流竞争带宽共享时,具有较高RTT的流也具有较大的最小RTT,因此具有较高的带宽延迟乘积。 因此,该流以比RTT较低的流快得多的速度增加其飞行中数据。 这会导致以RTTs的降序重新分配带宽,而RTTs较高的流量比RTTs较小的流量更快地填充缓冲区。

在实验室环境中再现结果

为了进一步了解流之间的交互,我们在虚拟机中创建了一个测试环境,以捕获我们在生产中看到的行为。 我们确定了在边缘服务器上模拟不同流量类别的方法,如下所示:

客户端流量延迟设置为~50ms,损失范围为0.001至0.1,瓶颈带宽为50Mbps。 同样,对于弹出到弹出,仅损失和延迟设定为~15ms,0.0001至0.01。 对于Pop内部流量,我们允许虚拟机最大程度地利用可用容量。 最后,使用各种对象大小运行模拟,以捕获流量的多租户性质。 我们将所有三种流量模式与流量的指数级到达并行运行,以捕获中毒式流量到达分布。 图7显示了测试台设置。

此测试的目标是重现我们在生产测试中看到的问题,特别是针对流行流量和流行到流行的小RTT流的吞吐量下降。

图7 使用KVM,iperf,netem和tc实用程序进行实验室设置。

使用此设置,我们使用模拟的后台流量(立方流量和BBR流量)以及完成流程所需的测量时间运行了数百次模拟。 后台流量的目标是模拟类似生产的环境。 许多现有研究侧重于运行几个立方和BBR流并评估其行为。 在这些情况下,了解每个流的行为非常有用,但它不能很好地代表大型,高容量CDN的复杂性。 我们使用客户端流完成时间作为可靠的指标,因为对于小文件大小,吞吐量可能会产生噪音。

8 iperf流所需的时间。 左侧:客户端流。 右:弹出到弹出流。 对象大小:3MB。 对于模拟的客户端流,BBR的性能优于CUBAL。

我们也看到了模式在我们的测试台上再次出现。 在图8中,我们显示了BBR和立方iperf流在两种情况下所用时间的CDF:客户端流量和3MB (中等大小)文件的弹出到弹出流量。 在低损耗高带宽设置中,BBR流无法赶上立方。 客户端流量(低带宽)有所改善,即BBR流所用的时间更短。 但是,对小文件的改进很小。 在测试环境中重现这些行为使我们确信它们是不同流动类型之间相互作用的结果。 因此,在CDN上部署BBR时,必须意识到它可能对流类型混合产生的更广泛影响。

结论

从我们的评估中,我们观察到BBR流在所有情况下都不能很好地运行。 具体而言,使用BBR时,数据中心/入网点(PoP)内的流量和数据中心之间的流量(Pop到Pop)会受到影响。 在某些极端情况下,吞吐量会减少一半。 但是,我们确实看到了-8弹出到客户端的流量吞吐量提高了6%。

在这篇文章中,我们概述了在我们的CDN背景下对BBR (版本1)的评估。 我们首先对单个POP中的几台服务器进行了一个小测试,并评估了我们作为一个大型内容提供商感兴趣的不同变量。 在一个大规模的全流行测试中,我们注意到BBR在重传率高的ASes的情况下会帮助大多数人,并建议使用BBR来处理大文件是值得的。

我们从这里往哪里去呢?

如果我们在系统级别(所有流量)启用BBR,我们就会面临POP内和Pop到Pop流量吞吐量下降的风险。

但是,BBR已显示出潜力,并且在客户端流量方面表现良好。 这确实促使我们有选择地为客户端启用BBR,可能从无线提供商开始。 此外,这些路径具有浅缓冲区和无线损耗,这是BBR比其他立方流性能更好的理想情况。

我们希望本概要对大型内容提供商使用BBR及其对可能存在瓶颈的不同类型流量的影响有所澄清。 BBRv2的alpha版本现已发布,该版本将解决其中的一些问题。 我们计划继续评估较新版本的BBR,并使用智能传输控制器,该控制器可为正确类型的流量选择正确的拥塞控制。 我们将在未来分享更多关于这方面的详细信息。

感谢组织内各个团队的贡献,使此分析成为可能!