Measuring the Performance and Network Utilization of Popular Video Conferencing Applications

1 Introduction

视频会议应用程序需要多少网络资源、它们如何应对网络降级和连接中断、它们如何与每个应用程序竞争，以及这些问题如何根据使用方式（例如，画廊模式与演讲者模式）而变化。

2 BACKGROUND & EXPERIMENT SETUP

我们研究了三种流行的 VCA——Zoom、Google Meet 和 Microsoft Teams。

我们首先描述我们的双方通话的实验设置。我们使用两台相同的笔记本电脑，称为 V1 和 V2，代表两个 VCA 客户端。每台笔记本电脑都是戴尔 Latitude 3300，屏幕分辨率为 1366 × 768 像素，运行 Ubuntu 20.04.1。这些笔记本电脑通过有线连接到 Turris Omnia 2020 路由器，并通过专用的 1 Gbps 对称链路访问互联网。每个实验都包含在预先指定的网络带宽配置文件和 VCA 下的 V1 和 V2 之间的呼叫。流量控制 (tc)，更具体地说是分层令牌桶排队规则，在路由器上用于模拟网络带宽配置文件。使用 ffmpeg 将分辨率为 1280 × 720 的预先录制的谈话头视频用作呼叫的视频源。

3 STATIC NETWORK CONDITIONS

我们进行了一系列实验，每个实验包括两个客户端 V1 和 V2（如第 2.2 节所述）在特定整形级别下的 2.5 分钟通话。我们进行了两组实验，首先是上行链路，然后是下行链路。我们将吞吐量限制为 {0.3, 0.4, . . . , 1.4, 1.5, 2, 5, 10} Mbps（上行和下行方向）。对于每种情况，我们进行了 5 次 2.5 分钟的实验；我们的数据表明，由于大多数观察结果的方差相对较低，因此这一数量的实验足以获得具有统计学意义的结果。

3.1 Network Utilization

受限上行利用率：图 1a 显示了不同上行链路容量的中值发送网络比特率。我们观察到在相同可用上行链路网络容量的情况下，VCA 之间的上行网络利用率存在差异。例如，在 10 Mbps 上行链路的情况下，Teams-native 的平均上行利用率为 1.44 Mbps，而 Meet 仅为 0.95，Zoom 为 0.77 Mbps。当链路受到严重限制（0.8 Mbps 或更低）时，所有三个 VCA 都有效地利用了上行链路（超过 85%），尽管 Meet 的比特率略高于其他 VCA。

受限的下游吞吐量：我们探讨了受限的下游容量对 VCA 网络利用率的影响。图 1b 显示了这个结果。不受约束的下行链路利用率不同于不受约束的上行链路利用率，如表 2 所示。为了更好地理解这一现象，我们分析了从两个客户端捕获的流量。

对于 Teams，我们发现从 V1 发送的总流量与在 V2 接收的总流量几乎相同，反之亦然。我们怀疑上行和下行利用率的微小差异可能主要是由于 Teams 中实验的利用率不同，这在与 Zoom 和 Meet 相比更大的置信区间中也很明显。

相比之下，Zoom 的使用模式是不对称的：我们发现两个客户端的发送和接收数据速率不对称。我们发现 Zoom 使用中继服务器而不是直接通信。此外，Nistico 等人的相关工作 [26] 建议 Zoom 使用前向纠错 (FEC) 进行错误恢复。 Zoom 本身的一项相关专利进一步支持了这一点，该专利讨论了一种在服务器上生成 FEC 数据的方法 [19]。我们怀疑额外的数据可能因此对应于中继服务器添加的 FEC，从而导致不对称的上行和下行利用率。

Meet 在下行链路受限的情况下表现出明显不同的行为。具体而言，下行吞吐量受限（< 0.8 Mbps）的网络利用率仅为 39-70%（图 1b），而在上行链路受限的情况下则超过 90%（图 1a）。经过进一步探索，我们发现 Meet 还使用中继服务器以及simulcast，其中发送方 (V2) 将视频的多个副本传输到服务器，每个副本具有不同的质量级别 [26]。然后，服务器根据推断的服务器-V1 链路的可用容量将其中一个质量流中继到 V1。我们在实验中观察到两个同步视频流，一个为 320x180，另一个为 640x360 分辨率。当下行吞吐量受到限制时，中继服务器无法切换到更高质量的视频并继续以低质量比特率发送。这就解释了为什么 Meet 在 0.5 Mbps 时的网络利用率仅为 0.19 Mbps，几乎与 0.3 Mbps 时的利用率相似。simulcast的使用也解释了与下行利用率相比，上行利用率更高的原因。

浏览器与本机客户端利用率：图 1c 比较了 Zoom 和 Teams 在各自本机和 Chrome 客户端之间的上游利用率。 Zoom 在原生平台和基于浏览器的平台上的利用率相似；相比之下，我们发现 Teams 本机客户端和浏览器客户端之间存在显着差异。当上行链路容量调整为 1 Mbps 时，本机客户端使用 0.84 Mbps，而浏览器版本仅使用 0.61 Mbps。当下行吞吐量受到限制时，我们发现本机版本和浏览器版本之间存在类似的差异。

3.2 Application Performance

视频质量：VCA 通过调整编码参数来调整视频质量，以实现传输提供的目标比特率估计。理想情况下，VCA 可以调整以下三个参数中的一个或多个：

• 每秒帧数 (FPS)，

• 视频压缩中使用的量化参数。它调节编码帧时保存的空间细节。较低的值意味着更好的图像质量。请注意，量化参数的值在不同的编码标准之间不具有可比性，并且

• 视频分辨率表示为每个维度中的像素数。在我们的分析中，我们提出了分辨率的一个维度，即它的宽度。

结论：

随着下行容量的减少，Teams-Chrome 会同时降低所有三个视频质量参数。
随着下行容量的减少，在 1-0.7 Mbps 范围内，Meet 主要通过调整每秒帧数来调整比特率。从 0.7到 0.5Mbps，帧宽度会下降、量化参数增加，而每秒的帧数会同时增加。在仔细检查此操作范围内的每秒统计数据后，我们发现中继服务器可能会切换到它通过联播接收到的流的质量较低的副本。
随着上行容量的减少，Teams 主要通过增加量化参数和减小帧宽度来适应吞吐量，同时保持 FPS 几乎恒定。令我们惊讶的是，我们发现帧宽度随着上行链路容量减少到 0.3 Mbps 而增加。对于这种效果似乎没有特别好的解释，并且（正如我们在下一段中讨论的那样）它还会导致视频冻结，表明设计决策或实现错误。
Meet 遵循类似的趋势，主要增加量化参数，直到上行带宽降低到 0.5 Mbps。在 0.4 Mbps 时，它还减少了帧宽度和 FPS。

视频卡顿：

结论：

冻结率随着下行链路带宽的降低而增加。 Meet 的冻结率高于 Teams-Chrome，在 0.3 Mbps 时冻结率为 10%。有趣的是，即使在没有吞吐量限制的情况下，Teams-Chrome 也会发生冻结（3.6% 的冻结率），这再次表明实施存在问题或设计选择不佳。

4 NETWORK DISRUPTIONS

方法：我们通过引入瞬时容量减少来分析 VCA 如何在通话期间响应临时网络中断。使用与上一个实验相同的设置，我们在两个客户端 V1 和 V2 之间启动一个 5 分钟的 VCA 会话，这两个客户端都通过 1 Gbps 链路连接到 Internet。发起呼叫一分钟后，我们将 V1 和路由器之间的容量减少 30 秒，然后恢复到不受约束的 1 Gbps 链路。我们将每个实验重复四次。我们进行了两组实验：首先破坏上行链路，然后破坏下行链路。我们将容量降低到以下水平：0.25、0.5、0.75、1.0 Mbps。我们认为容量中断不会超过 1 Mbps，因为 Zoom 和 Meet 的平均利用率都低于 1 Mbps。

4.1 Uplink Disruptions

恢复时间：图 4b 显示了上行链路连接中断的程度如何影响每个 VCA 的恢复时间。容量减少越严重，VCA 需要恢复的时间就越长。即使在不太严重的中断情况下，Teams 也需要更长的时间才能恢复，原因有两个：（1）Teams 的标称比特率高于 Meet 和 Teams，（2）Teams 最初在中断后立即缓慢增加上游比特率，然后迅速恢复正常（如图 4a) 所示。当中断将容量降至 0.25 Mbps 时，Meet 也观察到类似的恢复模式。然而，对于不太严重的中断，它恢复得更快，主要是因为它的标称比特率约为 0.96 Mbps。

恢复模式：虽然 Meet 和 Teams 遵循更快速的趋势，但 Zoom 的恢复不同：在严重中断的情况下恢复所需的时间最长。根据图 4a，Zoom 遵循逐步恢复，中断后立即几乎线性增加。然后它进入一个周期性探测阶段，在这个阶段它增加发送速率，在它再次增加之前停留一段时间。探测阶段继续远高于其标称比特率，然后最终降低比特率。 Zoom 直到中断后两分钟才恢复到稳定的发送模式，同时以更高的速率发送。

4.2 Downlink Disruptions

图 5b 显示，Teams 的恢复速度比 Meet 和 Zoom 慢，无论中断的幅度如何，总是需要至少 20 秒的时间才能恢复到平均速度。此外，与上行链路中断相比，在这种情况下，Meet 和 Zoom 恢复得更快。对于所有三个 VCA，客户端通过中间服务器进行通信。因此，恢复时间取决于服务器的拥塞控制行为。

如第 3 节所述，Meet 使用称为 simulcast 的编码技术，其中客户端以不同的质量级别对相同的视频进行编码，并将编码的视频发送到中间服务器。然后，服务器根据接收器感知到的下行链路容量发送适当的版本。服务器可以根据下游容量快速切换版本。这种快速恢复如图 5 所示：无论中断的严重程度如何，Meet 都会在 10 秒内恢复到其平均速度。

同样，Zoom 在传输视频时使用可缩放视频编码 [39]。 Zoom 发送的不是发送多个不同质量的版本，而是发送分层编码层，当它们组合在一起时，会产生高质量的视频。这使得即使 V1 的下行链路容量减少，V2 也可以不间断地发送。一旦网络条件改善，服务器就可以通过发送额外的层来更快地恢复。

虽然 Zoom 和 Meet 的中间服务器执行拥塞控制，但对于 Teams，此服务器仅充当中继。在 Teams 通话期间，V2 将识别 V1 的下行容量有限，并仅以它知道 V1 可以接收的比特率发送。一旦 V1 拥有更多可用带宽，V2 必须发现这一点：它必须首先探测连接，然后才能返回其平均发送速率。图 6 说明了 V2 到中间服务器的发送速率如何在 Meet 通话期间没有变化，但在 Teams 通话期间下降到 V2 的下行链路容量以下，从而导致恢复缓慢。

5 COMPETING APPLICATIONS

我们专注于与其他 VCA、单个 TCP 流 (iPerf3) 和两个流行的视频流应用程序 Netflix 和 YouTube（使用 QUIC）共享链接。

对于每个测试，V1（现有应用程序）首先与 V2 建立 VCA 调用。大约 30 秒后，C1 启动竞争应用程序，持续两分钟。 C1 的对手方 C2 取决于竞争应用程序的类型。我们将每个实验重复 3 次，链路容量以 {0.5, 1, 2, 3, 4, 5} Mbps 对称变化。

5.1 VCA vs. VCA

考虑到上行方向，我们观察到每个 VCA 如何共享链路的差异。图 8 显示了上行链路容量为 0.5 Mbps 时现有 VCA 和竞争 VCA 的上行份额的箱线图。

Zoom 作为现有应用程序和竞争应用程序都非常激进，如果它是现有客户端，则使用至少 75% 的链路容量（参见图 8c）。事实上，Zoom 的拥塞控制甚至对自己都不公平。图 10a 更清楚地说明了这种效果，两个 Zoom 客户端之间的链路共享在 0.5 Mbps 上行链路容量下进行了一次实验。我们将此与图 10b 中两个 Meet 客户端之间的链接共享进行对比，其中两个会话都收敛到 0.25 Mbps 的公平份额。其他上行链路容量的结果类似，如果新客户端达到标称比特率，激进的应用程序就会为新客户端留出更多空间。

当下游容量受限时，我们发现 Zoom 和 Meet 的结果相似。但是，我们发现 Teams 在共享下游容量时是被动的，会退回到所有其他 VCA，包括其他 Teams 流。图 11b 显示了现有 Teams 客户端与 0.5 Mbps 下行链路容量下的竞争 VCA 相比的链路份额。

图 12b 中 Teams 的下游吞吐量甚至在 Zoom 呼叫开始之前就已经下降，这可能是因为竞争客户端打开 Zoom 登录页面以发起呼叫。这可能会导致链路上的 TCP 流量竞争，正如我们在下一小节中发现的那样，Teams 在与 TCP 竞争时非常被动。

当与现有 Teams 客户端在 3 Mbps 容量上行链路上竞争时，竞争 Teams 客户端未达到其标称利用率。FCC 对宽带互联网的定义是 25/3 Mbps，但很明显，3 Mbps 的上行链路容量不足以使两个团队的通话达到其标称利用率。

5.2 VCA vs. TCP

显然，所有的 VCA 都不是 TCP CUBIC 友好的，Meet 和 Zoom 非常激进，而 Teams 非常被动。

图 14 显示了在与 iPerf3 竞争时如何表现出这种行为。在大约 125 秒时，Zoom 增加的发送速率导致 iPerf3 突然降低其利用率。这证实了 Zoom 中的临时突发（可能是为了推断可用带宽）会对稀缺链路上的其他应用程序产生不利影响。

5.3 VCA vs. Video Streaming

在与视频流应用程序竞争时，Meet 和 Zoom 都非常激进，使用了超过 75% 的链接容量。相比之下，Teams 在与 YouTube 和 Netflix 以 0.5 Mbps 的速度竞争时使用率不到 25%。

当 Netflix 客户端以 0.5 Mbps 的下行容量与现有的 Zoom 客户端竞争时。 Zoom 的平均吞吐量约为 0.4 Mbps，而 Netflix 则难以达到 0.1 Mbps 以上。尽管已知 Netflix 使用多个 TCP 连接，但我们观察到了这种效果，尤其是在容量有限的情况下。图 15b 显示了 Netflix 在 120 秒实验期间打开的 TCP 连接。 Netflix 总共打开了 27 个 TCP 连接，每个连接的数据量都超过 100 Kbits；在某一时刻，它打开了 11 个并行 TCP 连接。尽管存在这种行为，但在与 Zoom 竞争时，打开多个 TCP 连接并不能改善 Netflix 的链接共享。

6 CALL MODALITIES

我们研究了两种主要通话模式下的网络利用率：（1）通话参与者的数量和（2）查看模式。

6.1 Number of Users

6.2 Viewing Mode

当所有客户端固定 C1 的视频时，Zoom 和 Meet 始终以 1 Mbps 的速度发送，无论参与者有多少。

在这方面，Teams 的行为也不同于 Meet 和 Zoom。 C1 的上行链路利用率从 3 名参与者的 1.25 Mbps 继续增加到演讲者模式下的 2.9 Mbps 参与者。我们检查了增加是否可以归因于团队与多个目的地的通信（例如，分别与每个用户）。但是，我们观察到所有流量都被定向到单个服务器。目前尚不清楚是什么导致了 Teams 流量的增加，但这显然会导致网络利用率低下，尤其是与 Zoom 和 Meet 相比时。