GCC ：Google 的 WebRTC 的拥塞控制算法

需要在 Internet 对等点之间进行实时通信 (RTC) 的应用程序不断增加。  RTC 不仅需要拥塞控制，还需要最小化排队延迟以提供交互性。众所周知，成熟的传输控制协议拥塞控制不适合 RTC，因为它的重传和按序传递机制会导致显着的延迟。在本文中，我们提出了一种新的 RTC 拥塞控制算法，该算法基于估计的主要思想——使用一个 Kalman 滤波器，从发送方到目的地的数据包所经历的端到端单向延迟变化。该估计值与动态阈值进行比较，并驱动位于接收器的控制器进行动态调整，其目的是保持较低的排队延迟，而位于发送端的，基于丢失 los 的控制器在检测到丢失时采取相应的行动。提出的拥塞控制算法已经应用于 Google chrome。广泛的实验结果表明，该算法考虑排队延迟，同时提供协议内和协议间公平性以及完整的链路利用率。

根据最新的调查研究，视频占据当今网络请求的绝大多数。尽管视频流是这种增长的主要驱动力，但用于建立端到端实时通信 (RTC) 的音频/视频流的应用程序也越来越受欢迎。这主要是由于手持设备的日益普及，比如说手机，手提电脑，这些设备拍摄，编码然后通过移动网络推送实时的视频流。除了传统的视频会议和远程呈现系统之外，新的移动应用程序，如 Periscope、Meerkat 或 Facebook live，允许智能手机捕获的视频实时流式传输。

尽管互联网在其上层发生了重大变化，并且被用作大规模传输视频的平台，但大部分互联网流量仍然主要通过传输控制协议 (TCP) 传输。事实上，TCP 基于丢包策略的拥塞控制方法被证明适用于弹性数据传输（网页浏览、文件传输）和具有弱实时特性的流量，例如由当今通过 HTTP/TCP 传输视频的视频流系统产生的流量。然而，众所周知，TCP 不适合传送具有硬实时约束的流量（延迟敏感流量），例如由视频会议应用程序生成的流量。事实上，与本质上要求最小化流程完成时间的批量数据交付相比 [3]、[4]，实时多媒体应用的体验质量 (QoE) 不仅受吞吐量的影响，还必须保持尽可能低的连接延迟。据我们所知，除了 VoIP 流量 [6]、[7] 之外，通过 TCP 传输实时视频内容——这确实需要更高的数据速率——从未在文献中得到解决，也从未得到证实，从未在实际应用中取得成功。因此，尽管进行了多项标准化工作——最值得注意的是 DCCP [8]，实时视频应用程序使用 ad-hoc 拥塞控制算法管理的 UDP 套接字（应用层实现的）（参见 f.i.、[9] 和 [10]）。采用这种做法的明显缺点是不同的应用程序无法互操作，这阻碍了 RTC 应用程序的大规模应用。一个名为 WebRTC 的 W3C 和 IETF 联合倡议已经被建立起来解决这个问题。 特别是，WebRTC 计划旨在标准化一个可互操作且高效的框架，用于通过实时协议 (RTP) 使用 Web 浏览器进行实时通信 [11]。仅在几年前推出的 WebRTC 计划如今允许超过 20 亿用户通过 Web 浏览器进行实时通信。另一个相关的 IETF 工作组 RTP 媒体拥塞避免技术  (RMCAT) 已经成立，用于标准化 RTC 的可互操作拥塞控制算法。

本文显着扩展了我们的预览工作 [12] 并介绍了 Google 拥塞控制 (GCC)，它是一种完全符合 WebRTC 框架的算法。该算法被设计为与 RTP/RTCP 协议一起使用，并且基于使用延迟变化来推断拥塞的想法。首先，我们建议使用卡尔曼 kalman 滤波器来估计应用层的单向延迟变化。然后，我们将展示，这个估计的延迟变化不会与一个固定的阈值去比较，二十提出了一个简单有效的控制法则去动态的调整阈值，估计的延迟会与动态阈值比较从而去判断拥塞状况。在我们之前的工作 [12] 中，我们在 IETF RMCAT 工作组 [13] 中描述的场景中对 GCC 进行了实验评估。做出这一选择是为了与 RMCAT WG 中提出的其他拥塞控制算法在一组常见场景中进行比较。在本文中，我们进一步研究了 GCC 在广泛的网络条件和场景下的行为。特别是，我们评估了算法对不同队列大小、瓶颈容量和并发流数量的敏感性。 我们相信获得的结果可以更完整地描述算法的性能。

我们在本文中提出的算法今天已被互联网上使用最多的浏览器 Google Chrome 采用。据我们所知，GCC 是唯一一个为 WebRTC 提出的拥塞控制算法，并已部署在 Internet 上。 此外，谷歌最近宣布，名为 Google Duo 的 Android 新视频会议应用程序也将采用 GCC。 最后，我们指出，这项工作中呈现的实验结果是可以重现的。 事实上，(i) 所提出算法的代码可在 Google Chromium GIT 存储库 [14] 中获得，并且 (ii) 有关如何设置本文中使用的测试平台的详细信息已公开发布 [15]。

本文的其余部分安排如下。 第二节回顾了延迟敏感流拥塞控制的相关文献。 第三节描述了所提出的算法。 在第四节控制参数被调整。 第五节介绍了实验测试平台和采用的指标。 第六节说明了实验结果，第七节总结了论文。

传统的基于丢包的 TCP 不适合实时通信流量，因为它的拥塞控制会持续探测网络可用带宽，从而引入周期性循环，在此期间网络队列首先被填充然后排空。 这些队列振荡会引起随时间变化的随机延迟分量，该分量会增加传播时间并使对延迟敏感的通信成为问题。 可以采用两种互补的方法来解决这个问题：端到端，将控制放在端点中，以及主动队列管理 (AQM)，解决路由器中的问题。

开创性论文 [16] 提出了网络延迟与网络拥塞相关的想法。然而，从那时起，已经考虑了与基于延迟的算法中的延迟测量相关的几个问题 [17]，特别是在无线环境 [18] 以及当瓶颈与基于丢包的流共享时 [19]、[20]。在下文中，我们回顾了相关工作集群提出的端到端拥塞控制算法，该算法基于 推断拥塞的度量 和使用 AQM 来控制网络中瓶颈排队延迟的解决方案。

旨在减少排队延迟的第一个努力是在 TCP 拥塞控制研究领域中进行的，因此，许多实时流量算法都植根于该文献。  Jain 在 1989 年的开创性工作中采用了第一个专门设计用于包含端到端延迟的拥塞控制算法 [16]。从那时起，提出了几种基于延迟的 TCP 拥塞控制变体，例如 TCP Vegas [21] 和 TCP FAST [22]，它们使用 RTT 测量来推断拥塞。已经表明，当 RTT 用作拥塞度量时，存在反向流量或与基于丢包的流量竞争时，可能会获得较低的信道利用率 [19]。值得一提的是，由于视频流是双向发送的，因此反向流量问题在视频会议中至关重要。

另一类算法提倡使用单向延迟测量来排除对反向路径拥塞的敏感性。 示例是 LEDBAT（通过 UDP）[23] 和 TCP Santa Cruz [24]。特别是，LEDBAT [23] 利用与测量的单向延迟和固定延迟目标之间的距离成比例的速率增加其拥塞窗口。已经表明，LEDBAT 受到所谓的“后来者效应”的影响：当两个流共享相同的瓶颈时，第二个流通常会饿死第一个 [25]。

使用 RTT 梯度来推断拥塞的想法最近已被用于克服上述“后来者效应”。一些例子是 CDG [26] 和 Verus [27]。CDG [26] 旨在提供与基于丢包的流和低端到端延迟的公平共存。Verus [27] 是专门为蜂窝网络设计的，在这些网络中，突然的链路容量变化使拥塞控制设计具有挑战性。 最近，已经表明，通过使用 NIC 硬件时间戳 [28]，可以在数据中心网络中实现准确的延迟梯度测量。

在最近提出的拥塞控制算法中，不通过测量网络延迟来推断拥塞，我们引用了 Sprout [29] 和 Remy [30]。  Sprout [29] 采用一种随机方法，旨在考虑延时的情况下最大化吞吐量。Remy [30] 是一个生成拥塞控制算法的框架。通过根据用户需求定义效用函数，Remy 利用网络的先验知识使机器学习拥塞控制方法。

排队延迟也可以通过适当调整网络缓冲区大小[35]-[37]或使用 AQM 算法来减少，如果使用 ECN，则通过丢弃数据包或标记它们来控制路由器缓冲区 [38]。尽管过去已经提出了许多 AQM 算法，但由于两个主要问题 [39]，它们的采用一直受到阻碍：（i）它们旨在控制平均队列长度而不是排队延迟和（ii） 必须对 ad-hoc 配置的参数进行调整。 这些问题，连同缓冲区膨胀现象 [40]，激发了对新 AQM 算法的研究，例如 CoDel [39] 和 PIE [41]，它们不需要参数调整，并且显式控制排队延迟而不是队列长度。

在补充论文 [42] 中，我们进行了一项实验研究，研究 GCC 和基于延迟的 AQM 方案之间的相互作用。结果表明，如果只有 GCC 流通过瓶颈，GCC 能够在 drop-tail 队列的情况下以零丢包控制排队延迟。另一方面，PIE 和 CoDel 提供了与 drop tail 大致相同的排队延迟，但有引入数据包丢失的缺点。这是因为CoDel（或PIE）对延迟增加的反应比 GCC 早，导致了视频流的丢失。此外，我们已经证明，与 AQMs相比，诸如随机公平队列（SFQ）之类的流调度器提供了更好的解决方案，因为它们提供了流隔离。特别是，当与 SFQ 一起使用时，GCC 在排队延迟和数据包丢失方面效果最好。

GCC是为实时流而设计的。它必须（i）在没有并发异构流量的情况下提供低排队时延，以及（ii）在与同质或异构流竞争时提供合理的带宽份额[43]。

为了满足这两个要求，设计了两种协同拥塞控制算法，如图 1 所示。在收端有一个基于延迟的控制器，其主要目标是维持一个低的排队延迟。而当丢包被侦测到时，位于发端的基于丢包的控制器就将发挥作用。

发送端采用 UDP 套接字发送 RTP 数据包以及接收 来自收端的 RTCP 反馈报告。具体而言，基于延迟的控制器计算反馈给发送方的速率 ；基于丢包的控制器计算速率 。目标发送速率设置为 minimum()。图 1 中， sending engine 这个模块将来自源设备的源视频以匹配速率 A 进行编码，然后通过 UDP 套接字发送编码后的视频。

接下来，我们将会提供算法的描述。GCC 的源代码在 Chromium web browser 的 WebRTC 仓库中可见。

设计理由：理想情况下，拥塞控制算法应提供充分的链路利用率，同时在稳态下保持零排队。在端点无法直接测量队列长度。因此，必须使用单向延迟或 RTT 测量值来估计队列长度，然而，这些测量值受第二节讨论的几个问题的影响，即反向路径拥塞、后来者 late comer 现象等。

为了消除这些问题的影响，我们测量单向延迟变化来检测拥塞。图 1 详细介绍了所提出的基于延迟的控制器的体系结构。

接下来，我们将展示这 3 个组件是如何设计的。

*定义 1 *： 单向排队延迟梯度是排队延迟的导数。

一个众所周知的排队延迟流模型是，其中 C 是瓶颈链路的容量， 是队列长度，单位为 bits。因此，排队时延的梯度 就是：

队列长度的导数可以按照如下方式建模：

其中， 是其中r（t）是以每秒比特数(bits/s) 为单位测量的队列填充率, 是队列大小。 可以作为拥塞信号，当 时，队列在膨胀，当 时，队列在缩小。在所有这些情况中， 的值越大，则队列越快被填充或者越快缩短。

根据上面所说，提出的算法旨在不完全占据链路的情况下保持队列尽可能的小。为了实现这一目标，算法必须通过增加发送速率来探测可用带宽，直到检测到正向增长的排队延迟变化。此时，必须降低发送速率。因此，需要引入一些排队延迟来运行基于延迟变化的拥塞控制算法。

估计：从分布式节点的同步[46]到基于延迟的拥塞控制算法，测量计算机网络中的单向延迟是多个应用中的关键问题。尽管在过去[47]已经讨论过使用延迟来推断拥塞，但最近几项研究提倡使用这种度量来驱动拥塞控制算法[26]，[28]。

我们提出使用单向延迟变量(OWDV, one-way delay variation) 端到端的测量 去估计单向排队延迟变化 。端点测量 OWDV 的方法如图 2 所示：

其中 是第 i 帧视频的第一个包被发送的时间(该包的发送时间戳)， 则是第 i 帧视频最后一个包被接收的时间。需要注意的是，上述公式并不要求发端和收端时间同步。

这里的目标是要从 中将 提取出来。特别地，我们需要一个工具，能够同时过滤噪声 和消除传输时延变化这一项。在 上使用噪声滤波器只能滤除分量 而不能滤除传输延迟变化引起的影响。一个合适且稳健的解决这一问题的工具是 Kalman 滤波器。我们使用一个 Kalman 滤波器去估计系统的状态 ，基于其模型和噪声测量 。系统的状态向量定义如下：

系统模型由(5)给出：

状态中的噪声 建模为平稳高斯过程，其均值为0，方差 。与 类似的，测量的噪声 —— 将网络抖动考虑在内 —— 也被建模为平稳高斯随机过程，均值为 0，方差 。状态和测量噪声方差都是需要适当调整的重要参数。

在每一步， innovation 或者 residual （残差） 被计算为:

= 。残差 乘以卡尔曼增益 ，它提供对估计的校正，并根据进程和测量的噪声变化动态更新：

其中 是递归计算的系统误差变化：

在我们的例子中，卡尔曼增益由两个部分组成； 提供了对单向延迟变化 的修正：

观察式子，结果证明等效于自适应 EWMA (Exponentially Weighted Moving Average)滤波器，该滤波器将测量的 OWDV 作为输入，从中减去估计的传输延迟变化 。该等式表明，卡尔曼滤波器既能够自适应地过滤噪声 ，又能够从测量值 中消除传输时间变化的影响。

注：在通信领域中， EWMA 主要用于对网络的状 态参数进行估计和平滑， 例如在 TCP 拥塞控制中 EWMA 被 用来计算分组的往返时延 ( RTT ) ，在拥塞控制中的主动队列管理(AQM）技术中很多使用EWMA平滑估计拥塞指示参数( 如平均队长) 等参数

关于状态噪声协方差 的调整，我们在真实网络上进行了多次实验，并选择了算法响应 检测拥塞和过滤噪声两方面达到最佳平衡的设置，以避免错误的反馈。 被设置为：

可以通过考虑状态分量的动态来对这种设置进行过一个物理上的解释。由于瓶颈容量 通常未知但恒定，因此与影响 的噪声的方差相比，这种分量 的方差非常小。

关于测量噪声方差 ，我们使用残差的指数移动平均滤波器:

其中，是根据 式测量的。这是在无法获得有关测量噪声的信息时采用的典型方法。

最后，关于系统初始条件，当初始系统误差方差 远大于状态噪声方差时，可以快速收敛。我们设置：

在这些条件下，状态的初始估计可以自由设置为任何值。

拥塞检测：在本节中，我们设计了一种，基于卡尔曼滤波器估计的单向延迟变化 的拥塞检测机制。为此，我们将 与阈值 进行比较来检测拥塞。这种机制由图 1 所示的 over-use detector 模块实现。特别是，此模块产生一个信号 ，它可以采用三个不同的值（参见图 3）：(1) overuse 当 ：一个正在增长的队列长度被检测到 (2) underuse 当 ：检测到缩小的瓶颈队列，比如说输入速率低于可用带宽； (3) normal 当 ：检测到未改变的拥塞状态。

阈值 的值对于调整拥塞检测机制至关重要。直观地说，一个小的阈值会使算法在检测拥塞状态的变化时非常敏感，但它会有对噪声过于敏感的缺陷。相反，较大的阈值会导致对拥塞状态变化的检测缓慢，但在噪声方面会更加稳健。此外，不能将阈值 设置为常数值（另见 [50]），因为可能会出现两个问题： (i) 如果瓶颈队列的大小不够大，基于延迟的控制器可能永远不会影响发送速率计算 (ii) GCC 流在并发基于丢失的 TCP 流的情况下处于饥饿状态。

为了克服这些问题，我们提出了一种 自适应阈值，以实现适应网络条件的检测机制。我们提出以下控制规律来动态调整阈值：

其中，， 是接收到第 个视频帧的时间。增益 定义为：

其中 确定阈值增加（减少）的速率。阈值 是 的低通滤波版本。 的调整将在第四节讨论。

速率控制：有限状态机 (FSM) 由 over-use detector 产生的信号 驱动，并按如下方式计算速率 ：

其中 代表第 个视频帧被接收的时间，， 是测量的接收速率。是增长速率，等于平均包大小除以 RTT 的一半。

有限状态机如图 4 所示。FSM 的状态由 基于 的过度使用检测器信号 驱动。重要的是要注意 的上限为 。

提出的 FSM 的基本原理如下：当瓶颈缓冲区开始建立时，估计的单向延迟变化 是正数。然后，过度使用检测器检测到这种变化并触发过度使用 overuse 信号，驱动 FSM 进入 “Decrease” 状态。因此，发送速率降低，瓶颈缓冲区开始消耗，直到估计的单向延迟变化 变为负值。然后 underuse 信号就会被触发，该信号驱动 FSM 进入 Hold 状态。FSM 保持在“Hold”状态，直到瓶颈缓冲区变空。当这种情况发生时， 接近于零，过度使用检测器产生一个 normal 信号，驱动 FSM 再次进入“增加”状态。

在测量丢包的情况下，基于丢包的控制器对基于延迟的控制器进行了补充。每当发送方在时刻接收到携带 的反馈消息，该算法就会发挥作用。反馈消息通过实时控制协议 (RTCP) 发送。RTCP 报告包括按照 RTP RFC [51] 中所述计算的丢失数据包 的比例。发送端使用 根据以下公式计算发送速率

在本节中，我们描述了用于检测拥塞的自适应阈值参数的调整。特别地，我们首先进行中使用的参数 ku 和 kd 的选择，这些参数决定了阈值增加或减少的速度。然后，我们解释了为什么必须使用自适应阈值来避免（i）如果瓶颈队列的大小不够大，基于延迟的控制器永远不会影响发送速率计算，并且（ii）GCC流与基于丢包的 TCP 流并发的情况下，为什么会处于饥饿状态。

自适应阈值的动态变化取决于 和 两个参数，它们决定了阈值 跟随延迟梯度 变化的快慢。 和 是动态时间常数。为了调整这些参数，我们通过使用 [52] 中提出的目标函数来陈述优化问题：

其中， 时测量第 i 个流的目标函数。全局的目标函数是 N 个并发流的 之和。 是第 i 个流的平均吞吐量。是一个凹效用函数，由下式给出：

众所周知，对于任何 的值，这个优化问题都是帕累托有效的 [52]，[53]。 的最大化意味着在并发流之间公平分配吞吐量。 在视频会议的情况下，我们需要扩展 以考虑排队延迟对系统性能的影响 [30]：

用于 的相同原理适用于 ，其中 是第 i 个流测量的平均排队延迟。参数 a 和 b 表示吞吐量和延迟的公平性和效率之间的权衡，而 表示延迟相对于吞吐量的相对重要性。根据 [30]，我们使用 ，更加强调吞吐量公平性，，保证 和 很好的平衡。

我们考虑了三种测量目标函数的场景： (i) 单个 GCC 流通过具有可变链路容量的瓶颈，类似于图 10 中所示的用例。

(ii) 多个并发 GCC 流过具有恒定链路容量的瓶颈，类似于图 13 中描述的用例 (iii) 一个 GCC 流与一个 TCP 流通过具有恒定链路容量的瓶颈。目标函数针对 范围内的每个 和 值计算，并以对数尺度划分为 200 × 200 个区间。每对（ku，kd）在每个场景中获得的归一化目标函数 之和的等值线图如图 5 所示。

当 时， 呈增长趋势，即阈值 增长迅速，下降缓慢。然而当 时，如图 5 右下角所示，阈值降低得太慢，降低了算法对延迟膨胀的敏感性；这会导致更高的排队延迟，因此，U 会减小。另一方面，当 时，算法变得对延迟变化非常敏感，这会在并发 TCP 流的情况下导致吞吐量下降。对于 获得最大值。此设置提供了吞吐量、延迟、协议内和协议间公平性之间的最佳折衷。

我们现在来解释为什么需要自适应的阈值。事实上，一个常数阈值 ， 如果 大于最大可测量延迟变化，则可能会阻止基于延迟的控制器发挥作用。

提议 1：让我们考虑一个 GCC 流访问具有最大排队时间 的 drop-tail 瓶颈队列。如果以下条件成立，则无法生成过度使用 over-use 信号，因此基于延迟的控制器处于非活动状态：

其中， 是使用基于丢包的算法 计算的发送速率的指数增长阶段的时间常数。

证明：我们首先回顾基于延迟的控制器的目标是在排队延迟变得太大之前停止发送速率 的增加。为此，基于延迟的控制器的过度使用检测器 over-use detector 将估计的 与静态阈值 进行比较，如果 ，它会触发速率降低。因此，如果 的最大值 小于 ，则抑制过度使用信号的产生。因此，为了证明这个命题，我们需要证明如果 成立，那么 。

从计算 开始。根据第三节给出的假设， 是对排队延迟梯度˙ 的估计。由于我们的目的是找到 的最大值，因此我们只考虑 ， 当测量的丢包率 时发送速率 的指数增长阶段。发送速率 r(t) 的增加阶段的流量模型可以很容易地从 (14) 推导出如下：

现在，组合和得到：

令 表示 的时刻，即队列开始建立的那一刻。让我们分析 时 的动态。在这些假设下，通过对 积分可以得出：

现在将 代入 ，我们得到：

等式 是一个单调递增函数，直到点 ，即当队列已满并且数据包开始被丢弃时。 因此， 的最大值等于 ，其中 tM 是队列变满的时刻，即。考虑，以及在 之间积分，我们有：

根据第 VI 节的实验评估，我们测得 为秒级，远大于 ；因此，通过计算指数的二阶 McLaurin 展开并将其代入 ，我们得到以下近似值：

因此，最小的排队延迟为：

该命题通过观察来证明，如果条件 (18) 成立，则证明 。

为了通过实验验证使用恒定阈值的问题，图 6 (a) 显示了一个真实的实验（有关测试平台的详细信息，请参见第 V 节），其中单个 GCC 流在 1 Mbps 瓶颈链路上启动，其尾部队列最大排队时间为 。

图 6 比较了在阈值静态设置（图 6 (a)）和自适应阈值（图 6 (b)）的情况下的 GCC 速率、RTT 和丢失数据包的比例。使用静态阈值 ，基于延迟的控制器变得无效，并且无法在存在延迟时间膨胀的情况下做出反应。这是因为延迟变化（梯度）的最大值，其取决于 ，比 更小。另一方面，图 6 (b) 表明，使用自适应阈值， 以较慢的时间常数跟随 ，当 m(t) 超过 时，基于延迟的算法可以降低发送速率。图 6 (b) 还显示控制器能够避免数据包丢失，即在整个实验期间 。为了进一步展示自适应阈值的好处，图 7 比较了图 6 中报告的两个实验中测量的 RTT 的累积分布函数。RTT 的测量中位数非常接近传播延迟 ，而由于自适应阈值，RTT 的第 95 个百分位数从 130 ms 减少到 90 ms。

在本段中，我们展示了阈值必须是自适应的，以避免在存在基于丢包的并发流的情况下 GCC 流的饥饿。为此，我们考虑单个 GCC 流和一个并发的长寿命 TCP 流。我们将证明，阈值的静态设置可能导致 GCC 流的饥饿。 在这种情况下，单向延迟变化可以表示为两个分量的总和：

其中， 和 分别是 GCC 和 TCP 流的排队延时变化， 和 则是相应的发送速率。

在下文中，我们展示了由 TCP 流引起的最大延迟变化 可能比 GCC 流大得多。特别是，通过使用用于推导 (24) 的类似参数，我们得到：

TCP 吞吐量的一个众所周知且广泛使用的近似值是 [44]，其中 是TCP 流的拥塞窗口，RTT(t)是往返时间。拥塞窗口的最大值可以假设为队列大小 加上 in-flight 字节—— [45]，即 ，其中 的最小值是往返传输时延 。因此，，于是：

和 的比值：

明显，当 增大，这个比例单调上升。因为在这个情况下， 因为 TCP 流的缘故包含 ，如果 ，GCC 流降低 并不是因为自身流的延迟，而是因为 TCP 流造成的排队延迟。这就意味这，如果使用固定阈值 ，当有大的队列时这个 TCP 流将会饿死 GCC 流。

为了通过实验验证理论发现，图 8 显示了一个真实的实验，该实验通过使用第 V 节中描述的测试平台运行。

图 8 显示了一个 GCC 流，它与一个 TCP 流在一个 1Mbps 瓶颈链路上和最大排队时间为 的 drop-tail 队列上竞争。图 8(a) 显示，当使用固定的阈值时，GCC 流会被饿死。特别地，当 TCP 流启动后， 开始在 阈值 之上震荡，主要是因为 TCP 流造成的排队时延变化 ，触发了大量的 overuse 信号。因此，远端的 FSM 控制器进入了降速模式，依据 减少 的值。另一方面，图 8(b) 展示了自适应阈值避免了 GCC 流的饥饿，为 TCP 流和 GCC 流提供了公平性。特别是，在 TCP 启动后， 以较小的时间常数跟随 ，这避免了产生大量连续的过度使用 over-use 信号并防止 GCC 流的饥饿。

图 9 显示了用于模拟 WAN 场景的实验测试平台。 有关如何重现实验的更多详细信息可在线获得 [15]。 测试平台由四台配备 Linux 内核 3.16.0 的 Linux 机器组成。通过以太网电缆连接两个节点，每个节点运行多个 Chromium 浏览器 [14] 会话和一个生成或接收 TCP 长寿命流的应用程序。 因此，可以分析 GCC 流在与 TCP 流竞争时的行为。 另一个节点运行一个网络服务器，它处理在浏览器之间建立视频呼叫所需的信令。 最后一个节点是通过 ssh 命令编排实验的测试平台控制器。 测试台控制器承担以下任务：

(i) 它放置 WebRTC 调用以启动 GCC 流；  (ii) 在节点 1 上设置链路容量 C 和瓶颈队列大小 ；  (iii) 它设置节点 2 上的传播延迟 ；(iv)它在需要时启动 TCP 流

瓶颈队列被放置在节点 1 上，并采用 drop-tail 排队规则。队列大小 考虑耗尽缓冲区 所需的最大时间来设置，即 。

往返传播延迟 ，这是通过 NetEm Linux 模块在节点 2 上设置的直接和反向路径上的传播延迟之和（每个 25ms），而瓶颈队列大小 已经根据对边缘网络的大型测量研究 [54]，设置在 范围内， 设置在 范围内。我们使用了令牌桶过滤器 token bucket filter(TBF) 来设置节点 1 的入口链路容量 C。

TCP 源使用 CUBIC 拥塞控制，这是 Linux 内核中的默认设置。记录拥塞窗口、慢启动阈值、RTT 和序列号。  Web 服务器提供 HTML 页面，该页面使用 WebRTC JavaScript API [11] 处理对等点之间的信令。相同的视频序列用于保证实验可重复性。为此，我们使用了循环重复的 “four people” YUV 测试序列。Chromium 使用 VP8 视频编码器对原始视频源进行编码。我们测量到，在没有任何带宽限制的情况下，VP8 将发送比特率 限制为最大值 2Mbps。

为了定量评估 GCC 的性能，我们考虑 QoS 指标，例如丢包率、平均比特率和延迟，这些指标与 QoE 指标密切相关，例如 IQX 假设 [55]。遵循这种方法的优点是使用 对应用特定方面不敏感的指标，例如所采用的视频编码器。此外，将 QoE 指标的评估与 QoS 指标分开也遵循 IETF RTP 媒体拥塞避免技术 (RMCAT) 工作组 [13] 中定义的指南。特别地，我们考虑：

在本节中，我们展示了使用第五节中描述的测试平台获得的实验结果。目标是检查 GCC 是否满足 [43] 中定义的实时通信要求，即在没有并发异构流量的情况下的低排队以及在与其他同质或异构流竞争时的合理带宽份额。特别是，我们考虑了单个 GCC 在不同的瓶颈条件下运行的场景，GCC 与长寿命和短寿命 TCP 流共享瓶颈的场景，最后是可变数量的 GCC 流共享瓶颈的场景。重要的是要注意，在典型的视频会议会话中，对等点连接到边缘网络，瓶颈通常位于上行链路接口 [54]。

我们通过考虑单个 GCC 流越过瓶颈来开始实验评估。 我们考虑两种情况：第一种旨在检查当链路容量发生阶梯式变化时 GCC 如何调整其发送速率； 第二种是家庭网络场景，其中只有视频会议会话正在使用网络。

可变链路容量: 在本节中，我们研究当链路容量发生阶跃变化时，GCC 流如何调整其发送速率。特别是，链路容量 $$ 呈阶梯状变化：从 等于 500kbps 开始， 每 50s 增加 500kbps，直到达到 2000kbps 的容量。然后，使用相同的模式减少 。 往返传播延迟 已设置为 50ms。图 10 表明 GCC 发送速率能够快速匹配可变链路容量 。

此外，GCC 包含排队延迟，因为在整个视频通话期间 RTT 保持接近 RTTmin。总体而言，平均测量的信道利用率大致等于 86%。 我们可以得出结论，评估 GCC 能够跟踪链路容量，同时限制数据包丢失并保持低排队延迟。

具有恒定链路容量的不同瓶颈条件：在本节中，我们研究单个 GCC 流在具有恒定链路容量的瓶颈上的性能。瓶颈的容量 已设置为 ，并考虑了队列大小的三个值，即 。

对 12 种组合中的每一种组合 ，我们运行 10 个视频会议，每一个视频会议持续 300s，我们通过对 10 次实验进行平均来评估第五节中定义的指标。图 11 显示了按队列大小 的值分组的度量；

每个组都包含一个条形图，该条形图根据平均信道利用率 U、平均丢失率和排队延迟百分位数显示特定 值的度量。

无论参数 和 多少，每个实验的信道利用率都略高于 90%。当 或 时，GCC 能够避免损失，而在 的情况下，测量到一些丢包。排队延迟使用对数刻度的 whisker plot 图来描述：箱的底部和顶部分别是第 25 个和第 75 个百分位数，而框中的红色带是中位数；胡须的末端代表第 5 个和第 95 个百分位数。让我们关注链路容量 对排队延迟的影响。我们注意到，在所有实验中，随着链路容量的降低，第 95 个百分位数更大：这是因为根据等式，到达滤波器在较低的链路容量下测量到较大的延迟变化。让我们关注瓶颈队列大小 的影响。 当 时， 的第 95 个百分位受到小队列大小的限制，代价是溢出导致的一些损失。随着 值的增加，它对排队延迟的影响变得不那么显着，证明 GCC 能够适当地控制排队延迟。。还有就是，图 11 展示了 在每一个实验中，排队时延的中位数都低于 3ms。

B. GCC 流与 TCP 流并发 我们现在考虑一个 GCC 流与一个 TCP 流共享瓶颈链路的情况。 此方案旨在验证 GCC 是否能够在不同的瓶颈条件下公平地与长期 TCP 流共享链路容量。

特别是，这种情况考虑了在视频会议会话期间用户与其他对等方共享大文件的场景。视频通话从 t = 0 s 开始，持续 400 秒，而 TCP 流在时间间隔 [100, 300] 秒内活跃 200 秒，如图 8 所示。容量已设置为 和瓶颈队列大小为 [54]。对于 9 对 中的每一对，我们进行了 10 次实验，通过对 10 次实验中获得的结果进行平均来测量第 V 节中定义的指标。图 12 显示了按队列大小 的值分组的度量； 每个组都包含一个条形图，该条形图显示了 的特定值在平均信道利用率 、平均丢失率和排队延迟平均值方面的度量。

从图 12 中可以看到，在 和 的情况下，GCC 流能够和 TCP 流公平地共享链路容量，而 的情况下，TCP 占有链路容量略微超过了 GCC 流。这是通过自适应阈值实现的，该阈值通过降低基于延迟的控制器的灵敏度，导致 GCC 流在存在并发基于丢包的流的情况下，由基于丢失和基于延迟的算法来控制。事实上，对于任何 值，GCC 流量测量的loss 率都大于零，这证实了该算法也在基于丢包的模式下运行。图 8(b) 先前显示了一个实验动态，以描述第 IV 节中的自适应阈值。

为了结束本节，我们指出通过使用 NewReno 拥塞控制代替 CUBIC 也进行了同一组实验。NewReno 的实验结果与 CUBIC 类似，由于篇幅限制就不放在文章里面了。然而，一个完整的性能评估，在未来，还应该包括不同的TCP拥塞控制算法，并考虑具有不同往返时间的流来检查RTT公平性。

本节的目的是调查 GCC 协议内的公平性。该案例考虑了多个用户使用视频会议的场景，例如在家庭网络场景中。为此，我们考虑可变数量的并发 GCC 流 并且链路容量 以这样的方式变化，即流之间容量的公平份额 等于 ,如果 ，则 设置为 ； 在每个实验中，瓶颈队列大小已设置为 。每个流程在前一个流程之后 20 秒开始，实验持续 200 秒。对于 9 对 中的每一对，我们进行了 10 次实验，并通过平均 10 次实验来评估指标。图 13 显示了一项实验的动态，其中四个 GCC 流共享瓶颈，公平共享 设置为 1Mbps（即 ）。

这个实验表明GCC不受“后来者效应”的影响[25]；三个 GCC 流公平地共享链接，测量的 Jain 公平指数接近 0.93。在整个实验期间没有数据包丢失。图 14 总结了每对 获得的结果。 结果按并发 GCC 流数 的值分组；每个组都包含一个条形图，该条形图根据平均信道利用率 、平均丢失率和对数刻度的排队延迟百分位数显示特定 值的度量。首先，我们注意到并发流的数量并没有显着影响指标：每次实验测得的 JFI 都在 0.9 以上，证实了该算法提供了协议内公平性，累积信道利用率始终保持在 85% 以上。某些损耗仅在 时发生。对于排队延迟的问题，结果类似于在第 VI-A 节中在单个 GCC 流的情况下获得的结果：随着链路容量的减少，第 95 个百分位数更大，而中值始终保持在 3ms 以下，这与单流场景的情况完全相同。 总的来说，我们可以得出结论，GCC 能够提供协议内公平性，同时保持低排队延迟和损失。

在本文中，我们介绍并评估了用于控制视频会议应用程序发送速率的 Google 拥塞控制 (GCC) 算法。  GCC 已在开源 Chromium Web 浏览器中实现，并已被 Google Chrome 浏览器采用。广泛的实验评估表明，GCC 能够控制排队延迟，同时提供协议内和协议间的公平性以及完整的链路利用率。