【论文阅读笔记】RDMA Transports in Datacenter Networks：Survey

原文链接：Hu, Jinbin, Houqiang Shen, Xuchong Liu, and Jin Wang. ‘RDMA Transports in Datacenter Networks: Survey’. IEEE Network 38, no. 6 (November 2024): 380–87. https://doi.org/10.1109/mnet.2024.3397781.

综述性质的文章，只是用于快速过一下 RDMA 技术。

一、RDMA Tech

1.1 Background

随着数据中心网络（DCN）带宽的快速增长，传统的 TCP 以及相关的通信协议的 I/O Bottleneck 成为制约其带宽的瓶颈。I/O Bottleneck ，即端到端通信过程中：

1. 发送方将应用层的 Buffer 复制到内核（也就是所谓的操作系统）中的 Socket Buffer ；
2. 然后在内核中进行一系列协议的封装等操作，这里涉及多层多个协议；
3. 封装完毕后，数据才被加载到网卡（NIC）的 Buffer 进行网络传输；
4. 接收方执行逆的解析过程，类似，此处略；

总而言之，数据移动和复制操作开销较大，根源就是数据采用内核传递。优化的思路也很明确，就是让内核不参与数据操作。

在引入 RDMA 之前，事实上还经过了 TCP Offloading Engine（TOE）、User-Net Networking(U-Net) 和 Virtual interface Architecture（VIA）技术。这边就不细说了。

1.2 Feature

RDMA（Remote Direct Memory Access，远程直接访存），允许服务器在主存中交换数据，而无需涉及任一服务器的处理器、缓存或操作系统。典型的数据流如下：

主要特点包括：

• 零拷贝（Zero-copy）：应用程序能够直接执行数据传输，在不涉及到网络软件栈的情况下。数据能够被直接发送到缓冲区或者能够直接从缓冲区里接收，而不需要被复制到网络层；
• 内核旁路（Kernel bypass）：应用程序可以直接在用户态执行数据传输，不需要在内核态与用户态之间做上下文切换；

1.3 Typical RDMA data flow

对上图的数据流进行一个简单的解释：

在建立 RDMA 连接后，在 Requester 和 Responder 都设置一个 Queue Pairs （QPs），或者说就是一个 Work Quene（WQ，工作队列），存放 Work Requests（WRs，工作请求），具体又分为：

• Send Quene（SQ，发送队列）；
• Recv Quene（RQ，接收队列）；

应用程序将任务打包为 Work Queue Elements（WQEs）并提交到 QP ，然后 RDMA 网卡（RDMA NIC, RNIC） 从 WQ 中获取任务并执行，执行完成后，将完成信息打包为 CQE 并提交到 CQ 。应用程序会轮询（Poll）CQ 以获取任务完成状态。

简而言之，数据的传送过程由网卡和应用程序间自行完成，无需经过 CPU 。

1.4 Challenge and Development

早期的 RDMA 建立在有损以太网的数据链路层，受限于网卡资源只实现了 GBN 协议，效率可想而知。

之后，RoCE 网络引入了 PFC（Priority Flow Control），实现了无损以太网上的基于优先级进行的流控机制。但 PFC 又有以下问题：

1. Head-of-Line Blocking（首部阻塞）：一个优先级通道上的队列满了后，交换机给上游发送 Pause 帧，导致所有共享该队列的流都会被阻塞，无论它们是否导致拥塞。
2. Congestion Spreading（拥塞蔓延）：当下游某个节点由于拥塞发送 PFC pause，上游节点也会因阻塞而发生拥塞，从而不断向更上游传播。（链式传播）
3. Deadlock（死锁）：某些拓扑中多个路径互相依赖，当每个节点都在等待对方释放资源时，就可能进入“死锁”；

可以发现问题多多少少都出现在拥塞感知和控制身上，后续诞生的一系列算法主要就是在解决拥塞控制的问题。

二、Single-Path CongestIon Control

2.1 Background and Motivation

• DCN 特点：存在短时突发流量，易引发瞬时拥塞；
• 传统的 GBN 协议对丢包敏感；
• 缓冲区排队问题（以及溢出后的丢包）；
• PFC 的相关问题；

2.2 Challenge

1. timely control congestion（及时拥塞控制）：DCN 中大部分流仅需少量时间即可完成，小于从感知拥塞到反馈拥塞需要的时间；
2. accurately control congestion（精确拥塞控制）：说白了，就是现在的拥塞信号信息熵太高，没办法精确确定拥塞源和信息；
3. performing accurate rate adjustment：实现精准的拥塞控制，即对发送速率的调节；

2.3 Existing Solutions

2.3.1 Lossless RDMA Networks

1. DCQCN：（典中之典，课内也教了）利用显式拥塞通知（ECN） 标记的数据包来指示交换机队列长度，并通过接收端生成的拥塞通知报文（CNP）通知发送端调整发送速率；
2. TIMELY && Swift：利用硬件网卡精确测量 RTT ，Swift 主要进一步解决了 TIMELY 中 RTT 抖动问题；
3. HPCC：利用新型交换专用集成电路（ASIC）支持的带内网络遥测（INT）技术，无需逐步演进和收敛过程即可获取精确的链路利用率并计算准确的流速率。HPCC 保持近乎零的队列状态，无丢包且不触发 PFC ，因此短流的完成时间（FCT）接近基础 RTT ；

以上 3 种一个通病是还是没有区分真正拥塞的流和其他流，它们都通过某些感知技术感知整个链路，对所有流一视同仁。

4. PCN：首个能识别实际拥塞流并对拥塞与非拥塞流实施差异化速率调整的拥塞控制协议。采用接收端驱动的速率调整机制，直接抑制输入流量以匹配瓶颈链路容量，而非逐轮探测可用带宽，调节速率快；

2.3.2 Lossy RDMA Networks

有损以太网还需要进一步考虑数据丢包恢复问题。代表协议是 IRN ，它重新设计了一种更高效的数据包丢失恢复机制（优于 PFC ），并通过网络的带宽延迟积（BDP）在网卡上以低开销限制每个流的在途数据包数量。缺陷是收敛性 and 公平性。

2.4 Future Opportunity

简单对论文进行了一定概括并结合了一些思考。

1. 降低信息熵：综合利用多种拥塞信号，并开发配套的算法和硬件，以细粒度方式区分真实拥塞流及实际发生拥塞的位置；
2. 提前预测：解决突发流量问题，即大量小流量会在拥塞控制机制生效前发送全部数据，这就需要对流量实现预测。预测和捕捉流量特征，这真是机器学习的用武之处了；
3. 设计更优的硬件传输协议：基于硬件卸载技术以及现场可编程门阵列（FPGA）等硬件充足的片上计算与存储资源，设计出更优的硬件传输协议来实现低 CPU 开销的拥塞控制；

与我的文章 TCP拥塞控制算法的前世与今生 的一些思考也是不谋而合了（笑）。

三、Multi-Path Transport

3.1 Background and Motivation

多路并行传输情况下：

• 检测和感知 PFC 的 Pause 不易；
• 协议栈下沉至网卡，导致高内存占用；
• 传统 RDMA 对丢包敏感，而多路并行传输难以保证数据包按序到达；

3.2 Challenge

简单来说，多路并行传输中，需要分别检测并控制多条路径上的拥塞状态，实现拥塞隔离，这间接导致了硬件资源的开销。同时，不同路径的链路状态不同，数据包可能乱序到达，这也是需要解决的问题。

3.3 Existing Solutions

现有解决方案主要围绕以下两方面展开：multi-path congestion control（多路拥塞控制） 和 load balancing mechanisms（负载均衡） 。

再介绍几个代表性协议：

1. MP-RDMA（Multi-Path RDMA）：其提出了 3 个新技术：
   1. 多路径 ACK-clocking 机制：简单来说，就是多个子路径共享一个全局拥塞控制器（只有一个速率调节器）；发送端通过观察各路径的拥塞标记，对各路径做出权重分配，实现“拥塞感知负载均衡”；
   2. 乱序感知的路径选择机制 + 位图乱序跟踪：屏蔽高延迟路径，使用 bitmap表示滑动窗口内每个包的到达情况，开销低；
   3. 内存同步机制：保证有序写入；
2. PLB && Proteus；
3. ConWeave；

3.4 Future Opportunity

1. 多路径的拥塞控制：核心是解决智能调节发送速率并分配到合理的路径上的问题；
2. 负载均衡：通过交换机重新路由流量；