Facebook：对比COPA 与CUBIC，BBR v1在拥塞控制及视频质量的表现

 

Facebook的测试结果显示，COPA较于经常使用算法CUBIC及BBR v1存在必定优点，来看看具体表现。

文 / Nitin Garg

译 / Adrian Ng

原文 https://engineering.fb.com/video-engineering/copa/

在对互联网应用进行性能优化时，可能会涉及一些复杂的权衡。在传输大量数据的时候，若是传输速度过快，可能会由于丢包而产生重传，从而随着时间流逝致使性能损失。同时，若是发送数据的速度太慢则可能会致使延迟和卡顿，对性能也有很大的损害。此外，不一样的视频体验须要针对质量与延迟进行不一样的权衡。对于交互式体验，其应用程序可经过下降视频质量，避免卡顿。但当视频的高质量是最重要的因素时，应用程序能够在合理的范围内的保持必定延迟。此时，应用一般会在几种不一样的拥塞控制算法中进行选择，找到最适合当前目标的优化算法进行优化。

尽管在拥塞控制领域上咱们已进行了普遍的研究，但若要将研究付诸实践一直以来都会涉及到修改Linux内核。使用QUIC能够在无需修改内核的状况下，在用户空间中实现整个传输堆栈，简化整个部署和实验的流程。而COPA 与 QUIC 的耦合能够为咱们提供一种算法，该算法可适用于各类视频体验，而且能够合理地遵循一种部署策略。在实际测试中，测试结果显示COPA较于经常使用算法CUBIC及BBR v1存在必定优点。本文将详细介绍为此所作的实验工做以及从大规模评估COPA中得到的经验。

 

COPA测试：基于延迟的拥塞控制

通过对COPA的实施和评估， COPA(美国MIT理工学院所设计的基于延迟的可调拥塞控制算法) 基于一个客观函数，因此吞吐量和延迟的权衡能够经过用户指定的参数parameter，delta进行配置。若是增量值较高，COPA对延迟就越敏感，使得输出下降。反应效果的增量值减小将提供高质量的输出并下降延迟。

 

在此实验中，咱们选择了Android平台上的Facebook Live。经过Facebook Live, 用户能够作线上直播streaming，推广给朋友而且获取更多粉丝. 根据咱们的设置，首先须要一个手机摄像头生成视频，再用自适应bitrate算法测量输出, 并调整编码bitrate。接着，咱们将使用QUIC把视频传送到FB服务器，从新在服务器内发出新的码流播放给观众。

在第一个测试里，咱们实现了无竞争模式（采用固定delta）的COPA。采用0.04的增量值才得以以达到如下结果，并在其中发现这些结构做为应用程序能够提供更合理的质量与延迟权衡，因此将CUBIC和BBR v1拥塞控制算法放在一块儿进行比较。CUBIC比较常见，也是LINUX的默认拥塞控制算法。此应用模式是增长CWND一直到数据包丢失，再经过乘法式减小CWND。但这种模式也会带来一些问题，例如缓冲膨胀buffer bloat及jagged锯齿状的传输模式会致使延迟。最近Google开发的新算法BBR，利用的则是bottleneck带宽和RTT构建网络路径模型，调整发送速率，以实现带宽和延迟之间的最佳平衡点。COPA、CUBIC 和 BBR的实做方案均可以在咱们的 QUIC 方法中找到。

测试结果

咱们经过A/B 测试来衡量全球 Facebook 实时视频的性能，其中大多数在线会话来自美国、墨西哥、印度、印度尼西亚、越南和泰国。在这次实验中，咱们聚焦于每一个视频的应用指标：

1. 平均高质量的输出: 在广播期间，发送的应用程序字节总数除以持续时间。请注意，Facebook Live 会话时间一般比较长（从几十秒到几分钟），因此应用程序会根据高质量输出和队列大小更改比特率。若是有更好高质量输出，反应出来的传送质量也会提高。重传发生期间，数据字节不会提升输出质量，缘由是由于它们不表明任何新的应用程序字节-天然而然地也减小了goodput.
2. 平均应用程序RTT测试: 这是Live摄入延迟的prox服务器。每一秒，应用程序会向服务器发送一个小的虚拟负载并等待确认。咱们测量了此往返时间（RTT），并采用会话时间的平均值来计算平均应用 RTT。若是bitrate相同或比例更高，那表示较低的应用 RTT 会显示较低的视频引入延迟。

 

依据测试结果，咱们使用RTT 测量发现 COPA 的视频延迟平均率比 CUBIC 低。对于网络良好且低延迟率的session，BBR能够减小更多幅度。P50 应用 RTT 从 499 ms 的 CUBIC 降低到 479 ms 的 COPA 和 462 ms 的 BBR，COPA 减小了 4%， BBR 减小了 8%。

 

所以，对于网络较差且延迟率较高的直播，COPA能够克服减小更多的幅度。 P90 App RTT 从 CUBIC 的 5.4 秒降至 COPA 的 3.9 秒，COPA 减小了 27%，而 BBR 的缩减开始减小。

 

在实际场景中，咱们能够经过调整视频质量来下降延迟。举个例子，若是下降视频bitrate，下降视频质量，每当发生网络拥塞时，视频延迟也会相应下降。若是分别把三组数据都拿来作比较，咱们会发现COPA和BBR提供的质量输出要比CUBIC好。这样的结果反而显得COPA 和 BBR不只减小了延迟，还能够提供更高质量的视频。若是咱们遵循延迟改进的模式，能够发现COPA 相比 BBR 有明显的优点。BBR 将 P10 改进了 4.8%，而 COPA 提升了 6.2%。BBR 将 P50 良件提升了 5.5%，而 COPA 提升了 16.3%。

 

咱们必须留意的是，在P90 以上的增益彷佛会减小，这是因为这个实验的编码器bitrate设限为 3 Mbps。在具体实验中，咱们专一于测量 QUIC 运输的 RTT 和转播overhead。传输 RTT 和应用 RTT 有很大的差别，前者是经过网络发送数据包后测量往返时间，后者是在数据包离开应用层后测量数据包。应用程序 RTT 存在隐藏的重传，即便在packet loss的状况下，它也会在传输层产生屡次的往返运输。

RTT平均传输数据

随着RTT应用模式，BBR为咱们提供了最低的传输 RTT能量，以得到最佳链接（P25 及如下）。可是结果显而易见，平均率幅度的减小并不大，由于对于这些用户来讲RTT已经处在一个很低的平均率了。

 

当你留意P75 及更高时， COPA在此很明显提供了最低值。BBR 将 P75 RTT 下降了 10%，而 COPA 将其下降了 35%。与之相比，P95 的下降幅度更大，BBR 将其下降了 16%，而 COPA 将其下降的幅度高达 45%。

 

若是存在较低的传输 RTT，也许能够断定视频延迟降低的缘由。值得注意的是，视频延迟（RTT应用程序）还取决于应用程序基于 ABR 发送的数据量，这会影响传输发送缓冲区中的数据量。所以，这使 ABR 可以产生更好质量，从而抵消了较低传输 RTT 减小的延迟。另外一方面，传输 RTT 的变化仅取决于数据包离开传输后基础网络中排队的数据量。

RTX Overhead开销

为进一步了解传输行为，咱们查看了丢失和传输的数据量。该指标的确切定义是：

RTX Overhead = Total bytes retransmitted bytransport / Total bytes ACKed

咱们发现，与CUBIC相比BBR 对于全部用户的整体开销较低，对于90%的用户来说约为CUBIC的一半左右。COPA和CUBIC相比， COPA 负担了大约 75% 用户四分之一的开销，到最后开始攀升并最终达到CUBIC 的4-5倍左右。

 

COPA 不将packet loss视为拥塞信号; 当它发现队列延迟增长时，会主动下降CWND。随着bottleneck队列的填满，COPA 所进行的延迟测量将会增长，咱们就能够在流量损失产生前发现存在拥塞。所以在理想状况下，咱们应该始终能够看到COPA有较低的数据包流失。实际上，这是大约90%的用户所看到的，而最后 10% 的用户则看到更多的损失。这表示丢失率和排队延迟与这部分用户没有关联性。

网络流量监管

网络流量监管表示某一来源的流量被隔离并限制以特定速率节流。。一般状况下，提供者将会丢弃超过该速率的全部额外数据包。而且会产生一些明显特征，使其与拥塞形成的损失区分开来：

• 一致的吞吐量
• 高损失
• 更低的RTT 和队列延迟

尽管与CUBIC和BBR相比，COPA的尾端重传开销很大，但尾端RTT开销比较少，这与流量监管的一些特色相符。为了正视这一点，第一步，咱们按照ASN 对结果进行分解，由于一般状况下，流量监管会由于ASN 的提供对象不一样存在很大差别。通过测试，咱们发现某些 ASN（在某一项独立分析中发现了流量监管的迹象）对于 COPA 的 RTX 开销也高得多。为了证明此理论，咱们绘制了图表展现 RTT、队列延迟和 RTX 开销之间的关联性。

 

 

在图中的前半部分，咱们看到对于 COPA，RTT 和队列延迟会随着 RTX 开销的增长而提高。这表示在当前区域，损失确实是因为拥塞形成的，同时伴随着排队延迟的增长。但在达到最大值后，RTT 和队列延迟在图表的后半部分开始降低。RTX开销最高的区域中的用户实际上看到的延迟很是低。这就证明了咱们的结论，即高损失多是由于网络限制的缘由。不过，短缓冲区也有多是其中一部分缘由，但网络特征和解决方案很是类似。对于CUBIC来讲，RTT 和队列延迟随着 RTX 开销的增长而增长。这代表全部用户的损失都是因为拥塞形成的，由于 CUBIC 将损失视为拥塞信号，并相应地减小了 CWND。

将来计划

COPA的潜力是毋庸置疑的。目标函数运行良好，控制排队延迟与吞吐量权衡的拨号很是有吸引力。咱们的测试是基于极端条件状况进行的，即在很是低的delta值下优化吞吐量。虽然它仅仅是针对吞吐量进行优化，但与 BBR 和 CUBIC 相比，仍然大大减小了排队延迟。值得注意的是，在咱们的 QUIC 实现和传输控制协议（TCP） 版本中，BBR 正在进行一些变化和改进，所以这种比较在未来可能会显示出不一样的结果。后续，咱们将开始测试另外一个极端状况， 即产品对极低延迟有要求时。这项实验会使咱们更接近于拥有一个可以知足不一样应用需求的单一可调拥塞控制算法。普遍的部署还须要更好地了解COPA对竞争流程的影响及其对于TCP的友好性。在测试中，咱们没法捕捉到这方面的重要信号。所以，这仍然是将来工做很重要的一部分，高RTX cases还存在许多改进的余地。目前有几种方法来更好的解决这些问题：COPA文件建议实施一种竞争模式，在这种模式中，增量值根据竞争的流动和损失动态变化。另一种选择是实施启发式方法，即根据损失来减小CWDN。但此方法存在必定风险，有可能会使COPA对于拥塞无关的随机损失作出反应，并侵蚀一些吞吐量。此外，与 BBR v1相似，还有一种方法就是能够为网络策略实施显示检测。