大规模 RDMA AI 组网技术创新：算法和可编程硬件的深度融合

目录

文章目录

• 目录
• [大规模 RDMA 组网挑战](#大规模 RDMA 组网挑战)
• 算法和硬件深度融合
• • 拥塞控制算法方面的创新
  • 硬件卸载方面的创新
• [微软云 DCQCN 量化拥塞通知](#微软云 DCQCN 量化拥塞通知)
• [谷歌云 TIMELY 基于 RTT 的拥塞控制](#谷歌云 TIMELY 基于 RTT 的拥塞控制)
• [阿里云 HPCC 高精度拥塞控制](#阿里云 HPCC 高精度拥塞控制)
• [AWS SRD 可扩展的可靠数据报协议](#AWS SRD 可扩展的可靠数据报协议)

大规模 RDMA 组网挑战

随着 AI 大模型技术的兴起，AI 训练依赖的 RDMA 网络需求强烈，实际上早在几年前各大公有云厂商就已经纷纷下场进行大规模 RDMA 组网的研究和落地，寄望在 RDMA 网络方面继续践行云计算的规模化效应和自服务销售模式。

目前主流的 RDMA 组网方案有 NVIDIA Infiniband 和 RoCEv2 这两种。对于 Infiniband RDMA 而言，其大规模组网的挑战主要有 2 个：一个是成本，IB 组网需要采购全套极其昂贵的专用网络设备，特别是具备 PFC（优先级流量控制）能力的交换机设备，运维成本也比较高；第二个就是规模，IB 组网规模受限，目前即便是国内的大型互联网公司也少有 2000+ 的组网规模。

而 RoCEv2 虽然同样具有规模限制的问题，但由于其成本和开放生态的优势，RoCEv2 和 RoCEv2-based 的自研协议目前成为了公有云厂商的大规模 RDMA 组网选择。而在性能方面，目前也有越来越多的研究数据表明 RoCEv2 和 IB 几乎可以达到一致。所以本文主要探讨 RoCEv2 的大规模组网问题。

算法和硬件深度融合

拥塞控制算法方面的创新

在《RoCEv2 高性能传输协议与 Lossless 无损网络》一文中已经介绍过 PFC 流量控制所存在的 Deadlock（死锁）和 PAUSE Storm（风暴），也介绍了 ECN 存在的拥塞控制滞后问题，这些问题都是限制 RoCEv2 组网规模的关键。

因此，目前业界解决大规模组网的关键切入点之一就是拥塞控制算法的优化和创新探索。随着 Lossless Network 技术的发展，越来越多 IT 巨头根据自身业务需求设计和开发拥塞控制算法。

硬件卸载方面的创新

随着 SmartNIC/DPU、白盒交换机/ P4 可编程交换机技术的成熟，无论是 Switch 还是 RNIC 都已经具备足够强大的计算能力，将创新性拥塞控制算法卸载到这些智能网络设备商是必然方向。

举例来说，大规模 RDMA 组网中的 L4 BTH QP 数量也会非常庞大，而 Traditional-RNIC 的 DRAM 空间却非常有限，基本都在几 M 或者数十 M 左右，因此 Cache 的数量也非常有限。所以该场景中，Traditional-NIC 需要依赖 Host DRAM 来存储 QP 相关的数据结构，而 RNIC 本地的 DRAM 只能作为 Cache。

但从技术层面看，实际上 Cache 的管理非常复杂，经常会引入性能问题，比如：Cache 换入换出引发 slow-receiver symptom 问题。更详细的：

1. RNIC 中包含的 MPT（Memory Protection Tables）和 MTT（Memory Translation Tables）模块是 2 个 Cached Page Table（缓存页表）元件，Page Table Entry 就是用来将 Virtual Address（虚拟内存）映射到相应的 Physical Address（物理内存）。
2. DMA 操作需要借助这两个 Tables 来将 VA 转换成 PA。
3. 而一旦需要 Cache 的信息超过了 RNIC DRAM 的大小，RNIC 则必须先通过 DMA 去 Host Main Memory 里面获取 MTT、MPT 然后才能进行 VA 到 PA 的转换最终完成 DMA 操作，这无疑会导致处理时间变长从而进一步引起链路抖动。

针对这个问题新型的 SmartNIC/DPU 正在提供越来越大的片上 CPU 和 DRAM 来进行存储和缓存 RDMA 相关的数据结构。

微软云 DCQCN 量化拥塞通知

2015 年，Microsoft 和 Mellanox 联合发布了 DCQCN（Data Center Quantized Congestion Notification）算法，是目前使用最广泛的网络拥塞控制算法之一，详见论文《Congestion Control for Large-Scale RDMA Deployments，SIGCOMM 2015》。

DCQCN 基于 ECN，融合了 QCN（Quantized Congestion Notification）和 DCTCP（Data Center TCP）算法，是一种 Rate-based（基于速率）的 E2E 拥塞控制算法。

DCQCN 定义了以下角色和功能定位：

1. RP（Reaction Point）：Sender RNIC，负责根据拥塞通知调整发送速率。
2. CP（Congestion Point）：Switch，负责检测拥塞并标记 ECN。
3. NP（Notification Point）：Receiver RNIC，负责生成 CNP 并反馈给 Sender。

DCQCN 和 ECN 的核心区别是前者设计了一套复杂的量化数据算法，在 RP、CP、NP 三个维度进行精细化的参数调控。

• CP 算法：与 DCTCP 算法相同，即：在出口队列中，如果队列长度超过阈值，则对到达的报文进行 ECN 打标，并根据实际情况调整 DCTCP 算法中定义的 Kmin、Kmax、Pmax 等参数。
• NP 算法：当一个带有 ECN 标记的报文到达 NP 时，表示网络拥塞了，NP 生成 CNP，NP 算法则规定了生成 CNP 的方式和时间。
• RP 算法：当 CNP 到达 RP 时，就开始根据 RP 算法中定义的降低公式 new_rate = old_rate * (1 - α/2) 进行降速和后续的恢复。其中 α是可动态调整的降速因子。

DCQCN 算法的改进在于通过一套参数提供了能够快速收敛到公平的带宽分配的量化数值算法，可避免 PFC 的不公平性问题，同时保证较低的缓存队列占用率和较少的缓存队列抖动情况。相对的不足是在一个大规模的组网中，每个节点可能需要配置数十个参数，全网的参数组合可能达到几十万。

谷歌云 TIMELY 基于 RTT 的拥塞控制

2016 年，Google 发布了自研的 TIMELY 算法，依赖于 Google 自研的 RNIC 设备，但却不依赖 Switch 提供额外的其他支持。详见论文《TIMELY: RTT-based Congestion Control for the Datacenter，SIGCOMM 2016》和《Swift: Delay is Simple and Effective for Congestion Control in the Datacenter，SIGCOMM 2020》。

TIMELY 算法的核心思想是通过测量报文的 RTT（端到端往返时间）来动态调整 Sender 的发送速率，基于 RTT 的变化进行梯度计算，进而根据梯度实现了基于速率（rate-based）的调速方法。

其运行原理包括以下几个关键步骤：

1. RTT 测量：Sender 在发送报文时记录 Timestamp，Receiver 收到报文后立即返回 ACK。Sender 通过计算发送和接收 ACK 的时间差，得到 RTT 值。
2. 拥塞检测：定义上水位和下水位，当 RTT 数值超上水位时，算法认为网络出现拥塞；当 RTT 数据超下水位时候，算法认为网络空闲。
3. 速率调整：当 RTT 超过阈值，Sender 根据情况减速或提速。
4. 平滑调整：为了避免速率波动过大，TIMELY 算法采用平滑调整机制，通过加权平均的方式梯度逐步调整发送速率。

TIMELY 算法的优势是简约，关注网络的 RTT 数值以及在 RNIC 上的算法实现，即能够根据网络状态动态调整发送速率；相对的缺点就是需要依赖高精度时钟，以实现准确的 RTT 测量，且算法的性能优化依赖于多个参数（如 RTT 阈值、速率调整系数等），调优过程复杂且需要经验。

阿里云 HPCC 高精度拥塞控制

2020 年，阿里云发布 HPCC（High Precision Congestion Control，高精度拥塞控制）算法，详见论文《HPCC: High Precision Congestion Control，SIGCOMM 2019》。

• https://zhuanlan.zhihu.com/p/420896292
• https://dl.acm.org/doi/pdf/10.1145/3341302.3342085

HPCC 算法旨在解决 DCQCN 和 TIMELY 算法中存在的局限性：

1. 收敛缓慢：对于ECN 或 RTT 这种粗粒度的通知反馈机制，Sender 无法快速且确切的计算出降速或增速的调整参数，并最终迭代收敛到稳定的速率。
2. 不可避免的数据包排队：DCQCN 使用 ECN 标记来识别拥塞，TIMELY 使用 RTT 数值增加来识别拥塞。这两个算法都是在 RDMA QP 建链后，Sender 基于反馈开始降速，这些前序报文必然会导致队列的堆积而增加例如网络延迟。
3. 复杂的参数调整：DCQCN 和 TIMELY 都有大量的参数可以调整，非常依赖性能调优和经验来确定参数。运维人员在 RDMA 网络维护中要面对复杂且耗时的参数调整，这会大大增加配置错误的风险，这些错误配置会导致不稳定或性能下降。

对于上述问题，HPCC 的核心思想是利用 INT（In-Network Telemetry，在网遥测）技术来提供精确的链路负载信息，并以此来计算出准确的 Sender 速率更新数值，并且实践发现 HPCC 在大多数情况下仅需要 Sender 更新一次速率，而无需迭代更新。此外还有以下特性：

1. HPCC Sender 可以快速提高流量以实现高利用率，或者降低流量以避免拥塞；
2. HPCC Sender 可以快速调整流量，以使每个链接的输入速率略低于链接的容量，保持高链接利用率；
3. 由于发送速率是根据 Switch 直接测量的结果精确计算得出的，HPCC 仅需要 3 个独立参数即可调整公平性和效率。

INT 的实现原理如下图，Sender 发出报文后，路径上的每个 Switch 都利用 INT 功能插入一些 Metadata，这些 Metadata 描述了特性 Switch Out-port 当前的拥塞情况。Receiver 收到报文后会将所有 Metadata 插入到 ACK 消息中再响应给 Sender，最终 Sender 根据 Metadata 决定如何调整流量。

从上述 INT 原理可知，HPCC 显然需要在 RNIC 和 Switch 等设备上进行报文编程。下面是 HPCC RNIC 的框图，可见采用了可编程 FPGA 芯片作为 HPCC 算法模块，位于 PCIe 和 MAC 模块之间。其中 CC 模块实现了 Sender 速率控制算法，它接收返回的 ACK 报文，根据 Metadata 调整发送窗口和速率，并且更新发送窗口和速率到流量调度器。

AWS SRD 可扩展的可靠数据报协议

AWS 认为 RoCEv2 中的 PFC 存在的队头阻塞、拥塞扩散和死锁问题从根本性上限制了规模，尤其在 AWS 的规模场景中。最终 AWS 选择设计自己的 HPC 网络传输协议 SRD（Scalable Reliable Datagram，可扩展的可靠数据报文）。

SRD 提供 HPC 应用程序所需的持续低延迟的前提下，同时还保持公共云的核心优势，例如：可扩展性、按需弹性容量和成本效益等。详见论文：

• https://aijishu.com/a/1060000000255945

在网络产品实现层面，SRD 通过 EFA（Elastic Fabric Adapter，弹性物理网络适配器）PCIe Pass-thought 提供给 EC2 实例，支持快速开通、弹性扩展。同时，EFA 提供了一个 User space 驱动程序，上层 Application 可以直接使用 OpenFabrics Alliance Libfabric SDK/API，比如：多种 MPI（OpenMPI、Intel MPI 和 MVAPICH）和 NCCL（NVIDIA 集体通信库）。

而在底层网络实现层面，SRD 实现了以下核心思想来最大化网络吞吐量并降低延迟：

1. 可控的 ECMP 多路径传输：SRD 依旧使用标准的 ECMP 实现负载均衡，同时通过 Sender Nitro DPU 编程报文特征（Packet Spraying，数据包喷涂）来控制 ECMP 路径的选择，以此来解决了 ECMP 路径冲突的问题。两个 EFA 实例之间可能有数百条路径。

2. 可靠的乱序交付保障：SRD 不关注分片报文的顺序，乱序交付消除了队头阻塞问题，显著降低了延迟。同时通过 Receiver Nitro DPU 强大的缓冲能力来进行快速重排，确保了数据的可靠性和完整性。EFA User space 驱动程序实现了重排，RDMA Application 无感。

3. 基于 RTT 的快速拥塞控制：SRD 同样采用了 RTT-based 的动态速率调整算法，可以快速响应网络拥塞或链路故障。

4. 硬件线速的转发性能：SRD 转发功能尽可能的卸载到了 Nitro DPU，避免主机操作系统和管理程序注入的性能噪音。

SRD 和 TCP、InfiniBand 网络的功能特征对比：