将slowdown作为拥塞控制公平性指标 | HotNets 23

本文介绍了一种新的互联网拥塞控制公平性评估框架，传统的拥塞控制公平性评估主要侧重于流量速率公平性，但这并不总能反映不同用户的实际需求，因为用户更关心的是流完成时间（FCT）。因此，作者提出了一种新的评估框架，以“slowdown”作为衡量拥塞控制公平性的新指标，这一指标考量了正规化的流完成时间。

作者：Adrian Zapletal；Fernando Kuipers
来源：HotNets ’23
标题：Slowdown as a Metric for Congestion Control Fairness
链接: https://dl.acm.org/doi/10.1145/3626111.3628185
内容整理：鲁君一

简介

传统上，研究人员通过启动多个共享瓶颈链路的流，让这些流尽可能多地发送数据，然后评估流量速率公平性，即这些流是否获得了相等的吞吐量。然而，这种传统的评估设置并不现实，也没有关注用户的实际需求。文章指出，这种传统评估方法存在三个核心问题：

流生成不符合现实，因为实际的网络流有一定的大小，且在传输完毕后会结束，而不是持续不断地发送数据；
流量速率公平性并不是最优的，因为如果长流和短流共享一个链接，执行流量速率公平性会不必要地延长短流的完成时间；
流量速率不公平并不一定意味着有害，如果一个流获得的带宽比另一个类似大小的流多，虽然存在流量速率不公平，但这并不一定会损害用户体验。

贡献：本文的主要贡献在于提出了一种新的拥塞控制公平性评估框架，该框架采用slowdown，即正规化的流完成时间FCT，作为衡量指标。

传统公平性评估方法

传统方法中多个发送方同时发送流通过共享瓶颈链路；这些流使用 iperf 等工具在固定时间内从无限的数据积压中发送数据。当流传输时，测量它们的吞吐量并评估所有流是否获得相同的吞吐量。这称为流量公平性。通常使用 Jain 指数等公平性指标来总结结果。

流生成办法

根据上图所示，互联网上的流量有以下特征：

流量具有不同的大小：在传统设置中生成的无限积压流量并不现实。在互联网中，流量具有一定的大小；流量需要传输一些数据，传输完数据后，它们就结束了。此外，流量在不同时间到达。有人可能会认为，无限积压的流量模拟长流量，但互联网中的大多数流量都是短的，即使对于长流量，也重要的是要考虑它们的大小。通过分析CAIDA数据集，MAWI数据集，校园网络trace数据集和各种真实世界网络trace数据的流量大小和流量间到达时间，验证了互联网中的流量确实差异很大。图1展示了结果，显示所有数据集都遵循类似的重尾分布，并且大多数流量确实是短的。

流量可能受到速率限制：传统设置假设每个流量都旨在实现尽可能高的吞吐量。然而，某些流量可能被限制在某种速率上。这类受限速率的流量示例包括流媒体、被文件主机节流的文件下载，以及在网络其他地方有瓶颈的流量。传统的评估设置没有考虑到受限速率的流量。

把流量速率作为公平性指标

用户更关心的是数据快速传输，而不是流量率的绝对公平。实际情况显示，当所有流量获得相同吞吐量时，短流量完成速度反而比被优先处理时要慢，而长流量完成时间并无差异。因此，简单追求流量率公平并不总是对用户体验最有利。实际上，大部分网络流量是短流，这些短流在公平性机制下可能处于不利位置，但这并不意味着流量不公平就一定是问题。例如，两个长流量共享带宽时，即使一个流量获取更多带宽也不会对另一个造成延迟，说明流量大小和实际使用情况比简单的公平性指标更重要。

本文的公平性评估方法

本文提出了一个关于公平性的新观点：当没有流量不必要地延长其他流量时，就是公平的。希望鼓励社区从使用流速公平性作为拥塞控制公平性的主要指标转变过来，通过提供一个实用且简单的替代方案并展示其有用性。评估框架需要一个设置，其中多个发送者共享一个瓶颈，类似于传统设置。它与传统设置的不同之处在于流量的生成方式和度量指标：流量代表实际的网络流量，度量指标是slowdown（即，归一化的流完成时间）。

流生成办法

流量要么使用预定义的大小和开始时间生成（例如，强制一个长流量堵塞瓶颈），要么生成随机流量，这些随机流量类似于实际工作负载。为了生成一个随机流量，我们从流量大小分布中随机选择一个值，从流量到达间隔时间分布中随机选择另一个值。这个设置允许我们进行现实但受控的实验，其中流量对应于实际的网络流量。此外，我们的框架支持通过限制发送者的输出带宽来生成限速流量。

把Slowdown作为公平性指标

对于大多数应用程序，用户主要关心的是他们的流量快速完成（例如，网页浏览、电子商务、社交应用、消息传递、文件共享）。因此，反映用户体验的公平性指标应该基于流完成时间（FCT）。然而，仅凭FCT并不实用，因为它依赖于流量大小、可用带宽和往返时间（RTT），使得比较不同大小流量的FCT变得困难。此外，FCT并不直观：对于给定场景，人们并不直观地清楚什么构成了一个“好”的FCT。

FCT作为指标存在的问题是因为FCT是一个绝对值。通过将FCT标准化为理论上的最优FCT（给定流量大小、带宽和RTT）来计算slowdown，定义为

slowdown直观地代表了用户的需求。然而，slowdown是每个流量的值，而公平性实验涉及多个流量。因此，我们计算所有流量的平均slowdown（看流量是否平均表现公平）和最大slowdown（看是否有任何流量被忽视）。

当有多个活动流量和瓶颈出现拥堵时，一定程度的slowdown是不可避免的，最佳的平均和最大slowdown值是不明确的。然后，将实验的slowdown结果与理论上的最优slowdown进行比较是有用的。在框架中，模拟了一个理想化的网络，在瓶颈路由器处使用最短剩余处理时间（SRPT）调度作为最优标准来比较实验结果。SRPT优化了平均FCT，并且对于平均slowdown具有2-竞争性。

实验

实验部分旨在验证了本文提出的拥塞控制公平性评估框架，主要通过使用“slowdown”作为衡量指标来评估不同拥塞控制策略在模拟网络环境中的公平性。实验涉及多个发送者、一个接收者以及一个路由器，使用了不同的拥塞控制算法（如Reno, Cubic, BBR, BBRv2）和不同的RTT设置，同时考虑了不同的缓冲区IW大小和队列管理策略。实验结果揭示了一个重要发现：尽管理论上优先处理短流应该比公平排队表现得更好，但实际应用中却因慢启动机制的影响而不尽如人意。此外，虽然存在流量速率的不公平，但这并不总是导致性能退化，特别是当拥塞控制算法能够迅速利用可用带宽时。

如上图，首先单独测试了各种流的性能，评估它们在没有其他流竞争资源时的slowdown。总结来说，大约一半的流量能在两个RTT内完成，另一半因慢启动而有显著slowdown。只有约1%的流量大到足以使稳态传输的效率高于慢启动，slowdown很小。另外，较短的RTTs可以减少慢启动的slowdown，尤其是对于基于损失的机制（如Reno和Cubic）在小缓冲区和长RTT条件下的长流量。不同的初始窗口配置也被测试，较大的IW值通常能减少单独运行时的减速。

上图实验探讨了网络中的“缓冲区膨胀”问题，即大流量填满缓冲区，导致共存短流量传输延迟增加和减速。通过模拟大流量与从MAWI追踪随机生成的短流量共存的场景，测试了不同的网络配置，包括拥塞控制算法、往返时间、缓冲区大小和排队规则（FIFO、FQ、FQ_CoDel和HHF）。结果显示：

使用FIFO时，大流量在所有CCAs下都会在某种程度上填满缓冲区，特别是使用填充缓冲区的CCAs（如Reno和Cubic）和大缓冲区时，短流量性能大幅下降。
FQ和FQ_CoDel通过分流显著改善了这一问题
HHF在解决缓冲区膨胀后，对短流量的减速效果与FQ相似，表明慢启动成为了主要因素。此外，HHF的配置需要根据不同环境调整，而FQ_CoDel则表现出更一致的效果。

总结

本文的评估框架的重点应用对象是经典的 Web 应用程序。另一个流行的应用程序是流媒体。虽然该框架可以使用速率受限的流对简单的流（例如音频流）进行建模，但这种方法通常不足以进行实际评估，尤其是对于视频内容。视频流通常使用自适应比特率方案并在会话期间改变视频质量。然而，吞吐量或流量公平性也不是适合视频的指标。对于视频来说，重要的是感知体验质量 (QoE)。有针对视频 QoE 和 QoE 公平性的应用程序特定指标。可以说，这些指标更适合评估视频流。另一种类型的应用程序是交互式应用程序，它们保持连接活动并在需要时传输数据。对于此类应用程序，可以评估活动连接内每次数据传输的减慢情况。