拥塞控制
本次演讲来自Demux-SF Video Technology July 2020，主讲者是Facebook的软件工程师Nitin Garg，介绍了怎样通过更好的拥塞控制进行更有效的传输，进而提高视频质量。
首先Nitin介绍了拥塞控制的重要性。在带宽有限的情况下，选择发送速率是很重要的。如果发送速率大于可用速率，就会出现丢包和延迟。相反如果发送速率远低于可用速率，观众同样无法获得好的视频质量体验，因为没有充分利用带宽。并且，发送速率的选择是一个很困难的问题，因为网络容量变幻莫测，难以估计。它取决于很多方面，比如连接的类型、一天中不同的时段和其他发送方及其流量类型。
拥塞控制一般分成发送数据包、等待、获取ACKs、调整发送速率四个阶段。拥塞控制算法会设置拥塞窗口cwnd，拥塞窗口被用来限制一次的飞行数据包数量。如上所述，拥塞控制算法中延迟和吞吐量之间是trade-off的关系。如果可用带宽大于下载速率，一切都将顺利进行。但如果下载速率大于可用带宽，多余的数据包将存储在路由器缓冲区中，这引入了额外的延迟。这种临时缓冲在一定情况下是好的，比如带宽有临时的波动，这些缓冲区会平滑数据输出，有利于播放应用达到最大吞吐量。然而对于端到端的一些应用例如视频电话，这种延迟的存在是糟糕的。
通过上述分析，他们得到以下两点启发：
1. 不同的视频体验要求不同的延迟和质量平衡。
2. 使用单一的拥塞控制算法来适配所有场景是否可行？若可行，就要使应用程序能灵活地设置吞吐量和延迟的平衡。
因此除了之前常被使用到的CUBIC和BBR，引入了新的拥塞控制算法COPA。COPA是一种基于延迟的算法，可以通过参数来控制对延迟的敏感度。
在讨论具体的拥塞控制算法前，Nitin介绍了QUIC，这也是他们完成后续算法测试的基础。Nitin认为QUIC有最大的优点是传输层在用户空间而不是内核中。在TCP条件下，对于拥塞控制算法的更改必须通过修改内核来完成，而QUIC的拥塞控制算法可插拔，使得新算法的测试开发容易了非常多。Nitin介绍了CUBIC、BBR和COPA三种算法的基本要点，并且通过Facebook的QUIC库mvfst进行了拥塞控制性能测试。
CUBIC算法相对旧一些，它被运用到Linux内核中已经很长一段时间了，是一种基于丢包的拥塞控制算法。CUBIC在慢启动阶段指数型增加cwnd，之后加性增加，一旦出现丢包就乘性降低。这种算法有两个主要缺点，一是会造成缓冲膨胀，增大延迟；二是不利于带宽的充分利用，因为一旦丢包，cwnd将“断崖式”降低，需要很长时间才能探测到最大值。
BBR是一个Google开发的、相对新的算法，已经被应用于YouTube、Chrome等应用中。BBR预测BtlBw和RTprop两个参数，目的是将发送速率收敛并维持在最优点附近，在最优点上飞行数据包数量等于BDP，发送速率等于BtlBw，RTT等于RTprop。这种特性导致BBR不允许应用维持在所占带宽相对保守的情况下，过于激进。
COPA是三者中最新的一个算法，由MIT的研究人员提出。COPA允许应用可以对吞吐量和延迟的平衡进行配置，参数delta越大，对于延迟越敏感（延迟越低，吞吐量也越低）。COPA使用competitive mode解决同样的激进问题，一旦探测到流量异常，就会进行调整使自身越来越不激进。
Nitin团队通过Facebook的QUIC库mvfst，对CUBIC、BBR和COPA进行了性能测试，同时配合使用ABR算法提高视频质量。他们使用移动端的Facebook live 应用作为测试平台，在全世界范围内进行实验。实验对Avg Goodput和Avg Application Observed RTT两个指标进行测试，前者是一段时间内成功发送的比特数，后者是应用发送至FB Live服务器的每帧数据的平均RTT。实验数据显示COPA的性能全面领先，得到以下两个结论：
1. 配合QUIC使用时，相比于CUBIC和BBR，COPA为移动直播提供了更高的质量和更低的延迟
2. 进一步的分析表明，COPA具有更低的传输RTT和更低的丢失/重传开销，这有可能推动了这些改进
Nitin表示，他们未来想要想要进行更多的延迟-质量平衡测试，例如在超低延迟场景中，和与GCC进行比较。另外上传面临相对轻的竞争，下载时用户的行为更复杂，因此也需要设计进行测试。
最后附上演讲视频：