目录
声明
论文精度系列文章,是笔者个人对论文内容的私有解读,可能会在部分引用的基础上进行大量的个人理解与阐述,很可能会歪解论文原本的含义,因此推荐读者阅读论文原文,下方会提供地址链接。
前言
- 时间:2020 年 12 月
- 期刊:SIGCOMM
- 论文:
- https://zhuanlan.zhihu.com/p/420896292
- https://dl.acm.org/doi/pdf/10.1145/3341302.3342085
摘要
拥塞控制(CC)是在高速网络中实现超低延迟、高带宽和网络稳定性的关键。根据多年运行大规模高速 RDMA 网络的经验,我们发现现有的高速 CC 方案在实现这些目标方面存在固有的局限性。在本文中,我们提出了 HPCC(高精度拥塞控制),一种新的高速 CC 机制,它同时实现了这三个目标。
HPCC 利用网络遥测(INT)获得精确的链路负载信息并精确控制流量。通过解决诸如在拥塞期间延迟 INT 信息和对 INT 信息的过度反应等难题,HPCC 可以快速收敛以利用空闲带宽,同时避免拥塞,并且可以在网络队列中保持接近零的数据堆积以实现超低的延迟。HPCC 易于在 COTS 硬件中部署。我们使用 COTS 的可编程 NIC 和交换机实现 HPCC。
在我们的评估中,与 DCQCN 和 TIMELY 相比,HPCC 将流量完成时间缩短了 95%,即使在大规模 Incast(多对一的通信模式,“多打一”)情况下也几乎不会造成拥塞。
导言
在过去的十年中,数据中心网络的链路速度从 1Gbps 增长到 100Gbps,而且这种增长还在继续。超低延迟和高带宽是当今和未来高速网络的两个关键要求,越来越多的应用要求超低延迟和高带宽。
具体而言,作为世界上最大的云提供商之一,我们观察到数据中心的两个关键趋势,它们推动了对高速网络的需求。
- 第一个趋势是新的数据中心架构,如资源分解(Resource disaggregation)和异构计算。在资源分解中,CPU 需要与远程资源(如 GPU、内存和磁盘)进行高速联网。根据最近的一项研究,资源分解需要 3-5us 的网络延迟和 40-100Gbps 的网络带宽才能保持良好的应用程序级性能。在异构计算环境中,不同的计算芯片,如 CPU、FPGA 和 GPU,也需要高速互连,延迟越低越好。
- 第二个趋势是新的应用,如高速 I/O 介质上的存储,如 NVMe(非易失性存储器)和高速计算设备上的大规模机器学习训练,如 GPU 和 ASIC。这些应用程序周期性地传输大容量数据,其性能瓶颈通常在网络中,因为它们的存储和计算速度非常快。
考虑到主机中传统的基于软件的网络堆栈不再能够满足关键的延迟和带宽要求,将网络堆栈卸载到硬件中是高速网络中一个不可避免的方向。近年来,我们在数据中心部署了大规模网络,通过 RoCEv2(Converged Ethernet Version 2)实现 RDMA,作为我们当前的硬件卸载解决方案。
不幸的是,在运行大规模 RoCEv2 网络多年后,我们发现 RDMA 网络在协调低延迟、高带宽利用率和高稳定性方面面临着根本性的挑战。这是因为高速意味着流量以线路速率开始,并积极攫取可用网络容量,这很容易在大规模网络中造成严重拥塞。此外,高吞吐量通常会导致深度数据包排队,这会破坏延迟敏感流的性能以及网络处理意外拥塞的能力。我们强调实践中遇到的众多案例中的两个代表性案例,以证明这一困难:
-
案例 1:PFC(优先流量控制)风暴。一个使用 RDMA 的云存储(测试)集群曾经遇到了一场持续时间较长的 PFC 风暴导致的网络范围内的大幅度流量下降。这是由一个大型 Incast(“多打一”)事件和一个供应商错误触发的,该错误导致交换机无限期地发送 PFC 暂停帧。由于 Incast 事件和拥塞是这类集群中的常态,并且我们不确定是否会有其他供应商的错误导致 PFC 风暴,因此我们决定尽最大努力防止任何 PFC 暂停。因此,我们调整了 CC 算法以快速降低速率,并保守地增加速率,以避免触发 PFC 暂停。我们确实得到较少的 PFC 暂停(风险较低),但网络中的平均链路利用率非常低(成本较高)。
-
案例 2:惊人的长延迟。一个机器学习(ML)应用程序抱怨短消息的平均延迟 >100us(预期 RDMA 的尾部时延 <50us)。我们最终发现,延迟时间长的原因是网络中的队列主要被同一集群中的带宽密集型云存储系统占用。因此,我们必须通过将 ML 应用程序部署到新集群来分离这两个应用程序。考虑到 ML 应用程序不太需要带宽,新集群的利用率较低(成本较高)。
为了解决协调延迟、带宽/利用率和稳定性的困难,我们认为良好的 CC 设计是关键。这是因为 CC 是在高流量负载下避免数据包缓冲或丢失的主要机制。如果 CC 频繁失败,像 PFC 或数据包重传这样的备份方法要么会带来稳定性问题,要么会遭受巨大的性能损失。不幸的是,我们发现 RDMA 网络中最先进的 CC 机制,如 DCQCN 和 TIMELY,有一些基本的局限性:
-
收敛慢。对于粗粒度反馈信号,如 ECN 或 RTT,当前的 CC 方案不知道增加或减少多少发送速率。因此,他们使用启发式来猜测速率更新,并尝试迭代收敛到稳定的速率分布。这种迭代方法处理大规模拥塞事件的速度很慢,如案例 1 所示。
-
不可避免的数据包排队。DCQCN 发送方利用一位 ECN 标记来判断拥塞风险,TIMELY 发送方使用 RTT 的增加来检测拥塞。因此,发送方只有在队列建立后才开始降低流量。这些构建的队列会显著增加网络延迟,而这正是案例 2 中 ML 应用程序在开始时遇到的问题。
-
复杂的参数调整。当前 CC 算法用于调整发送速率的启发式算法有许多参数需要针对特定网络环境进行调整。例如,DCQCN 需要设置 15 个参数。因此,运营商在日常 RDMA 网络操作中通常面临复杂而耗时的参数调整阶段,这大大增加了导致不稳定或性能差的不正确设置的风险。
前面 3 个限制的根本原因是传统网络中缺少细粒度的网络负载信息 —— ECN 是终端主机可以从交换机获得的唯一反馈,RTT 是一种纯端到端的测量,没有交换机的参与。然而,这种情况最近发生了变化。随着新的交换 ASIC 中提供的网络遥测(INT,In-Network Telemetry)功能,在生产网络中获得细粒度网络负载信息并使用它改进 CC 已成为可能。
在本文中,我们提出了一种新的 CC 机制,HPCC(高精度拥塞控制),用于大规模高速网络。
HPCC 背后的关键思想是利用来自 INT 的精确链路负载信息来计算准确的流量更新。与通常需要大量迭代才能找到合适流速的现有方法不同,HPCC 在大多数情况下只需要一个流速更新步骤。使用 INT 提供的精确信息使 HPCC 能够解决当前 CC 方案中的三个限制。
首先, HPCC 发送端可以快速提高流量以实现高利用率,或降低流量以避免拥塞。其次,HPCC 发送方可以快速调整流量,使每条链路的输入速率略低于链路的容量,从而防止队列的建立,并保持较高的链路利用率。最后,由于发送速率是根据交换机上的直接测量值精确计算的,因此 HPCC 只需要 3 个独立的参数来调整公平性和效率。
另一方面,在 CC 中利用 INT 信息并不简单。设计 HPCC 有两个主要挑战。
- 首先,链路拥塞会延迟数据包上承载的 INT 信息,从而延迟流量降低以解决拥塞。在 HPCC 中,我们的 CC 算法旨在限制和控制繁忙链路的飞行中总字节数(total inflight bytes),防止发送方发送额外流量,即使反馈延迟。
- 第二,尽管所有 ACK 数据包中都包含 INT 信息,但如果发送方盲目地对所有信息做出快速反应,则可能会出现破坏性的过度反应(第 3.2 节)。我们的 CC 算法通过结合每次确认和每次 RTT 反应,选择性地使用 INT 信息,实现快速反应而无过度反应。
HPCC 满足了我们在大规模高速网络中同时实现超低延迟、高带宽和高稳定性的目标。此外,HPCC 还具有以下实用的基本特性:
- (i)部署容易:它只需要交换机中的标准 INT 功能(为了提高效率,需要一个简单的可选扩展),并且易于在 NIC 硬件中实现。
- (ii)公平:将效率与公平控制分开。它使用乘法递增和递减来快速收敛到每个链路上的适当速率,确保效率和稳定性,同时使用加法递增来实现长流的公平性。
HPCC 的稳定性和公平性在理论上得到了保证(附录A)。
我们使用 FPGA 在 COTS 可编程 NIC 上实现 HPCC,用 P4 可编程的 COTS 交换 ASIC 实现 HPCC。通过试验台实验和大规模仿真,我们表明,与 DCQCN、TIMELY 和其他替代方案相比,HPCC 对可用带宽和拥塞的反应更快,并保持接近零的队列。在我们的 32 台服务器测试床中,即使在 50% 的流量负载下,HPCC 也将队列大小保持在中值为零,将队列大小保持在第 99 个百分位的 22.9KB(仅 7.3us 排队延迟),与 DCQCN 相比,第 99 个百分位的延迟减少了 95%,而不牺牲吞吐量。在我们的 320 台服务器模拟中,即使在使用 DCQCN 和 TIMELY 会频繁发生 PFC 风暴的 incast 事件下,HPCC 也不会触发 PFC 暂停。
请注意,尽管 HPCC 是根据我们使用 RDMA 网络的经验设计的,但我们相信其见解和设计也适用于其他高速网络解决方案。