【论文】利用RDMA技术提升Azure存储能力
摘要
随着公有云中分离式存储（disaggregated storage）的广泛部署，网络在构建高性能与高可靠性的云存储服务中扮演着核心角色。在Azure平台，我们选择了远程直接内存访问（RDMA）作为数据传输方式，旨在将其应用于存储的前端（计算虚拟机与存储集群间）及后端（存储集群内部）流量，以充分发挥其优势。鉴于计算和存储集群可能分散在Azure区域内的不同数据中心，我们需要在区域范围支持RDMA技术。
本文介绍了我们在Azure中部署区域范围内（intra-region）RDMA以支持存储工作负载的经验。面对基础设施的高度复杂性和异构性所带来的新挑战，如不同RDMA网卡（NIC）间的互操作性问题，我们对网络基础设施进行了多项优化调整。目前，Azure中约70%的流量已通过RDMA传输，且区域内RDMA已在所有Azure公共区域得到全面支持。RDMA技术的引入，显著提升了硬盘I/O性能并减少了CPU核心占用。
1. 引言
高性能与高可靠性的存储服务是公有云不可或缺的基础服务之一。近年来，随着存储介质与技术的飞速发展[73]，客户对云端存储性能的要求也日益提高。鉴于公有云中独立存储架构的广泛应用[35, 46]，连接计算与存储集群的网络成为了制约云存储性能的关键因素。尽管Clos网络架构提供了充足的带宽，但传统的TCP/IP协议栈因高处理延迟、低单核吞吐量及高CPU占用率而不适合此类应用场景。
在此背景下，远程直接内存访问（RDMA）成为了一个颇具前景的解决方案。通过将网络处理任务卸载至NIC硬件，RDMA实现了超低延迟、高吞吐量及近乎零的CPU占用。此外，RDMA还减少了单台服务器用于网络处理所需的CPU核心数量，这些节省下来的核心可用于支持更多客户虚拟机（VM）或增强应用处理能力。
为了全面发挥RDMA的优势，我们计划将其应用于存储的前端与后端流量。这与以往仅针对存储后端应用RDMA的做法不同[46]。在Azure环境中，由于容量规划的需要，计算和存储集群往往分布在同一区域内的不同数据中心，这就要求我们的存储工作负载必须支持区域范围的RDMA。
本文总结了我们在Azure内部署区域内RDMA以支持存储工作负载的实践经验。与以往的RDMA部署相比[46, 50]，区域范围部署面临着Azure区域内高复杂性与异构性所带来的诸多新挑战。随着Azure基础设施的不断演进，不同集群可能采用了多样化的RDMA NIC。尽管这些NIC均支持DCQCN[112]，但其实现方式却大相径庭，导致了NIC间通信时的多种不良行为。此外，来自多个供应商的异构交换机软硬件也增加了我们的运维难度。更值得注意的是，连接数据中心的长距离线缆在区域内引发了显著的传播延迟及往返时间（RTT，Round-Trip Time）波动，为拥塞控制带来了新的挑战。
为应对这些挑战，我们对网络基础设施进行了全面优化，从应用层协议到链路层流量控制均进行了针对性调整，以确保Azure存储流量能够安全、高效地通过区域内RDMA传输。我们开发并集成了基于RDMA的存储协议优化与故障转移支持（§4），构建了RDMA Estats以监控主机网络堆栈状态（§5），利用SONiC在不同交换机平台上实施了统一的软件堆栈（§6），并通过更新NIC固件以统一DCQCN行为、结合使用基于优先级的流量控制（PFC）与DCQCN实现了高吞吐量、低延迟及近乎零的数据包丢失（§7）。
自2018年起，我们逐步为存储后端流量启用了RDMA；至2019年，我们又将RDMA拓展至客户前端流量。图1展示了2023年1月18日至2月16日期间Azure所有公共区域的流量统计数据。截至2023年2月，Azure中约70%的流量已通过RDMA传输，且区域内RDMA已在所有Azure公共区域得到全面支持。RDMA技术的成功应用，不仅显著提升了硬盘I/O性能，还有效减少了CPU核心的占用。
2. 背景
本章首先概述了Azure的网络与存储架构背景，随后深入探讨了启用区域内RDMA的动机及所面临的挑战。
2.1 Azure区域的网络架构设计
机架（Rack）：包含一台T0交换机及其直接连接的服务器集合。 集群（Cluster）：由连接至同一组T1交换机的多个机架组成。 数据中心（Datacenter）：则是由连接至同一组T2交换机的多个集群构成。 区域（Region）：通过一组RH交换机相互连接的数据中心集合。值得注意的是，与数据中心内部短距离（几米至几百米）的链路相比，T2与RH交换机之间通过长达数十公里的长距离链路相连。
关于此架构，有两点需特别关注：首先，由于T2与RH之间长距离链路的存在，导致基本的往返时间（RTT）在数据中心内部可能仅为几微秒，而在整个区域内则可能延长至最多2毫秒。其次，我们采用了两种不同类型的交换机：T0与T1层使用的是“披萨盒式”交换机（pizza box switches），这种交换机通常配备单个交换机ASIC并拥有较浅的数据包缓冲区[31]；而T2与RH层则采用机箱式交换机，它们由多个交换机ASIC构建而成，并具备基于虚拟输出队列（VoQ）架构的深层数据包缓冲区[3,6]。
2.2 Azure存储的高层架构设计
在Azure中，为了降低成本并实现自动扩展能力，我们采用了计算与存储资源解耦合的设计策略。Azure主要包含两种类型的集群：计算集群与存储集群。虚拟机（VM）在计算集群中创建，但其虚拟硬盘（VHD）的实际存储则位于存储集群之中。
图3展示了Azure存储的高层架构概览[35]。Azure存储系统被划分为三个层次：前端层（Frontend Layer）、分区层（Partition Layer）以及流层（Stream Layer）。流层是一个仅附加的分布式文件系统，它负责在硬盘上存储数据并进行复制以确保数据的持久性，但它并不理解更高层次的存储抽象（如Blobs、表和VHD）。分区层则能够理解不同的存储抽象，管理存储集群中所有数据对象的分区，并在流层之上存储对象数据。分区层和流层的守护进程分别被称为分区服务器（Partition Server, PS）和区段节点（Extent Node, EN），它们共同部署在每个存储服务器上。前端（FE）层由一组服务器组成，这些服务器负责对传入的请求进行认证，并将其转发给相应的PS。在某些情况下，FE服务器还可以直接访问流层以提高处理效率。
当VM需要写入硬盘数据时，运行在计算服务器主机域中的硬盘驱动程序会向相应的存储集群发送I/O请求。FE或PS将解析并验证这些请求，然后生成对流层中相应EN的请求以执行数据写入操作。在流层中，文件实际上是由一系列称为“区段”的大型存储块有序排列而成。写入文件时，数据会被附加到当前活动区段的末尾，并且该区段会在存储集群中被复制三次以确保数据的持久性。只有在收到所有EN的成功响应后，FE或PS才会将最终响应发送回硬盘驱动程序。相比之下，硬盘读取操作则有所不同。FE或PS会从任意EN副本中读取数据，并将读取结果发送回硬盘驱动程序。
除了面向用户的工作负载外，存储集群还承担着许多后台任务，如垃圾回收和纠删码处理[57]。我们将存储流量分为前端流量（发生在计算服务器与存储服务器之间，如VHD的写入和读取请求）和后端流量（发生在存储服务器之间，如数据复制和硬盘重建）。这些存储流量具有类似汇聚的特性。一个典型的例子是数据重建过程，它在流层中执行[57]。流层会将封闭的区段进行纠删码编码，生成多个碎片，并将这些编码后的碎片分发到不同的服务器进行存储。当用户尝试访问因故障而不可用的碎片时，流层会从多个存储服务器中读取其他碎片以重建目标碎片。
2.3 部署区域内RDMA的动机
近年来，存储技术取得了显著进步。例如，非易失性存储器快速接口（NVMe）固态硬盘（SSD）能够提供高达数十Gbps的吞吐量，并且请求延迟仅为几百微秒[105]。随着这一技术趋势的发展，许多客户在云端也对存储性能提出了类似的高要求。
高性能云存储解决方案[1,4]由于其独特的分离式（disaggregated）和分布式（distributed）存储架构（§2.2），对底层网络性能提出了严苛要求。尽管数据中心网络普遍具备充足的带宽能力，但操作系统内核中的传统TCP/IP协议栈，因其较高的处理延迟和低单核吞吐量，往往成为性能提升的瓶颈。更棘手的是，该协议栈的性能还受制于操作系统的调度策略。为确保存储性能的可预测性，我们不得不在计算和存储节点上预留充足的CPU核心，以应对存储工作负载高峰时的TCP/IP处理需求。然而，这种做法减少了可用于向客户提供的虚拟机（VM）的处理能力，进而推高了云服务的整体运营成本。
鉴于上述局限，远程直接内存访问（RDMA）技术应运而生，成为一项极具前景的解决方案。通过将网络协议栈卸载至网卡硬件，RDMA实现了微秒级的低处理延迟和接近线速的高吞吐量，同时几乎不占用CPU资源。除了显著的性能优势外，RDMA还减少了服务器上为网络处理而预留的CPU核心数量，这些节省下来的核心可以直接用于客户VM的部署或存储请求的处理。
为充分发挥RDMA的优势，我们决定在存储系统的前端和后端流量中均启用RDMA。后端流量的RDMA启用相对简单，因为主要发生在存储集群内部。然而，前端流量则跨越了区域内的不同集群，即便我们尝试通过共址计算和存储集群来最小化延迟，但由于容量需求，它们有时仍可能分布在区域内的不同数据中心。因此，我们的存储工作负载高度依赖于区域范围RDMA的支持。
2.4 面临的挑战
在推进区域范围RDMA部署的过程中，我们遭遇了诸多挑战，这些挑战主要源于实际运营中的多重约束。
实际考虑：我们的目标是在不改变现有基础设施大框架的前提下，实现区域内RDMA的启用。尽管在NIC驱动程序、交换机操作系统及存储栈等软件层面的重配置和升级上我们拥有一定的灵活性，但从运营角度来看，替换底层硬件（如NIC和交换机）并不现实。因此，我们选择了基于通用以太网的RDMA v2（RoCEv2）[29]，以确保与现有IP路由网络的兼容性（§2.1）。值得注意的是，我们在项目启动前已部署了大量第一代RDMA NIC，这些NIC在固件层面实现了带有限处理能力的回退N（go-back-N）重传机制。实测发现，其恢复丢失数据包的时间长达几百微秒，性能甚至不及TCP/IP软件栈。鉴于这一严重性能退化，我们决定采用基于优先级的流控（PFC，Priority-based Flow Control）[60]技术，以消除因网络拥塞而导致的数据包丢失问题。
面临的挑战：在此项目之前，我们已在部分集群中部署了RDMA以支持Bing服务[50]，并积累了丰富的经验。然而，与集群内RDMA部署相比，区域内RDMA部署因基础设施的高度复杂性和异构性而面临诸多新挑战：
异构NIC问题：云基础设施的演进往往采用增量方式，不同集群或机架可能采用最新一代的服务器硬件[91]，导致一个区域内存在多种类型的NIC。我们已部署了来自同一供应商的三代通用RDMA NIC（Gen1、Gen2、Gen3），但每代NIC在DCQCN的实现上存在差异，这引发了不同代NIC间通信时的诸多不期望交互。
异构交换机难题：类似于服务器基础设施，我们持续部署新型交换机以降低成本和提升带宽能力。然而，这些交换机来自不同供应商，采用了不同的ASIC和操作系统，极大增加了运营复杂度。包括缓冲区架构、大小、分配机制、监控和配置等在内的多个方面均存在供应商特异性。
异构延迟挑战：如第2.1节所述，由于T2和RH交换机间长距离链路的存在，区域内RTT差异显著，从几微秒到2毫秒不等。这不仅重新凸显了RTT公平性的重要性，而且长距离链路的大传播延迟也对PFC的前导空间构成了巨大压力[12]。
与公有云中的其他服务相似，高可用性、故障诊断及可维护性同样是我们RDMA存储系统的核心关注点。为确保高可用性，我们始终为潜在的“零日”（zero-day）问题做好准备，即便在测试环节已投入大量资源。系统需具备检测性能异常的能力，并在必要时自动触发故障转移机制。为便于故障理解和调试，我们构建了细粒度的遥测系统，以实现对端到端路径中各组件的清晰监控。此外，系统还需具备出色的可维护性，确保在NIC驱动程序更新和交换机软件升级过程中，存储工作负载能够持续稳定运行。
3. 概述
为了安全地让Azure存储支持RDMA功能，我们对网络基础设施进行了全面的改造，从应用层协议到链路层流控均有所涉及。我们开发并成功集成了两种基于RDMA的协议——sU-RDMA（§4.1）和sK-RDMA（§4.2），它们分别用于后端和前端通信，无缝融入现有存储栈中。此外，我们在存储协议与NIC之间部署了RDMA监控系统Estats（第5章），通过精确的成本细分，让我们能够深入了解主机网络栈的运行状态。
在网络层面，我们结合了PFC（优先级流控）和DCQCN[112]技术，以实现高吞吐量、低延迟且几乎无丢包的拥塞控制。DCQCN和PFC是项目启动时市场上最先进的商业解决方案。为了优化客户体验，我们采用双优先级策略来隔离存储的前端与后端流量。针对交换机异构性问题，我们开发并部署了SONiC[15]，以确保不同交换机平台上的软件栈保持一致（§6）。同时，为解决异构NIC间的互操作性问题，我们更新了NIC固件，统一了DCQCN行为（第7章），并精细调整了DCQCN及交换机缓冲参数，以适应不同场景下的性能需求。
3.1 使用监控机制应对PFC风暴
PFC是防止拥塞导致数据包丢失的有效手段。然而，故障的NIC或交换机可能在无拥塞情况下持续发送PFC暂停帧，长时间完全阻塞对端设备，甚至引发网络范围内的PFC风暴。为此，我们在每个交换机及T0交换机与服务器间的FPGA卡上部署了PFC监控机制[11, 50]。一旦发现某个队列暂停时间过长（如数百毫秒），该机制将立即禁用PFC并丢弃该队列上的所有数据包，从而有效遏制PFC风暴的蔓延。
3.2 安全性考量
鉴于RDMA在受信任环境中的使用特性，我们将其限制在存储服务器、计算服务器主域、交换机及链路等受保护范围内，以防范[69, 94, 104, 109]中提及的安全隐患。
4. 基于RDMA的存储协议
本章详细介绍了两种基于RDMA可靠连接（RC，Reliable Connections）的存储协议：sU-RDMA和sK-RDMA。两者均旨在提升性能的同时，保持与传统软件栈的良好兼容性。
4.1 sU-RDMA
sU-RDMA[87]专为存储后端（存储到存储）通信设计。图4展示了包含sU-RDMA模块的存储后端网络栈架构。Azure存储网络协议作为一种直接服务于应用程序的RPC协议，用于传输请求和响应对象。它通过套接字API实现连接管理、消息发送与接收。
当RDMA应用无法直接写入现有内存区域（MR，memory regions）时，需将应用缓冲区注册为新MR或复制数据至现有MR，这两种操作均会带来较大的延迟开销，需尽量减少。 如果我们使用RDMA的“发送”（Send）和“接收”（Receive）功能，接收方必须预先发布足够的“接收”（Receive）请求。 RDMA的发送方和接收方必须就传输的数据大小达成一致。
为降低内存注册开销（这在处理小消息时尤其显著[44]），sU-RDMALib维护了一个公共缓冲池，用于预注册内存，该池由多个连接共享。此外，sU-RDMALib还提供API，允许应用请求和释放已注册的缓冲区。为避免NIC上的内存转换表（MTT，Memory Translation Table）缓存未命中[50]，sU-RDMALib从内核分配大块内存并进行注册。此缓冲池可根据运行时需求自动扩展。为防止接收方过载，sU-RDMALib实现了一种基于信用的流控机制，由接收方驱动，其中信用代表接收方已分配的资源（如可用缓冲区和已发布的接收请求）。接收方定期向发送方发送信用更新消息。
小消息模式：直接利用RDMA发送与接收功能传输数据。 中等消息模式：发送方通过RDMA“写”（Write）请求传输数据，并以“写完成”“发送”（Send）请求通知接收方。 大消息模式：发送方首先通过RDMA“发送”（Send）请求向接收方传递本地数据缓冲区的描述符，随后接收方发起“读取”（Read）请求拉取数据，并在数据读取完成后，通过“读取完成”“发送”（Send）请求告知发送方。
在sU-RDMALib的基础上，我们构建了模块以实现TCP与RDMA之间的无缝动态转换，这对于保障系统的故障切换与恢复能力至关重要。转换过程采取渐进式策略，即定期关闭一小部分现有连接，并基于新的传输需求建立新的连接。
与TCP不同，RDMA采用的是基于速率的拥塞控制机制[112]，而非追踪在途数据包的数量（即窗口大小）。因此，RDMA有时可能会注入过多的在途数据包，从而触发PFC（优先级流控）机制。为解决这一问题，我们在Azure存储网络协议中引入了静态流控机制，将消息划分为固定大小的块，并限制每个连接仅允许一个在途数据块。这种分块技术不仅在高并发场景下显著提升了性能，而且其引入的CPU开销几乎可以忽略不计。
4.2 sK-RDMA
sK-RDMA专为存储前端（计算到存储）通信设计。与在用户空间运行的sU-RDMA不同，sK-RDMA在内核空间执行RDMA操作，这使得运行在计算服务器主域中的硬盘驱动程序能够直接利用sK-RDMA发起网络I/O请求。sK-RDMA不仅继承了Server Message Block (SMB) Direct[14]的优势，还进一步扩展了其功能，提供了类似套接字的内核模式RDMA接口。与sU-RDMA相似，sK-RDMA同样支持基于信用的流控机制以及RDMA与TCP之间的动态切换。
图5展示了sK-RDMA在读写硬盘时的数据流程。计算服务器首先发起快速内存注册（FMR，Fast Memory Registration）请求以注册数据缓冲区，随后发布RDMA发送请求，将包含硬盘I/O命令及FMR注册缓冲区描述的请求消息传输至存储服务器。根据InfiniBand（IB）规范，NIC会等待FMR请求完成后再处理后续发布的请求，确保请求消息在内存注册成功后才被推送到网络上。数据传输则由存储服务器根据收到的请求，通过RDMA读取或写入操作完成。传输结束后，存储服务器通过带失效的RDMA发送将响应消息返回给计算服务器。
为确保数据传输的完整性，sK-RDMA与sU-RDMA均在所有应用数据上实施了循环冗余校验（CRC，Cyclical Redundancy Check）。在sK-RDMA中，计算服务器负责计算硬盘写入数据的CRC，并将这些CRC值包含在请求消息中发送给存储服务器进行验证。对于硬盘读取操作，则由存储服务器计算CRC并随响应消息返回给计算服务器进行验证。
5. RDMA Estats
为了理解并调试潜在故障，我们迫切需要一款细粒度的遥测工具来捕捉端到端路径中每个组件的行为细节。尽管市场上已存在多款用于诊断交换机和链路故障的工具[51,97,114]，但它们在提供主机端RDMA网络栈的深入可视化方面却显得力不从心。
受TCP诊断工具的启发[79]，我们开发了RDMA扩展统计（Estats，RDMA Extended Statistics），旨在帮助用户诊断网络和主机中的性能问题。当RDMA应用程序表现不佳时，RDMA Estats能够迅速定位瓶颈所在——无论是发送方、接收方还是网络本身。
RDMA Estats不仅收集常规的计数器数据（如发送/接收字节数和NACK数量），还提供了每个RDMA操作的细粒度延迟分解。具体而言，请求方NIC会在工作队列元素（WQE，Work Queue Element）穿越传输管道的过程中，在多个测量点记录时间戳。当接收到响应（ACK或读取响应）时，NIC则会在接收管道中的相应测量点再次记录时间戳（如图6所示）。在Azure环境中实施RDMA Estats时，我们定义了以下关键测量点：
T1：WQE发布时间戳，记录WQE被发布到提交队列时的主机处理器时间。
T5：CQE生成时间戳，标记NIC生成完成队列元素（CQE,Completion Queue Element）的瞬间。
T6：CQE轮询时间戳，反映软件轮询CQE时的主机时间。
在Azure环境中，NIC驱动程序会基于上述时间戳报告各种延迟数据。举例来说，T6-T1反映的是RDMA消费者所体验到的操作延迟，而T5-T1则是NIC层面的延迟。用户模式代理会根据连接类型、操作种类以及操作的成功或失败状态，对延迟样本进行分组，并为每组生成延迟直方图。默认情况下，每个直方图覆盖一分钟的时间范围。随后，这些直方图的分位数和汇总统计数据会被传送到Azure的遥测系统中。随着诊断功能的不断完善，我们在用户模式代理中增加了功能，以便在高延迟事件期间收集和上传NIC及QP（队列对）的状态转储信息。此外，我们还扩展了用户模式代理的事件触发数据收集范围，以涵盖非RDMA特定事件（如影响连接的服务操作）中的NIC统计数据和状态转储。
收集延迟样本会不可避免地增加WQE（工作队列元素）发布和完成处理路径上的开销，这些开销主要源自保持NIC和主机时间戳同步的需求。为了减轻这一负担，我们开发了一种时钟同步机制，旨在通过减少读取NIC时钟寄存器的频率来降低开销，同时保持较低的时间偏差。
RDMA Estats显著缩短了存储性能事件的调试和缓解时间，因为它能够迅速排除或确认网络延迟问题。在后续章节中（§8.3），我们将分享利用RDMA Estats诊断FMR（快速内存注册）隐藏围栏错误的实践经验。
6. 交换机管理
6.1 利用SONiC应对异构性挑战
我们的RDMA部署高度依赖于交换机的支持，但不同供应商的异构交换机ASIC和操作系统给网络管理带来了诸多挑战。商业交换机操作系统为满足广泛客户需求而设计，这导致软件栈复杂且功能更新缓慢。此外，不同交换机ASIC的缓冲架构和机制各异，增加了Azure RDMA部署的认证和测试难度。
为应对这些挑战，我们采取了双管齐下的策略：一方面，与供应商紧密合作，明确功能需求、制定测试计划，并深入了解其底层实现；另一方面，与多方合作，开发并部署了SONiC（云开放网络的软件，Software for Open Networking in the Cloud）这一内部跨平台交换机操作系统[15]。SONiC基于SAI（交换机抽象接口，Switch Abstraction Interface）[20]，通过简化和统一的软件栈来管理来自不同供应商的异构交换机。它将传统单体交换机软件拆分为多个容器化组件，不仅实现了清晰的隔离，还提升了开发的灵活性，允许按需定制功能，从而构建“精简版”软件栈。
6.2 SONiC在“披萨盒式”交换机上的缓冲管理与配置实践
SONiC提供了RDMA部署所需的一系列关键功能，包括ECN标记、PFC、PFC监控器等（详见§3.1），以及共享缓冲模型。由于篇幅所限，这里仅简要介绍SONiC在“披萨盒式”交换机（用于T0和T1拓扑[§2.1]）上的缓冲模型和配置实践。详细缓冲配置示例请参阅附录§A。
通常，我们在“披萨盒式”交换机上配置三个缓冲池：用于所有数据包的入口控制的ingress_pool、用于有损数据包的出口控制的egress_lossy_pool，以及用于无损数据包的出口控制的egress_lossless_pool。需要注意的是，这些缓冲池和队列并非由独立的物理缓冲器支持，而是基于单个物理共享缓冲器的计数器实现，用于执行入场控制。每个计数器仅由映射到它的数据包更新，且同一数据包可能同时映射到多个队列和缓冲池。例如，从源端口s到目的端口d、优先级为p的无损（或有损）数据包会更新入口队列（s，p）、出口队列（d，p）、ingress_pool以及相应的egress_lossless_pool（或egress_lossy_pool）。只有同时通过入口和出口入场控制的数据包才会被交换机接收。计数器的增减依据是数据包的大小，我们采用动态阈值和静态阈值来限制队列长度。
在“披萨盒式”交换机上，我们仅对无损流量实施入口控制，对有损流量则实施出口控制。若交换机缓冲总容量为B，则ingress_pool的大小必须小于B，以确保有足够的PFC头部缓冲区（详见§7.1）。当入口无损队列达到动态阈值时，该队列会进入“暂停”状态，交换机将向上游设备发送PFC暂停帧。此后到达的无损队列数据包将使用PFC头部缓冲区而非ingress_pool。相反，对于入口有损队列，我们设置了一个静态阈值，其值等于交换机缓冲总大小B。由于有损队列长度无法达到交换机缓冲总大小，因此有损数据包可以绕过入口入场控制。
在出口端，有损和无损数据包分别被映射到egress_lossy_pool和egress_lossless_pool。我们将egress_lossless_pool的大小以及出口无损队列的静态阈值设置为B，以确保无损数据包能够绕过出口入场控制。相反，egress_lossy_pool的大小则被限制在不大于ingress_pool的范围内，因为有损数据包不应占用入口处的任何PFC头部缓冲区。出口有损队列则配置为使用动态阈值[40]来管理数据包的丢弃。
6.3 使用SONiC进行RDMA功能测试
我们通过实施每晚测试来持续监控SONiC交换机的性能与质量。在本节中，我们将简要介绍如何利用SONiC交换机来测试RDMA功能的方法。
基于软件的测试
我们采用了Packet Testing Framework（PTF）[10]来开发针对SONiC的通用测试用例。虽然PTF主要用于测试数据包转发行为，但测试RDMA功能需要我们进行额外的设计和实施。
受软件调试中断点的启发，我们设计了独特的测试方法。为了为交换机设置“断点”（breakpoint），我们首先利用SAI API来阻塞交换机端口的传输。随后，我们生成一系列指向被阻塞端口的数据包，并捕获交换机的一个或多个状态快照（如缓冲区水位），这与软件调试中的变量值转储类似。之后，我们释放端口并捕获接收到的数据包。通过对比分析捕获的交换机快照和接收到的数据包，我们能够判断测试是否通过。这种方法已被我们用于测试缓冲管理机制、缓冲相关计数器以及数据包调度器等关键功能。
基于硬件的测试
尽管上述软件测试方法为我们提供了交换机状态和数据包微行为的深入洞察，但它仍无法满足某些测试对严格性能的要求。例如，为了测试PFC监控器[50]的性能，我们需要能够高速生成连续的PFC暂停帧，并精确控制其间隔，因为每个PFC帧都会强制产生短暂的暂停。
为了满足这种对性能敏感的测试需求，我们构建了一个基于硬件的测试系统，该系统利用硬件可编程流量生成器[9]来实现对流量生成的微秒级甚至纳秒级控制，并具备高分辨率地测量数据平面行为的能力。该系统专注于测试PFC、PFC监控器、RED/ECN标记等关键功能。
截至2023年2月，我们已为RDMA功能构建了32个软件测试用例和50个硬件测试用例。这些测试用例的详细文档和实现代码可在[18]中找到。
7. 拥塞控制
我们采用PFC和DCQCN相结合的策略来缓解网络拥塞。在本章中，我们将讨论如何在区域范围内扩展这两种技术的应用。
7.1 长链路上的PFC扩展
当入口队列暂停上游设备时，需要一个专用的头缓冲区来暂存正在传输的数据包，直到PFC暂停帧在上游设备上生效[50,112]。理想的PFC头缓冲区大小取决于多种因素，如链路容量和传播延迟[12]。此外，交换机对头缓冲区的总需求还与无损优先级的数量成正比。
为了将RDMA从集群规模[46,50]扩展到区域规模，我们必须处理T2和RH之间（数十公里）以及T1和T2之间（数百米）的长链路，这些链路对PFC头缓冲区的需求远超集群内链路。考虑到生产环境中T1交换机的实际情况，我们可以保留一半的总缓冲区用于PFC头缓冲区和其他用途。然而，在T2和RH，由于机箱交换机的高端口密度（数百个）和长距离链路的特性，我们需要为它们预留数GB的PFC头缓冲区。
为了在长链路上有效扩展PFC，我们基于以下两点策略进行了优化。首先，在T2和RH的机箱交换机上，我们利用片外DRAM的深度数据包缓冲区来存储RDMA数据包。经过分析，我们发现生产中的机箱交换机提供了足够的DRAM缓冲区来满足PFC头缓冲区的需求。其次，我们不再为每个队列单独保留PFC头缓冲区，而是为交换机上的所有入口无损队列分配一个共享的PFC头缓冲池。每个入口无损队列都设有一个静态阈值，以限制其在共享头缓冲池中的最大使用量。我们通过合理超额订阅头缓冲池的大小，为突发流量预留更多的共享缓冲空间。我们的生产实践表明，这种超额订阅的PFC头缓冲池策略能够有效减少拥塞损失并提高网络的突发容忍度。
7.2 DCQCN的互操作性挑战
我们采用DCQCN[112]机制来控制各队列对（QP）的数据发送速率。DCQCN由三大核心实体构成：发送方（或称反应点RP）、交换机（或称拥塞点CP）以及接收方（或称通知点NP）。在出口队列上，CP依据RED算法[43]进行ECN标记操作。一旦NP接收到带有ECN标记的数据包，便会发送拥塞通知数据包（CNP，Congestion Notification Packets）。随后，RP在接收到CNP时会相应降低发送速率，否则会根据字节计数器和定时器来增加速率。
然而，在部署过程中，我们发现来自不同代（Gen1、Gen2、Gen3）知名网卡供应商的商用网卡，尽管均支持DCQCN，但在具体实现上存在显著差异，这在不同代网卡间的通信中引发了互操作性问题。
DCQCN实现差异
在Gen1网卡上，DCQCN的大部分功能，包括NP和RP的状态机，都是在固件层面实现的。受限于固件的处理能力，Gen1采取了NP侧的CNP合并策略，以最小化CNP的生成。具体而言，NP在一个时间窗口内最多只为一个流生成一个CNP，无论该窗口内有多少个带有ECN标记的数据包到达。相应地，RP在收到CNP后会降低发送速率。此外，Gen1的缓存资源也相对有限，缓存未命中会显著影响RDMA的性能[50,63]。为了缓解这一问题，我们将Gen1上的限速粒度从单个数据包提升至数据包组，通过突发传输减少固定时间内的活跃QP数量，从而减轻对有限缓存资源的压力。
与Gen1不同，Gen2和Gen3网卡采用了基于硬件的DCQCN实现，并采用了RP侧的CNP合并机制。在Gen2和Gen3中，NP会为每个到达的带有ECN标记的数据包发送CNP，但RP则在一个时间窗口内最多只为一个流降低一次发送速率，无论该窗口内接收到多少CNP。值得注意的是，尽管合并机制的位置不同，但RP侧和NP侧的CNP合并机制在本质上提供了相似的拥塞通知粒度。在Gen2和Gen3上，限速操作是以单个数据包为粒度进行的。
互操作性挑战
当跨不同集群的存储前端流量导致不同代网卡间通信时，DCQCN的实现差异便成为了一个问题。具体而言，当Gen2/Gen3节点向Gen1节点发送流量时，由于其每个数据包的限速策略，往往会触发Gen1节点上的大量缓存未命中，进而减慢接收管道的处理速度。反之，当Gen1节点通过拥塞路径向Gen2/Gen3节点发送流量时，Gen2/Gen3的NP会向Gen1的RP发送过多的CNP，导致速率过度降低和吞吐量损失。
我们的解决方案
鉴于Gen1在处理能力和资源上的限制，我们无法直接使其性能达到Gen2和Gen3的水平。因此，我们采取了使Gen2和Gen3尽可能模拟Gen1行为的策略。我们的解决方案主要包括两个方面：
CNP合并机制调整：我们将Gen2和Gen3上的CNP合并操作从RP侧移至NP侧。在Gen2/Gen3的NP侧，我们增设了按QP划分的CNP速率限制器，并设置了与Gen1 NP相同的CNP合并定时器值作为两个连续CNP之间的最小间隔。同时，在Gen2/Gen3的RP侧，我们将速率降低的时间窗口最小化，以确保RP在接收到CNP时几乎总是能够立即降低发送速率。
按突发限速：我们在Gen2和Gen3上启用了按突发进行限速的功能，以进一步平滑发送速率并减少因速率频繁变化而带来的性能波动。
7.3 DCQCN的调整与优化
在Azure环境中调整DCQCN时，我们面临一些实际限制。首先，网卡仅支持全局DCQCN参数设置。其次，为了优化客户体验，我们根据应用语义而非RTT将RDMA流量分配到两个交换机队列中。因此，我们采用了全局DCQCN参数设置（在网卡和交换机上），这些设置在面对区域内RTT较大变化时仍能表现出良好的性能。
我们采用了一个三步法来调整DCQCN参数：首先，利用流体模型[113]深入理解DCQCN的理论特性；其次，在实验室测试平台上使用合成流量进行实验，以评估解决互操作性问题的方案并确定合理的参数设置；最后，在测试集群中验证这些参数设置，这些集群采用了与生产集群相同的配置来承载客户流量。我们运行了带有真实存储应用程序的压力测试，并根据应用性能反馈进一步调整DCQCN参数。
DCQCN机制不会受到往返时间（RTT）不公平的影响，因为它是基于速率的控制协议，其速率调整过程与RTT无直接关联。 为了提升具有较长RTT的DCQCN流的吞吐量，我们采用了稀疏的ECN标记策略，并设置了较大的Kmax与Kmin之差以及较小的Pmax值。 DCQCN与交换机缓冲区的性能调优应协同进行[112]。例如，在增加Kmin之前，必须确保无损流量的入口阈值足够大，以避免优先流控制（PFC）在ECN标记之前被错误触发。
8. 经验总结
自2018年起，我们开始逐步将RDMA技术应用于客户后端流量的处理。2019年，我们进一步将RDMA引入客户前端流量服务，实现了存储与计算集群在同一数据中心的紧密集成。2020年，我们在Azure的首个区域内成功部署了区域内RDMA。截至2023年2月，Azure公共区域中约70%的流量已采用RDMA技术（如图1所示），且区域内RDMA已在所有Azure公共区域得到全面支持。
8.1 部署与运维服务
我们遵循一套严谨的三步策略来在生产环境中逐步启用RDMA。首先，在实验室测试平台上完成所有组件的开发与测试。其次，在软硬件配置与生产环境一致的测试集群中，进行端到端的压力测试，并模拟各种常见错误场景（如随机数据包丢失），以评估系统的健壮性。最后，我们谨慎地扩大生产环境中RDMA的部署规模，以逐步承载更多客户流量。在部署过程中，网卡驱动程序/固件及交换机操作系统的更新是常态，因此，如何最小化这些更新对客户流量的影响成为关键。
交换机运维
与T1或更高级别的交换机相比，T0交换机（尤其是在计算集群中）的运维难度更大，因为它们可能成为客户虚拟机的单点故障源（SPOF）。为此，我们采用快速重启[17]和温重启[19]技术，将数据平面的中断时间从几分钟缩短至不足一秒。
网卡运维
在某些情况下，更新网卡驱动程序或固件需要卸载网卡驱动程序。为确保安全卸载，我们必须在所有网卡资源均已释放后执行此操作。这要求我们先向相关消费者（如硬盘驱动程序）发送信号，关闭RDMA连接，并将流量切换至TCP。待RDMA及其他相关网卡功能被禁用后，方可重新加载驱动程序。
8.2 性能表现
存储后端
目前，Azure几乎所有的存储后端流量都已采用RDMA技术。鉴于通过RDMA节省的CPU资源已被用于其他任务，且客户体验未受影响，因此不再适合进行大规模的带客户流量的A/B测试。为此，我们展示了2018年在测试集群中进行的A/B测试结果。测试结果显示，在高每秒事务数（TPS）的存储工作负载下，RDMA相较于TCP在CPU利用率和网络数据传输速度上均有显著提升（如图7和图8所示）。
存储前端
同样，由于无法进行大规模的带客户流量的A/B测试，我们展示了2018年在测试集群中的测试结果。测试使用DiskSpd工具生成了读写工作负载（读IOPS为A，写IOPS为B，且A<B，I/O大小为8KB）。结果显示，在测试期间，RDMA相较于TCP在主机域的平均CPU利用率上降低了高达34.5%（如图9所示）。
为了进一步验证RDMA引入的性能改进，我们利用了一个持续运行的存储监控服务。该服务在Azure的每个区域部署了虚拟机，定期生成硬盘读写工作负载，并收集端到端的性能数据。监控服务覆盖了不同的I/O大小、硬盘类型以及存储前端流量的传输方式。图10展示了监控服务收集的一年内所有Azure公共区域中某类型SSD的整体平均访问延迟。结果显示，在各种I/O大小下，RDMA的访问延迟均优于TCP。特别是对于1MB的I/O请求，RDMA在读和写方面分别减少了23.8%和15.6%的延迟。这主要得益于RDMA能够通过单个连接以线速率运行，从而显著提升了对吞吐量敏感的大型I/O请求的性能，同时避免了TCP的慢启动问题。
拥塞控制
我们在测试集群中实施了压力测试，旨在确定在高负载条件下能够保持合理性能的DCQCN参数配置。图11展示了用于指导调优过程的99百分位消息完成时间结果，这是我们评估性能的关键指标。初始阶段，我们禁用了DCQCN，仅调整交换机缓冲区参数，如无损队列的动态阈值，以探索仅依赖PFC所能达到的最佳性能表现。随后，我们在达到PFC最优性能的基础上，启用了DCQCN，采用在实验室测试平台上通过合成流量得出的默认参数设置。然而，尽管DCQCN减少了PFC暂停帧的数量，但其默认设置过于激进地降低了发送速率，导致尾部消息完成时间延长。因此，我们调整了ECN标记参数，以改善DCQCN的吞吐量性能。经过优化，DCQCN的性能超越了仅使用PFC的情况。这次调整的核心经验在于，DCQCN与交换机缓冲区的协同调优对于优化应用程序性能至关重要，而不仅仅是关注PFC暂停的持续时间。
8.3 发现的问题与解决方案
在测试和部署过程中，我们识别并解决了多个与网卡（NICs）、交换机及RDMA应用程序相关的问题。
FMR隐式阻塞问题
在sK-RDMA架构中（§4.2），每个来自计算服务器的I/O请求都需伴随一个FMR请求，随后是一个发送请求至存储服务器，该请求中包含注册内存和存储命令的描述。因此，发送队列由众多FMR/Send对组成。
当我们在不同数据中心部署sK-RDMA以连接计算和存储集群时，发现前端流量吞吐量极低，尽管发送队列中积压了大量未完成的FMR/Send对。为诊断此问题，我们利用RDMA Estats工具收集了每个发送请求的T5-T1延迟数据（§5）。分析显示，T5-T1延迟与数据中心间的往返时间（RTT）高度相关，且每个RTT周期内仅有一个未完成的发送请求。经与NIC供应商沟通确认，问题根源在于NIC为简化设计，仅在前一请求完成后才处理FMR请求。在sK-RDMA中，这导致FMR请求在发送请求间形成了隐式阻塞，限制了并发发送请求的数量，无法有效利用数据中心间大带宽网络。我们已与NIC供应商合作解决了此问题，并在新版NIC驱动程序中实施了修复。
PFC与MACsec兼容性问题
在T2与RH之间启用PFC的长距离链路上，我们观察到高数据包损坏率，触发了相关警报。调查后发现，MACSec标准[21]未明确PFC帧是否应加密，导致不同供应商间对PFC帧的加密处理存在分歧。例如，交换机A可能发送未加密的PFC帧给期望接收加密PFC帧的交换机B，从而引发错误报告。我们已与交换机供应商协作，统一了MACSec启用端口对PFC帧的处理标准。
拥塞泄漏问题
在测试集群中，我们注意到当在Gen2 NICs上启用互操作功能（§7.2）时，其吞吐量有所下降。为深入探究原因，我们使用水填充算法计算了各QP的理论吞吐量，并与实测数据进行对比。分析结果显示两个显著特点：一是无论拥塞程度如何，Gen2 NICs发送的流均保持近乎相同的发送速率；二是实际发送速率非常接近NIC上最慢流的理论发送速率，表明所有流均受到最慢流的限制。我们向NIC供应商报告了这些观察结果，他们确认了NIC固件中的头部阻塞问题。我们已在所有支持互操作功能的NIC上修复了此问题。
回环RDMA导致的接收端缓慢
此问题在一个测试集群中被识别。在压力测试中，我们发现大量服务器向T0交换机发送PFC暂停帧，但T0交换机上并未触发PFC看门狗机制。这些服务器似乎只是逐步降低了来自T0交换机的流量速度，而非长时间完全阻塞。此外，考虑到Azure规模下普遍存在的慢接收端现象，集群中大部分服务器同时出现问题的可能性极低。
基于上述观察，我们推测慢接收端问题源于我们的应用程序设计。调查发现，每个服务器上运行了多个RDMA应用程序实例，且实例间流量均通过RDMA传输，未考虑其位置。因此，回环流量与外部流量在NIC的PCIe通道上形成了2:1的拥塞。由于NIC无法标记ECN，只能通过PCIe反压和PFC暂停帧来限制流量。为验证此分析，我们在部分服务器上禁用了回环流量的RDMA传输，随后这些服务器停止了PFC帧的发送。值得注意的是，近期的研究工作[61,70]也独立发现了类似问题。
9. 教训与未来挑战
在本章中，我们总结了从实际经验中汲取的深刻教训，并展望了未来亟待解决的关键问题。
RDMA故障切换成本极高
对于RDMA而言，故障切换是一项成本极高的操作。尽管我们在sU-RDMA和sK-RDMA系统中都实施了故障切换机制作为最终保障，但实践表明，RDMA的故障切换移特别耗费资源，应当尽量避免。云服务商采用RDMA技术旨在节省CPU资源，以释放更多核心用于其他任务。然而，一旦需要将流量从RDMA路径转移，就不得不额外分配CPU核心来承载这些流量，这不仅增加了CPU的负荷，而且在高负载情况下可能导致资源耗尽。因此，在Azure等大规模环境中，进行RDMA的故障切换被视为高风险操作，我们仅在全面测试通过后，才逐步扩大RDMA的部署规模。在部署过程中，我们持续监控网络性能，一旦发现异常立即暂停部署，并在故障切换后尽快恢复RDMA服务。
主机网络与物理网络的融合趋势
在8.3节中，我们揭示了新型慢接收端问题的根源在于主机内部的拥塞。最新的研究[24]也进一步印证了生产集群中主机拥塞的普遍存在及其特征。我们认为，这只是冰山一角，主机网络与物理网络之间尚存在许多未被发现的问题行为。传统上，主机网络和物理网络被视为独立的实体，而NIC则是它们之间的界限。然而，深入剖析主机内部结构，我们不难发现，它其实是一个由异构节点（如CPU、GPU、DPU）通过专有高速链路（如PCIe、NVLink）和交换机（如PCIe交换机、NVSwitch）连接而成的复杂网络。主机间的流量可以视为南北向流量，而随着数据中心链路容量的不断提升以及硬件卸载和直接访问技术（如GPUDirect RDMA）的广泛应用，主机间流量愈发复杂，与主机内部流量的交互也更为密切。
因此，我们预见未来主机网络与物理网络将趋于融合。这一融合网络将成为推动分散云发展的关键一步。我们期待能够以管理当前物理网络相似的方式来操作这一融合网络，实现更高效、更灵活的网络管理。
交换机缓冲区的重要性与创新需求
传统观念认为，低延迟的数据中心拥塞控制策略可以减少对大型交换机缓冲区的依赖，因为它们能够维持较短的队列长度。然而，在生产环境中，我们却发现交换机缓冲区与RDMA性能问题之间存在着密切的关联。缓冲区较小的集群更容易遇到性能瓶颈。而且，许多性能问题可以通过调整交换机缓冲区参数而非直接修改DCQCN策略来缓解。因此，在优化网络性能时，我们总是优先调整交换机缓冲区设置（§8.2）。
交换机缓冲区之所以重要，是因为数据中心中突发流量和短暂拥塞事件频发。传统的拥塞控制方法由于其反应式特性，难以有效应对这类场景。相比之下，交换机缓冲区作为吸收突发流量并提供快速响应的第一道防线，其作用不可忽视。
随着数据中心链路速度的不断提升，我们认为交换机缓冲区将变得更加重要，因此需要投入更多努力进行创新。一方面，近年来“披萨盒式”交换机上每Gbps端口的缓冲区大小持续减少[31]，部分交换机ASIC甚至将数据包存储器分割成多个分区，从而限制了有效的缓冲资源。我们呼吁加大研发力度，开发具有更深数据包缓冲区和更统一架构的ASIC。另一方面，现有的通用交换机ASIC在缓冲区管理机制上仍沿用几十年前的设计[40]，这限制了拥塞处理方案的创新空间。随着可编程数据平面的兴起[32]，我们期待未来的交换机ASIC能够在缓冲区模型和接口上提供更多的可编程性，从而推动更有效的缓冲区管理解决方案的发展[22]。
云环境下网络设备统一行为模型与接口的需求
软件和硬件的多样性给云规模下的网络运营带来了巨大挑战。尽管我们在统一交换机软件（§6）和NIC拥塞控制（§7.2）方面取得了显著进展，但多样性依然导致了一系列问题，如PFC与MACsec之间的意外交互（§8.3）。为此，我们认为需要建立更多的统一模型和接口来简化操作并加速云中的创新步伐。这些关键领域包括机箱交换机、智能网络设备以及RDMA NICs等。值得注意的是，目前已有一些工作致力于标准化不同数据路径的拥塞控制[85]和异构智能设备的APIs[16]，这些努力为未来的统一化进程奠定了坚实基础。
测试新网络设备的迫切性与挑战
自项目启动之初，我们便致力于构建多样化的测试工具，并在专业的测试床与集群环境中实施严格测试。尽管在测试阶段已发现并解决了众多问题，但在实际部署过程中，仍遭遇了由微行为及被忽略的边缘案例所引发的新问题（§8.3）。这促使我们深刻反思，在面对日益复杂、功能繁多的新型网络设备时，测试工作所面临的挑战与需求。
首先，许多新兴功能缺乏明确的标准规范，这是进行系统测试不可或缺的先决条件。许多看似简单的功能，实则涉及软硬件间错综复杂的交互作用。因此，我们坚信，前文中提及的统一行为模型与接口标准的建立，将对此类问题的解决大有裨益。
其次，测试系统需具备高速响应能力，以便与网络设备进行实时交互，并精准捕捉其微秒级的细微行为。我们认为，可编程硬件技术的发展，为这一目标的实现提供了有力支持[33,37]。值得注意的是，近期在RDMA NICs[69,70]及可编程交换机[37,110]测试领域已取得的进展，为我们提供了借鉴与启示。
10. 相关工作
本文聚焦于云存储环境中的RDMA技术应用。鉴于RDMA与存储系统相关的文献浩如烟海，以下仅就部分紧密关联的研究观点进行概述。
RDMA与存储网络的部署实践：
在项目前期，我们已将RDMA技术成功部署于支持Bing工作负载的环境中，并在此过程中遭遇了PFC风暴、PFC死锁及接收缓慢等难题[50]，这些经历为我们积累了·经验教训。此外，Gao等人[46]分享了阿里巴巴在集群内部署RDMA以优化存储后端流量的实践经验；Miao等人[80]则提出了LUNA与SOLAR两代存储网络栈，分别面向阿里巴巴的存储前端流量进行优化，其中LUNA为高性能用户空间TCP栈，而SOLAR则是在专用DPU上实现的存储优化UDP栈。值得一提的是，可扩展可靠数据报（SRD）[96]作为AWS自研Nitro网络卡上的云优化传输协议，已被广泛应用于HPC、ML及存储领域[7]。相比之下，我们采用普通硬件实现了区域内RDMA，有效支持了存储前端与后端流量的高效传输。
数据中心拥塞控制研究概览：
数据中心拥塞控制领域的研究成果丰硕，涵盖了基于ECN[26, 27, 99, 112]、延迟[71, 72, 76, 82]、INT[23, 75, 101]、信用[34, 38, 45, 52, 55, 84, 86, 88]及数据包调度[28, 30, 36, 49, 54]等多种机制。我们的工作聚焦于具有大RTT变化特性的区域网络，并注意到有研究[95, 107]针对类似场景进行了深入探讨。
数据中心RDMA技术的优化与改进：
除拥塞控制外，众多研究还致力于提升数据中心RDMA的可靠性、安全性及性能表现，包括死锁缓解[56, 92, 103]、多路径支持[77]、丢包网络上的容错性[78, 83, 102]、安全机制[94, 98, 104]、虚拟化[53, 67, 89, 100]、测试[69, 70]以及多租户环境中的性能隔离[109]等方面。我们的工作聚焦于信任环境中的第一方流量，并鉴于NICs有限的重传能力，在无丢包网络上启用了RDMA（§2.4）。此外，众多提案[41, 62-66, 74, 93, 106, 111]利用RDMA加速存储系统或一般网络系统，我们的RDMA协议（§4）亦提供类似套接字的接口，以保持与传统存储栈的兼容性。同时，一些最新研究通过新型内核设计[58, 59, 73]及SmartNIC[68, 81]等手段，进一步优化了存储系统性能。
11. 结论与未来展望
本文深入总结了我们在Azure环境中部署区域内RDMA以优化存储工作负载的经验。面对基础设施高度复杂与多样化的特性，我们成功应对了一系列新兴挑战，对网络基础设施实施了多项关键性改进。目前，Azure平台上的流量中，约有70%已通过RDMA进行传输，且所有Azure公共区域均已实现区域内RDMA的支持。这一技术的应用，显著提升了硬盘I/O性能，并有效减少了CPU资源的占用。
展望未来，我们计划继续在系统架构、硬件加速及拥塞控制等关键领域进行创新，以进一步优化存储系统的整体性能。同时，我们还将积极探索将RDMA技术引入更多应用场景的可能性，以拓展其应用边界，为用户提供更加高效、可靠的存储解决方案。
References
[1] Amazon ebs volume types. https://aws.amazon.c om/ebs/volume-types/.
[2] Amazon web services region. https://aws.amazon.com/about-aws/global-infrastructure/reg ions_az/.
[3] Arista 7500r switch architecture (‘a day in the life of a packet’). https://www.arista.com/assets/data /pdf/Whitepapers/Arista7500RSwitchArchitec tureWP.pdf.
[4] Azure managed disk types. https://docs.microso ft.com/en-us/azure/virtual-machines/diskstypes.
[5] Azure region. https://docs.microsoft.com/enus/azure/availability-zones/az-overview.
[6] Cisco silicon one product family. https://www.cisc o.com/c/dam/en/us/solutions/collateral/sil icon-one/white-paper-sp-product-family.p df.
[7] A decade of ever-increasing provisioned iops for amazon ebs. https://aws.amazon.com/blogs/aws/a -decade-of-ever-increasing-provisioned-i ops-for-amazon-ebs/.
[8] Google cloud region. https://cloud.google.com /compute/docs/regions-zones.
[9] Keysight network test solutions. https://www.keys ight.com/us/en/solutions/network-test.ht ml.
[10] Packet testing framework (ptf). https://github.c om/p4lang/ptf.
[11] Pfc watchdog in sonic. https://github.com/son ic-net/SONiC/wiki/PFC-Watchdog-Design.
[12] Priority flow control: Build reliable layer 2 infrastructure. https://e2e.ti.com/cfs-file/__key/com munityserver-discussions-components-file s/908/802.1q-Flow-Control-white_5F00_pap er_5F00_c11_2D00_542809.pdf.
[13] rsocket(7) - linux man page. https://linux.die. net/man/7/rsocket.
[14] Smb direct. https://learn.microsoft.com/en-u s/windows-server/storage/file-server/smb -direct.
[15] Software for open networking in the cloud (sonic). https://sonic-net.github.io/SONiC/.
[16] Sonic-dash - disaggregated api for sonic hosts. https://github.com/sonic-net/DASH.
[17] Sonic fast reboot. https://github.com/sonic-n et/SONiC/blob/master/doc/fast-reboot/fas treboot.pdf.
[18] sonic-mgmt: Management and automation code used for sonic testbed deployment, tests and reporting. ht tps://github.com/sonic-net/sonic-mgmt.
[19] Sonic warm reboot. https://github.com/sonic-net/SONiC/blob/master/doc/warm-reboot/SON iC_Warmboot.md.
[20] Switch abstraction interface (sai). https://github .com/opencomputeproject/SAI.
[21] Ieee standard for local and metropolitan area networksmedia access control (mac) security. IEEE Std 802.1AE-2018 (Revision of IEEE Std 802.1AE-2006), 2018.
[22] Vamsi Addanki, Maria Apostolaki, Manya Ghobadi, Stefan Schmid, and Laurent Vanbever. Abm: active buffer management in datacenters. In SIGCOMM 2022.
[23] Vamsi Addanki, Oliver Michel, and Stefan Schmid. Powertcp: Pushing the performance limits of datacenter networks. In NSDI 2022.
[24] Saksham Agarwal, Rachit Agarwal, Behnam Montazeri, Masoud Moshref, Khaled Elmeleegy, Luigi Rizzo, Marc Asher de Kruijf, Gautam Kumar, Sylvia Ratnasamy, David Culler, and Amin Vahdat. Understanding host interconnect congestion. In HotNets 2022.
[25] Mohammad Al-Fares, Alexander Loukissas, and Amin Vahdat. A scalable, commodity data center network architecture. In SIGCOMM 2008.
[26] Mohammad Alizadeh, Albert Greenberg, David A. Maltz, Jitendra Padhye, Parveen Patel, Balaji Prabhakar, Sudipta Sengupta, and Murari Sridharan. Data center tcp (dctcp). In SIGCOMM 2010.
[27] Mohammad Alizadeh, Abdul Kabbani, Tom Edsall, Balaji Prabhakar, Amin Vahdat, and Masato Yasuda. Less is more: trading a little bandwidth for ultra-low latency in the data center. In NSDI 2012.
[28] Mohammad Alizadeh, Shuang Yang, Milad Sharif,Sachin Katti, Nick McKeown, Balaji Prabhakar, and Scott Shenker. pfabric: Minimal near-optimal datacenter transport. In SIGCOMM 2013.
[29] InfiniBand Trade Association. Supplement to infiniband architecture specification volume 1 release 1.2. 1 annex a17: Rocev2, 2014.
[30] Wei Bai, Li Chen, Kai Chen, Dongsu Han, Chen Tian, and Hao Wang. Information-agnostic flow scheduling for commodity data centers. In NSDI 2015.
[31] Wei Bai, Shuihai Hu, Kai Chen, Kun Tan, and Yongqiang Xiong. One more config is enough: Saving (dc) tcp for high-speed extremely shallow-buffered datacenters. In INFOCOM 2020.
[32] Pat Bosshart,Dan Daly,Glen Gibb,Martin Izzard,Nick McKeown, Jennifer Rexford, Cole Schlesinger, Dan Talayco, Amin Vahdat, George Varghese, and David Walker. P4: Programming protocol-independent packet processors. ACM SIGCOMM Computer Communication Review, 2014.
[33] Pietro Bressana, Noa Zilberman, and Robert Soulé. Finding hard-to-find data plane bugs with a pta. In CoNEXT 2020.
[34] Qizhe Cai, Mina Tahmasbi Arashloo, and Rachit Agarwal. dcpim: Near-optimal proactive datacenter transport. In SIGCOMM 2022.
[35] Brad Calder, Ju Wang, Aaron Ogus, Niranjan Nilakantan, Arild Skjolsvold, Sam McKelvie, Yikang Xu,Shashwat Srivastav, Jiesheng Wu, Huseyin Simitci,Jaidev Haridas, Chakravarthy Uddaraju, Hemal Khatri, Andrew Edwards, Vaman Bedekar, Shane Mainali, Rafay Abbasi, Arpit Agarwal, Mian Fahim ul Haq,Muhammad Ikram ul Haq, Deepali Bhardwaj, Sowmya Dayanand, Anitha Adusumilli, Marvin McNett, Sriram Sankaran, Kavitha Manivannan, and Leonidas Rigas.Windows azure storage: A highly available cloud storage service with strong consistency. In SOSP 2011.
[36] Li Chen, Kai Chen, Wei Bai, and Mohammad Alizadeh. Scheduling mix-flows in commodity datacenters with karuna. In SIGCOMM 2016.
[37] Yanqing Chen, Bingchuan Tian, Chen Tian, Li Dai, Yu Zhou, Mengjing Ma, Ming Tang, Hao Zheng,Zhewen Yang, Guihai Chen, Dennis Cai, and Ennan Zhai. Norma: Towards practical network load testing. In NSDI 2023.
[38] Inho Cho, Keon Jang, and Dongsu Han. Creditscheduled delay-bounded congestion control for datacenters. In SIGCOMM 2017.
[39] Sean Choi, Boris Burkov, Alex Eckert, Tian Fang,Saman Kazemkhani, Rob Sherwood, Ying Zhang, and Hongyi Zeng. Fboss: building switch software at scale. In SIGCOMM 2018.
[40] Abhijit K. Choudhury and Ellen L. Hahne. Dynamic queue length thresholds for shared-memory packet switches. IEEE/ACM Transactions on Networking, 1998.
[41] Aleksandar Dragojevic, Dushyanth Narayanan, Miguel´ Castro, and Orion Hodson. Farm: Fast remote memory. In NSDI 2014.
[42] Daniel Firestone, Andrew Putnam, Sambhrama Mundkur, Derek Chiou, Alireza Dabagh, Mike Andrewartha, Hari Angepat, Vivek Bhanu, Adrian Caulfield, Eric Chung, Harish Kumar Chandrappa, Somesh Chaturmohta, Matt Humphrey, Jack Lavier, Norman Lam, Fengfen Liu, Kalin Ovtcharov, Jitu Padhye, Gautham Popuri, Shachar Raindel, Tejas Sapre, Mark Shaw, Gabriel Silva, Madhan Sivakumar, Nisheeth Srivastava, Anshuman Verma, Qasim Zuhair, Deepak Bansal, Doug Burger, Kushagra Vaid, David A. Maltz, and Albert Greenberg. Azure accelerated networking: SmartNICs in the public cloud. In NSDI 2018.
[43] Sally Floyd and Van Jacobson. Random early detection gateways for congestion avoidance. IEEE/ACM Transactions on Networking, 1993.
[44] Philip Werner Frey and Gustavo Alonso. Minimizing the hidden cost of rdma. In ICDCS 2009.
[45] Peter X. Gao, Akshay Narayan, Gautam Kumar, Rachit Agarwal, Sylvia Ratnasamy, and Scott Shenker. phost: Distributed near-optimal datacenter transport over commodity network fabric. In CoNEXT 2015.
[46] Yixiao Gao, Qiang Li, Lingbo Tang, Yongqing Xi, Pengcheng Zhang, Wenwen Peng, Bo Li, Yaohui Wu,Shaozong Liu, Lei Yan, Fei Feng, Yan Zhuang, Fan Liu, Pan Liu, Xingkui Liu, Zhongjie Wu, Junping Wu, Zheng Cao, Chen Tian, Jinbo Wu, Jiaji Zhu, Haiyong Wang, Dennis Cai, and Jiesheng Wu. When cloud storage meets RDMA. In NSDI 2021.
[47] Dror Goldenberg, Michael Kagan, Ran Ravid, and Michael S Tsirkin. Zero copy sockets direct protocol over infiniband-preliminary implementation and performance analysis. In HOTI 2005.
[48] Albert Greenberg, James R. Hamilton, Navendu Jain, Srikanth Kandula, Changhoon Kim, Parantap Lahiri, David A. Maltz, Parveen Patel, and Sudipta Sengupta.Vl2: a scalable and flexible data center network. In SIGCOMM 2009.
[49] Matthew P Grosvenor, Malte Schwarzkopf, Ionel Gog, Robert NM Watson, Andrew W Moore, Steven Hand, and Jon Crowcroft. Queues don’t matter when you can jump them! In NSDI 2015.
[50] Chuanxiong Guo, Haitao Wu, Zhong Deng, Gaurav Soni, Jianxi Ye, Jitu Padhye, and Marina Lipshteyn. Rdma over commodity ethernet at scale. In SIGCOMM 2016.
[51] Chuanxiong Guo, Lihua Yuan, Dong Xiang, Yingnong Dang, Ray Huang, Dave Maltz, Zhaoyi Liu, Vin Wang, Bin Pang, Hua Chen, Zhi-Wei Lin, and Varugis Kurien. Pingmesh: A large-scale system for data center network latency measurement and analysis. In SIGCOMM 2015.
[52] Mark Handley, Costin Raiciu, Alexandru Agache, Andrei Voinescu, Andrew W Moore, Gianni Antichi, and Marcin Wójcik. Re-architecting datacenter networks and stacks for low latency and high performance. In SIGCOMM 2017.
[53] Zhiqiang He, Dongyang Wang, Binzhang Fu, Kun Tan, Bei Hua, Zhi-Li Zhang, and Kai Zheng. Masq: Rdma for virtual private cloud. In SIGCOMM 2020.
[54] Chi-Yao Hong, Matthew Caesar, and P Godfrey. Finishing flows quickly with preemptive scheduling. In SIGCOMM 2012.
[55] Shuihai Hu, Wei Bai, Gaoxiong Zeng, Zilong Wang, Baochen Qiao, Kai Chen, Kun Tan, and Yi Wang. Aeolus: A building block for proactive transport in datacenters. In SIGCOMM 2020.
[56] Shuihai Hu, Yibo Zhu, Peng Cheng, Chuanxiong Guo, Kun Tan, Jitendra Padhye, and Kai Chen. Tagger: Practical pfc deadlock prevention in data center networks. In CoNEXT 2017.
[57] Cheng Huang, Huseyin Simitci, Yikang Xu, Aaron Ogus, Brad Calder, Parikshit Gopalan, Jin Li, and Sergey Yekhanin. Erasure coding in windows azure storage. In ATC 2012.
[58] Jaehyun Hwang, Qizhe Cai, Ao Tang, and Rachit Agarwal. Tcp ≈ rdma: Cpu-efficient remote storage access with i10. In NSDI 2020.
[59] Jaehyun Hwang, Midhul Vuppalapati, Simon Peter, and Rachit Agarwal. Rearchitecting linux storage stack for µs latency and high throughput. In OSDI 2021.
[60] IEEE. 802.11 qbb. priority based flow control. 2008.
[61] Yimin Jiang, Yibo Zhu, Chang Lan, Bairen Yi, Yong Cui, and Chuanxiong Guo. A unified architecture for accelerating distributed dnn training in heterogeneous gpu/cpu clusters. In OSDI 2020.
[62] Anuj Kalia, Michael Kaminsky, and David Andersen. Datacenter rpcs can be general and fast. In NSDI 2019.
[63] Anuj Kalia, Michael Kaminsky, and David G Andersen. Design guidelines for high performance rdma systems. In ATC 2016.
[64] Anuj Kalia, Michael Kaminsky, and David G Andersen. Fasst: Fast, scalable and simple distributed transactions with two-sided (rdma) datagram rpcs. In OSDI 2016.
[65] Anuj Kalia, Michael Kaminsky, and David G Andersen. Using rdma efficiently for key-value services. In SIGCOMM 2014.
[66] Daehyeok Kim, Amirsaman Memaripour, Anirudh Badam, Yibo Zhu, Hongqiang Harry Liu, Jitu Padhye, Shachar Raindel, Steven Swanson, Vyas Sekar, and Srinivasan Seshan. Hyperloop: group-based nicoffloading to accelerate replicated transactions in multitenant storage systems. In SIGCOMM 2018.
[67] Daehyeok Kim, Tianlong Yu, Hongqiang Harry Liu, Yibo Zhu, Jitu Padhye, Shachar Raindel, Chuanxiong Guo, Vyas Sekar, and Srinivasan Seshan. Freeflow: Software-based virtual rdma networking for containerized clouds. In NSDI 2019.
[68] Jongyul Kim, Insu Jang, Waleed Reda, Jaeseong Im, Marco Canini, Dejan Kostic, Youngjin Kwon, Simon´ Peter, and Emmett Witchel. Linefs: Efficient smartnic offload of a distributed file system with pipeline parallelism. In SOSP 2021.
[69] Xinhao Kong, Jingrong Chen, Wei Bai, Yechen Xu, Mahmoud Elhaddad, Shachar Raindel, Jitendra Padhye, and Alvin R Lebeck Danyang Zhuo. Understanding rdma microarchitecture resources for performance isolation. In NSDI 2023.
[70] Xinhao Kong, Yibo Zhu, Huaping Zhou, Zhuo Jiang, Jianxi Ye,Chuanxiong Guo,and Danyang Zhuo. Collie: Finding performance anomalies in rdma subsystems. In NSDI 2022.
[71] Gautam Kumar, Nandita Dukkipati, Keon Jang, Hassan M. G. Wassel, Xian Wu, Behnam Montazeri, Yaogong Wang, Kevin Springborn, Christopher Alfeld, Michael Ryan, David Wetherall, and Amin Vahdat. Swift: Delay is simple and effective for congestion control in the datacenter. In SIGCOMM 2020.
[72] Changhyun Lee, Chunjong Park, Keon Jang, Sue Moon, and Dongsu Han. Accurate latency-based congestion feedback for datacenters. In ATC 2015.
[73] Gyusun Lee, Seokha Shin, Wonsuk Song, Tae Jun Ham, Jae W. Lee, and Jinkyu Jeong. Asynchronous I/O stack: A low-latency kernel I/O stack for Ultra-Low latencySSDs. In ATC 2019.
[74] Bojie Li, Tianyi Cui, Zibo Wang, Wei Bai, and Lintao Zhang. Socksdirect: Datacenter sockets can be fast and compatible. In SIGCOMM 2019.
[75] Yuliang Li, Rui Miao, Hongqiang Harry Liu, Yan Zhuang, Fei Feng, Lingbo Tang, Zheng Cao, Ming Zhang, Frank Kelly, Mohammad Alizadeh, and Minlan Yu. Hpcc: High precision congestion control. In SIGCOMM 2019.
[76] Shiyu Liu, Ahmad Ghalayini, Mohammad Alizadeh, Balaji Prabhakar, Mendel Rosenblum, and Anirudh Sivaraman. Breaking the transience-equilibrium nexus: A new approach to datacenter packet transport. In NSDI 2021.
[77] Yuanwei Lu, Guo Chen, Bojie Li, Kun Tan, Yongqiang Xiong, Peng Cheng, Jiansong Zhang, Enhong Chen, and Thomas Moscibroda. Multi-path transport for rdma in datacenters. In NSDI 2018.
[78] Yuanwei Lu, Guo Chen, Zhenyuan Ruan, Wencong Xiao, Bojie Li, Jiansong Zhang, Yongqiang Xiong, Peng Cheng, and Enhong Chen. Memory efficient loss recovery for hardware-based transport in datacenter. In APNet 2017.
[79] Matt Mathis, John Heffner, and Rajiv Raghunarayan. Tcp extended statistics mib (rfc 4898). Technical report, 2007.
[80] Rui Miao, Lingjun Zhu, Shu Ma, Kun Qian, Shujun Zhuang, Bo Li, Shuguang Cheng, Jiaqi Gao, Yan Zhuang, Pengcheng Zhang, Rong Liu, Chao Shi, Binzhang Fu, Jiaji Zhu, Jiesheng Wu, Dennis Cai, and Hongqiang Harry Liu. From luna to solar: The evolutions of the compute-to-storage networks in alibaba cloud. In SIGCOMM 2022.
[81] Jaehong Min, Ming Liu, Tapan Chugh, Chenxingyu Zhao, Andrew Wei, In Hwan Doh, and Arvind Krishnamurthy. Gimbal: enabling multi-tenant storage disaggregation on smartnic jbofs. In SIGCOMM 2021.
[82] Radhika Mittal, Vinh The Lam, Nandita Dukkipati, Emily Blem, Hassan Wassel, Monia Ghobadi, Amin Vahdat, Yaogong Wang, David Wetherall, and David Zats. Timely: Rtt-based congestion control for the datacenter. In SIGCOMM 2015.
[83] Radhika Mittal, Alexander Shpiner, Aurojit Panda, Eitan Zahavi, Arvind Krishnamurthy, Sylvia Ratnasamy, and Scott Shenker. Revisiting network support for rdma. In SIGCOMM 2018.
[84] Behnam Montazeri, Yilong Li, Mohammad Alizadeh, and John Ousterhout. Homa: A receiver-driven lowlatency transport protocol using network priorities. In SIGCOMM 2018.
[85] Akshay Narayan, Frank Cangialosi, Deepti Raghavan, Prateesh Goyal, Srinivas Narayana, Radhika Mittal, Mohammad Alizadeh, and Hari Balakrishnan. Restructuring endpoint congestion control. In SIGCOMM 2018.
[86] Vladimir Olteanu, Haggai Eran, Dragos Dumitrescu, Adrian Popa, Cristi Baciu, Mark Silberstein, Georgios Nikolaidis, Mark Handley, and Costin Raiciu. An edgequeued datagram service for all datacenter traffic. In NSDI 2022.
[87] Madhav Himanshubhai Pandya, Aaron William Ogus, Zhong Deng, and Weixiang Sun. Transport protocol and interface for efficient data transfer over rdma fabric, August 2 2022. US Patent 11,403,253.
[88] Jonathan Perry, Amy Ousterhout, Hari Balakrishnan, Deverat Shah, and Hans Fugal. Fastpass: A centralized "zero-queue" datacenter network. In SIGCOMM 2014.
[89] Jonas Pfefferle, Patrick Stuedi, Animesh Trivedi, Bernard Metzler, Ionnis Koltsidas, and Thomas R Gross. A hybrid i/o virtualization framework for rdmacapable network interfaces. ACM SIGPLAN Notices, 2015.
[90] Jim Pinkerton. Sockets direct protocol v1. 0 rdma consortium. 2003.
[91] Leon Poutievski, Omid Mashayekhi, Joon Ong, Arjun Singh, Mukarram Tariq, Rui Wang, Jianan Zhang,
Virginia Beauregard, Patrick Conner, Steve Gribble, Rishi Kapoor, Stephen Kratzer, Nanfang Li, Hong Liu, Karthik Nagaraj, Jason Ornstein, Samir Sawhney, Ryohei Urata, Lorenzo Vicisano, Kevin Yasumura, Shidong Zhang, Junlan Zhou, and Amin Vahdat. Jupiter evolving: Transforming google’s datacenter network via optical circuit switches and software-defined networking. In SIGCOMM 2022.
[92] Kun Qian, Wenxue Cheng, Tong Zhang, and Fengyuan Ren. Gentle flow control: avoiding deadlock in lossless networks. In SIGCOMM 2019.
[93] Waleed Reda, Marco Canini, Dejan Kostic, and Simon Peter. Rdma is turing complete, we just did not know it yet! In NSDI 2022.
[94] Benjamin Rothenberger, Konstantin Taranov, Adrian Perrig, and Torsten Hoefler. Redmark: Bypassing rdma security mechanisms. In USENIX Security 2021.
[95] Ahmed Saeed, Varun Gupta, Prateesh Goyal, Milad Sharif, Rong Pan, Mostafa Ammar, Ellen Zegura, Keon Jang, Mohammad Alizadeh, Abdul Kabbani, and Amin Vahdat. Annulus: A dual congestion control loop for datacenter and wan traffic aggregates. In SIGCOMM 2020.
[96] Leah Shalev, Hani Ayoub, Nafea Bshara, and Erez Sabbag. A cloud-optimized transport protocol for elastic and scalable hpc. IEEE Micro, 2020.
[97] Cheng Tan, Ze Jin, Chuanxiong Guo, Tianrong Zhang, Haitao Wu, Karl Deng, Dongming Bi, and Dong Xiang. Netbouncer: Active device and link failure localization in data center networks. In NSDI 2019.
[98] Konstantin Taranov, Benjamin Rothenberger, Adrian Perrig, and Torsten Hoefler. srdma: efficient nic-based authentication and encryption for remote direct memory access. In ATC 2020.
[99] Balajee Vamanan, Jahangir Hasan, and TN Vijaykumar. Deadline-aware datacenter tcp (d2tcp). In SIGCOMM 2012.
[100] Dongyang Wang, Binzhang Fu, Gang Lu, Kun Tan, and Bei Hua. vsocket: virtual socket interface for rdma in public clouds. In VEE 2019.
[101] Weitao Wang, Masoud Moshref, Yuliang Li, Gautam Kumar, TS Eugene Ng, Neal Cardwell, and Nandita Dukkipati. Poseidon: Efficient, robust, and practical datacenter cc via deployable int. In NSDI 2023.
[102] Zilong Wang, Layong Luo, Qingsong Ning, Chaoliang Zeng, Wenxue Li, Xinchen Wan, Peng Xie, Tao Feng, Ke Cheng, Xiongfei Geng, Tianhao Wang, Weicheng Ling, Kejia Huo, Pingbo An, Kui Ji, Shideng Zhang, Bin Xu, Ruiqing Feng, Tao Ding, Kai Chen, and Chuanxiong Guo. Srnic: A scalable architecture for rdma nics. In NSDI 2023.
[103] Xinyu Crystal Wu and TS Eugene Ng. Detecting and resolving pfc deadlocks with itsy entirely in the data plane. In INFOCOM 2022.
[104] Jiarong Xing, Kuo-Feng Hsu, Yiming Qiu, Ziyang Yang, Hongyi Liu, and Ang Chen. Bedrock: Programmable network support for secure rdma systems. In USENIX Security 2022.
[105] Qiumin Xu, Huzefa Siyamwala, Mrinmoy Ghosh, Tameesh Suri, Manu Awasthi, Zvika Guz, Anahita Shayesteh, and Vijay Balakrishnan. Performance analysis of nvme ssds and their implication on real world databases. In SYSTOR 2015.
[106] Jian Yang, Joseph Izraelevitz, and Steven Swanson. Orion: A distributed file system for non-volatile main memory and rdma-capable networks. In FAST 2019.
[107] Gaoxiong Zeng, Wei Bai, Ge Chen, Kai Chen, Dongsu Han, Yibo Zhu, and Lei Cui. Congestion control for cross-datacenter networks. In ICNP 2019.
[108] Qiao Zhang, Vincent Liu, Hongyi Zeng, and Arvind Krishnamurthy. High-resolution measurement of data center microbursts. In IMC 2017.
[109] Yiwen Zhang, Yue Tan, Brent Stephens, and Mosharaf Chowdhury. Justitia: Software multi-tenancy in hardware kernel-bypass networks. In NSDI 2022.
[110] Naiqian Zheng, Mengqi Liu, Ennan Zhai,
Hongqiang Harry Liu, Yifan Li, Kaicheng Yang, Xuanzhe Liu, and Xin Jin. Meissa: scalable network testing for programmable data planes. In SIGCOMM 2022.
[111] Bohong Zhu, Youmin Chen, Qing Wang, Youyou Lu, and Jiwu Shu. Octopus+: An rdma-enabled distributed persistent memory file system. ACM Transactions on Storage, 2021.
[112] Yibo Zhu, Haggai Eran, Daniel Firestone, Chuanxiong Guo, Marina Lipshteyn, Yehonatan Liron, Jitendra Padhye, Shachar Raindel, Mohamad Haj Yahia, and Ming Zhang. Congestion control for large-scale rdma deployments. In SIGCOMM 2015.
[113] Yibo Zhu, Monia Ghobadi, Vishal Misra, and Jitendra Padhye. Ecn or delay: Lessons learnt from analysis of dcqcn and timely. In CoNEXT 2016.
[114] Yibo Zhu, Nanxi Kang, Jiaxin Cao, Albert Greenberg, Guohan Lu, Ratul Mahajan, Dave Maltz, Lihua Yuan, Ming Zhang, Ben Y. Zhao, and Haitao Zheng. Packetlevel telemetry in large datacenter networks. In SIGCOMM 2015.