数据中心以太网和RDMA：超大规模环境下的问题

Source: Torsten Hoefler; Duncan Roweth, Keith Underwood, Bob Alverson; Mark Griswold, Vahid Tabatabaee, Mohan Kalkunte, Surendra Anubolu; Siyuan Shen; Moray McLaren; Abdul Kabbani, Steve Scott; Datacenter Ethernet and RDMA: Issues at Hyperscale, 15 Apr 2023

摘要

我们观察到新兴的人工智能、高性能计算和存储工作负载对大规模数据中心网络提出了新的挑战。基于融合以太网的RDMA协议（RoCE，RDMA over Converged Ethernet） 是将现代的远程直接内存访问（RDMA，Remote Direct Memory Access）功能引入现有以太网的一种尝试。十年过去了，我们重新审视了RoCE的设计要点，并得出结论认为必须解决其几个缺点，以满足超大规模数据中心的需求。我们预测，数据中心和高性能计算市场将会融合，并在未来十年内采用现代化以太网为基础的高性能网络解决方案，取代TCP和RoCE。

数据中心以太网的新环境

以太网在有线局域网（LAN）领域占据主导地位已经几十年了，从私人住宅的部署到最大的数据中心。在过去的十年里，数据中心经历了巨大的增长，连接的机器数量超过了目前最大的超级计算机规模。虽然仍然存在一些差异，但这类超大规模的超级计算机和数据中心的网络需求非常相似[1]。然而，超级计算机通常使用专用的互连方式进行连接，而数据中心则建立在以太网之上。由于相似的需求和规模经济效益，随着每一代新技术的出现，二者继续趋近于融合。我们认为现在是重新思考融合互连的基本假设和架构的合适时机。

多种技术趋势加速了高性能互连的融合。主要的是，不断增加的网络性能要求推动了更高效的主机堆栈的发展，以支持新兴的数据密集型应用，如人工智能（AI），所需的Tb带宽、每秒数亿次的事务和个位数微秒级的延迟[2]。这些极端需求要求所有的协议和硬件尽可能高效，排除了许多传统驱动数据中心网络的类似TCP/IP的堆栈。远程直接内存访问（RDMA）是近30年来为高性能计算（HPC）工作负载开发的，并且后来扩展到目标存储与InfiniBand（IB）Verbs RDMA。RDMA使CPU可以通过网络进行硬件加速的直接内存访问。在过去的10年里，RDMA成为低开销和高速网络的事实标准。几乎所有的超级计算机架构以及领先的数据中心供应商都在生产环境中使用RDMA。

几十年前确定的负载平衡、拥塞控制和错误处理方面的简单假设，对于今天的网络来说已经不适用，现在的网络带宽高出100倍以上，消息速率高出10倍以上。此外，简单的RDMA网络接口卡（NIC）通常会增加额外的功能。由此产生的“智能NIC”通常会卸载重要服务并实现专门的网络协议。现代网络交换机还具备改进的能力，包括先进的网络遥测、网络计算能力以及网络负载均衡或拥塞控制[3]。我们认为当前现有的标准和部署基础设施存在根本性的差距，必须在不久的将来加以解决，以支持高效的高性能网络。

以太网RDMA简史

RDMA最初是为高性能计算系统开发的，早期应用包括Paragon、Cray的T3D/T3E和ASCI Red等。后来，InfiniBand Verbs RDMA成为超级计算领域中的标准解决方案。随后，在数据中心环境中采用了“RDMA over Converged Ethernet”（RoCE）来在向后兼容的以太网环境中提供RDMA的优势。另一个协议iWARP（参见IETF 2007年，RFC 5040-5044、6580、6581、7306）将RDMA语义层置于TCP或SCTCP之上。iWARP和RoCE都使用InfiniBand的Verbs与用户软件堆栈进行接口，因此对用户而言基本透明。尽管iWARP一开始就支持互联网兼容的路由，但并没有广泛采用。这可能是因为相对于RoCE所基于的非常简单的协议，一个完整的TCP/IP堆栈在硬件上的卸载是复杂而昂贵的。事实上，RoCEv1只是在以太网的L2报头之上采用了类似InfiniBand的传输层（即Base Transport Header，BTH）。后来，RoCEv2添加了IP/UDP L3报头以支持数据中心内部和跨数据中心的路由。目前，RoCEv2 NIC的部署数量超过了InfiniBand NIC。

RoCE - 融合还是临时应急？

RoCE的核心设计是继承自20年前为简单硬件开发的技术，对于今天的以太网环境来说并不是最优解。例如，RoCE使用基于InfiniBand的简单传输层，它在很大程度上依赖于按顺序传递和回退N（go-back-n）重传语义，这基本上需要一个高度可靠的按顺序传递的基础架构才能实现高效的运行。因此，RoCE在无丢包的有序传输环境（如InfiniBand）中运行效果最佳。传统上，以太网在交换机缓冲区已满时会丢弃数据包，并依赖端到端的重传机制。为了支持RoCE，"融合以太网"（CE，Converged Ethernet）引入了优先流控制（PFC，Priority Flow Control）来实现链路级无丢包操作。PFC重新利用了以太网中的PAUSE帧，以支持具有不同链路传输速率的网络。PFC通过增强PAUSE帧来停止（或限制）特定优先级类别的流量，以避免数据包丢失。不幸的是，这一复杂的协议集干扰了网络中的不同层次，并降低了对一些当今最重要的工作负载的效率。

RoCE的语义、负载平衡和拥塞控制机制都是继承自InfiniBand。这意味着所有的消息应该按照顺序到达目的地，就像它们是通过静态路由传输一样，这本质上禁止了许多分组级别的负载平衡机制。对于长期流程的AI训练工作负载，多路径机制可以极大地提高作业完成时间。此外，RoCEv2使用基于IP的简化拥塞控制机制，基于明确拥塞通知（ECN，Explicit Congestion Notification）的机制。当检测到拥塞时，ECN兼容的交换机会标记数据包，并将该信息传回接收方，接收方再将其传递给发送方，发送方根据一个参数减少注入速率。在无拥塞期之后，速率会自动增加，使用第二个配置参数。ECN使用二进制标志表示经历过拥塞，缺乏细粒度的指示会导致需要许多往返时间（RTTs，Round Trip Times）来确定正确的速率。这种简单的机制与InfiniBand最初的前向和后向明确拥塞通知（FECN/BECN）非常相似。它承诺可以与其它流量共存，但在实践中很难进行配置[4]，[5]，[6]。

现在我们简要讨论一些高性能计算（HPC）和数据中心流量中的重要流量模式，然后详细讨论RoCE的缺点。

指导流量模式

为了讨论方便，我们将确定三种流量模式，代表了当前大部分RDMA工作负载。不幸的是，这些模式也凸显了RoCE的不足之处。在这里，我们重点关注在HPC、AI训练和分布式推理、存储以及一般微服务或函数即服务（FaaS）流量中使用的东西（内部）数据中心流量。

Incast（IN）

当多个源进程以可能不协调但同时的流量模式针对同一目标进程时，就会发生incast流量模式。它的特点是具有多个源进程和一个事务大小。实际中，当服务在同一时间被许多不协调的客户端请求时，这种模式通常会随机出现。例如，假设有100个客户端想要向同一个存储服务器提交一个10kiB的写事务。所有客户端可能会以满带宽发送，因为他们不知道即将发生的拥塞。数据包将快速填满网络缓冲区，可能妨碍其它流量，并最终违反服务级别协议（SLA）。最具挑战性的incast模式是由于事务小于带宽-延迟乘积而导致拥塞控制机制在事务完成之前无法获得可靠的信号。我们指出，不断增长的带宽将越来越多的工作负载推入这个关键区域。

Oblivious bulk synchronous（OBS）

许多HPC和AI训练工作负载可以采用无感知的批量同步模型（OBS）表示，其中计算步骤与通信步骤交替进行，通常同步进程。无感知意味着应用程序的通信模式取决于少量参数（如大小或进程数），并且不依赖于被处理的数据。它通常可以在应用程序启动之前静态确定。例如，消息传递接口（MPI）标准[7]中的所有集合操作都是无感知的。因此，OBS工作负载可以在算法上避免incast！深度学习训练中的三维并行性[2]是一个典型的例子。OBS可以通过进程数、计算持续时间和通信大小（每个端点）建模。如果计算和通信都很小，那么整体工作负载对延迟敏感，这种模式在HPC和AI推理中经常出现。大型通信在AI训练工作负载中通常具有带宽敏感性。

Latency-sensitive (LS)

对于某些工作负载，消息延迟（有时也包括消息速率）起着核心作用。其中一些属于OBS类别，但其它工作负载具有复杂的、数据相关的消息链，形成应用程序中的关键性能路径。这些通常是强可伸缩性的工作负载，解决方案的时间很重要，必须容忍低效的执行。严格遵守截止日期的大规模模拟，如天气预报和石油勘探，属于这一类别，但也包括一些事务处理或搜索/推理工作负载。在这种情况下，通常具有严格的（个位数微秒）延迟要求。

部署特性

除了流量类型外，部署环境也在发生变化。新出现的机密计算理念要求所有流量在传输过程中进行加密。理想情况下，流量在安全隔离环境中端到端进行加密和解密，不信任任何网络设备（网卡或交换机）。此外，新出现的多租户场景要求从单个主机管理数以万计的连接。这些通常由管理资源（如带宽和安全性）的智能网卡通过速率限制和过滤来支持。此外，新的成本效益高的低直径和专用拓扑结构对于极高带宽部署而言，更高级的负载平衡和路由成为必要条件[8]，[2]。这些要求的许多组合对下一代高性能网络提出了重大挑战。

RoCE需要改进的方面

RoCE的许多问题已经在过去进行了讨论[9]，并且已经有许多研究工作提出了各种解决方案[10]。在这里，我们概述了我们认为可以进行改进的潜在措施，并将其与上述关键工作负载和部署用例联系起来。我们现在提供一个列举的问题列表，可以改进以实现在基于以太网的高性能RDMA或智能网卡系统中更高效的操作。

1）PFC需要过多的缓冲区来实现无丢包传输

优先流控制（PFC）是实现融合以太网上无丢包传输的核心。通过PFC，接收方监视可用输入缓冲区空间。一旦此缓冲区空间降低到与带宽-延迟乘积BWRTT相关的某个阈值以下，它会向发送方发送一个PAUSE帧。此时，已经有BWRTT/2字节在传入线上，但在发送方接收到PAUSE帧之前，它将发送另外BWRTT/2字节。完全无丢包传输所需的最小缓冲区要求将是BWRTT + MTU，其中MTU是数据包的最大大小。然而，这仅适用于数据包立即被接收方处理的情况。即使是最轻微的转发延迟也可能显著降低链路利用率。

BWRTT缓冲区空间用于覆盖PAUSE消息的传输延迟，通常被称为“剩余缓冲区”，类似于InfiniBand或光纤通道中使用的基于credit的流量控制方案所需的缓冲区。在这些方案中，接收方主动向发送方发送credit（缓冲区分配），以保持输入缓冲区空间处于均衡状态，而不是在PFC使其过于充满之后才作出反应。这两种方案都有其优点：credit可以主动地向源端传递，而PFC方案在为不同源链路分配共享缓冲区空间时可以更具反应性（延迟绑定）。这两种方案基本上需要为每条链路保留BWRTT的空间，仅用于覆盖链路的往返控制延迟，这样就会导致有效转发的空间减少。

实际上，缓冲区空间对于吸收不断变化的流量峰值以进行时间和空间负载平衡非常宝贵。此外，仅仅是所需的剩余缓冲区，如果不冒着丢包的风险，无法用于其它用途，对于下一代交换机的扩展构成了重大挑战。图1a显示了在三层Fat Tree上，假设平均延迟为600ns（包括仲裁、前向纠错（FEC）和导线延迟）的9kB数据包和8个流量优先级类别（每个类别具有单独的缓冲区）的情况下，各种交换机世代所需的剩余空间（不包括其它缓冲区！）。随着高性能地理复制数据中心的普及，覆盖较长距离（从而引起延迟）也具有挑战性。图1b显示了相同配置情况下，每个端口所需的剩余缓冲区，假设端口速率为800G，导线延迟为5ns/m，以及不同的部署类型。

人们可能会考虑使用有丢失的链路层协议来重新利用这些缓冲区进行转发功能。然而，这会与错误处理协议发生交互，我们很快将看到。无论如何，浪费的缓冲区空间是影响所有可能受益于附加缓冲区的工作负载的一般问题，如果这些空间可用于数据包转发，将会提供帮助。

2）受害者流、拥塞树、PFC风暴和死锁

另一个问题源于PFC停止整个流量类别（仅使用三个比特进行编码）以及其中的所有流量。这可能导致受阻的受害者流：假设我们有两个流A和B共享一个链路L。流A没有拥塞，可以以满带宽发送。然而，流B在下游端口某处被阻塞，并填满了链路L的输入缓冲区。最终，链路L的分配缓冲区将被流B的数据包填满，并发送一个PAUSE帧。该帧还会停止流A的传输，而流A本来可以独立进行。因此，未拥塞的流可能会受到其它拥塞流的影响。这种现象也被称为排头堵塞（Head of Line blocking）。

由于下游端口的任何拥塞都会填满上游缓冲区，除非端点的拥塞控制协议作出反应，因此PFC事件可以快速形成逆向“拥塞树”，跟随网络中受害流量的流动。拥塞树是无丢包网络中的一个普遍问题，有时被称为PFC风暴。可以通过更细粒度地跟踪拥塞情况来解决这个问题，例如在个别流量而不是优先级的基础上。然而，这要求网络交换机维护流状态以识别个别流量。另一种方法是尝试将拥塞流动态地移动到拥塞优先级中，以避免受害者（参见拥塞隔离，P802.1Qcz）。另一个问题是无丢包通道现在消耗了已经稀缺的流量类别（独立的缓冲区空间）。这从数据中心提供商那里夺取了一个重要的资源，他们已经将这些流量类别用于差异化服务，如大流备份、低延迟视频会议等。用于RoCE（或其它无丢包）流量的任何流量类别都会在整个网络中丢失。

这种拥塞树对于incast工作负载尤其成问题，它们可能会阻塞整个网络，特别是在包级自适应或无感知路由的背景下。然而，在incast链路上，每个流量的带宽非常低，这意味着理论上这些流量只需要很少的网络缓冲区就可以饱和链路。RoCE拥塞控制的纯速率特性允许源端注入（过多）的数据包，这些数据包会迅速填满网络缓冲区。例如，基于窗口的方案将允许管理员直接控制每个流的网络范围内的缓冲区占用情况。

任何具有有限缓冲区的无丢包方案都会遇到死锁问题，如果路由允许形成循环。可以通过无环路由方案或特殊缓冲策略来避免死锁，但这都会带来一定的（小）成本。即使路由通常是无死锁的，链路故障后发生的瞬态状态也可能导致死锁。避免这些情况更加困难，但可以通过在交换机中配置数据包超时来动态解决这个问题。

3）回退N（Go-back-N）重传

RoCE的设计针对的是非常简单的硬件，遵循InfiniBand的有序和基于credit的无丢包传输。这意味着数据包只有在被位错误破坏时才会丢失，这是非常罕见的事件。因此，重传逻辑可以很简单：如果接收方检测到数据包流中的间隙（即跳过的序列号），它向发送方发送负确认（NACK）并丢弃所有后续数据包。然后发送方从丢失的数据包开始重新发送所有数据包。这个方案实际上丢弃并重传了一个完整的端到端的BW*RTT（带宽延迟乘积）的数据。

假设一个具有800Gb/s链路速度和最坏情况下每跳延迟为600ns的三层Fat Tree网络。端点观察到的总往返时间（RTT）将为3.6微秒。每条链路上的有效误码率可以高达1e-12（根据以太网规范提出的建议） ，我们假设使用9kiB的帧，单个帧丢失的概率为3.3e-8（有关推导请参见附录A）。因此，由于回退N重传而造成的总带宽损失可以忽略不计，仅为0.00013%。

简单的回退N重传方案的一个更大问题是它不支持多路径传输或无序传输。任何两个经过的数据包都会触发一次昂贵的重传事件，导致整个BW*RTT传输丢失。最新一代的RoCE网络接口卡引入了选择性重传来缓解这个问题。然而，这些功能通常是有限的。例如，NVIDIA的ConnectX6适配器不支持启用选择性重传的标签匹配的自适应路由。然而，回退N重传具有一个有趣的优势：如果发生了位错误并且数据包在较低层次被（悄悄地）丢弃，一旦下一个数据包到达，错误就会立即被检测到。而支持无序传输的其它方案需要等待发送方的超时到期，这可能导致更长的恢复时间和抖动。因此，在设计新的传输协议时，需要仔细考虑所有这些权衡。

4）拥塞控制与其它流量的协同

RoCE的默认拥塞控制依赖于与无丢包传输假设密切相关的非常简单的速率控制。许多研究人员已经意识到，这种简单的机制与TCP/IP等其它流量集成不良，并且在数据中心环境中通常可以改进。诸如DCQCN [5]、TIMELY [6]和HPCC [4]之类的机制构建在RoCE之上，以改善流量的传输。目前大多数RoCE部署使用非标准的拥塞控制机制，这导致不同供应商之间甚至同一供应商的不同硬件版本之间的互操作性困难。这是因为拥塞控制仍然是一个棘手的问题，不同的工作负载可能需要协议的不同调优版本。

例如，在无感知同步工作负载中，通常重复的端点非拥塞自由的大规模数据传输可以基于预期的流量模式进行快速学习甚至静态配置[2]，[13]。高度动态的incast场景需要通过接收方或网络信号协调多个发送方。小于带宽延迟乘积的小消息的延迟敏感工作负载可能是最棘手的，特别是如果它们以不可预测的数据驱动通信模式出现。这些可能需要依靠交换机缓冲区来吸收网络级的临时负载不平衡。总的来说，拥塞控制方案是并将继续是研究的重点，即使在部署后也需要不断进行调优。与TCP或QUIC等不同类型的流量共存还需要不断的采用。因此，这些方案不仅需要在硬件上快速和廉价，还需要灵活并支持广泛的参数化设置。

另一方面的论点考虑了交换机的队列大小和占用情况。数据中心交换机传统上具有大容量（深度）的缓冲区，以适应流量突发情况，而无需进行丢包来适应慢速的端到端速率调整。另一方面，用于HPC的交换机通常使用非常浅的缓冲区并具有严格的反向压力，这是由于它们可靠的链路级流控制机制所决定的[3]。此外，HPC网络拓扑通常具有比数据中心部署更低的直径[14]。因此，HPC部署支持较低延迟操作，因为小的数据包不太可能在较长的流量后面的缓冲区中等待。采用RoCE的数据中心网络通常在效率上结合了这两者：它们使用了带有所有问题的无丢包传输，而交换机的缓冲区相对较大。因此，许多现代拥塞控制机制的目标是保持缓冲区占用率较低，使这个非常昂贵的资源不被利用！

5）报头大小、数据包速率、可扩展性

RoCEv2除了InfiniBand的基本传输头（BTH）外，还使用了完整的以太网L2和UDP/IP报头。因此，每个数据包的报头开销相当大：22字节的L2报头、20字节的IP报头、8字节的UDP报头、12字节的BTH报头和4字节的ICRC，总共为66字节。例如，本地路由的InfiniBand只有总报头大小为20字节：8字节用于本地路由报头，12字节用于BTH报头。其它HPC协议的报头大小小于40字节。

这既影响原始数据包速率，也影响处理开销和成本，因为复杂的报头需要更多的报头处理。仅仅对于小有效载荷的数据包速率可能是有问题的。假设我们以8字节消息为例，用于共轭梯度求解器的单元素约简操作或精细全局图更新。在800Gb/s的链路上，最大速率（不包括报头）将达到12.5千亿数据包每秒（Gpps）。使用InfiniBand报头，速率将下降到3.5Gpps，使用RoCEv2报头将下降到1.4Gpps。数据包中将近90%是报头开销！而我们忽略了用于MPI或RDMA终端的其它协议报头。然而，鉴于目前的NIC数据包处理速度较慢（每个NIC小于1Gpps），报头大小可能不是最大的问题。此外，NIC需要处理确认数据包，这对于选择性确认和重传协议可能是特别具有挑战性的。高用户级和协议消息速率要求在NIC中进行并行处理，考虑到时钟速率的停滞。

RoCE的数据包格式与InfiniBand的传输层谓词紧密相关，它的基本概念是队列对（QP）之间的连接。单个连接的上下文状态大小取决于实现细节，但是大型集群的全互联可能会有问题。每个队列对至少需要保持连接信息和状态，如序列号、目标地址和队列对号码。连接状态可能相对较大，在某些实现中可达1kB每个连接。

在对延迟敏感的工作负载中，小数据包通常很重要，其中一些工作负载受限于NIC发出新消息的速率。更精简的报头潜在地降低延迟并增加消息速率，同时允许更高效的带宽利用率。

6）不支持智能堆栈

随着网络开销在数据中心工作负载中变得更加重要，设计了更智能的堆栈。例如，QUIC协议允许将传输处理推向应用程序，应用程序可以定义特定于应用程序的协议。这使得可以为不同的服务需求运行不同的协议，例如对延迟不敏感的视频流，对延迟敏感的音频会议，或者通常具有弹性但大型备份流量。RoCE的硬件加速哲学不支持不同的传输协议，即使用户级堆栈能够指定流量的其它属性（例如，将消息标记为对乱序传递具有弹性）。

新兴的智能网卡在这一领域带来了新的机会，用户可配置的内核可以在网卡上执行数据包和协议处理[15]。此外，网络中的遥测（INT）可以为这些协议提供额外的信号以做出相应的反应。因此，即使堆栈对流量类型有额外的了解，当前的RoCE也将其限制在相对简单且不灵活的协议中，无法充分利用这些知识。

7）安全性

RoCE已知存在一些安全问题[16]，[17]，特别是在多租户环境中。其中许多问题源于协议的安全性、身份验证和加密在设计时的次要地位。然而，今天，这些属性变得更加重要。

IPSEC可以用于保护L3报头和有效载荷，但需要基于每个队列对启用，以确保没有两个租户共享一组密钥。这在连接上下文开销和性能方面可能相当昂贵。此外，RoCE不支持将内存区域子委托给其它节点。这两个问题可以通过现代密钥派生协议来解决[16]。

8）链路级可靠性

向更高的收发器速度迈进导致了在不断增长的频率下运行的更复杂的编码和调制方案。在50G通道上，以太网从简单的两电平NRZ转移到了四电平PAM4编码。如今的100G通道以25GHz运行，接收器需要在纳秒级内区分四个电平。电缆和连接器中的信号衰减以及越来越复杂的模拟电路导致比特错误率（BER）很快会达到1e-4的高水平。

前向纠错（FEC）被引入以避免由于网络中丢弃损坏的数据包而导致过多的端到端重传。以太网在链路层目标为1e-12的误码率（BER），目前使用Reed-Solomon编码，使用包含514个这样的符号的块，以及30个附加的编码符号（RS544）。这使得接收器能够纠正15个随机比特错误和最多150个连续（突发）比特错误。其它FEC编码，如LLFEC（RS272，RS544的一半大小）和Firecode提供较低的延迟，但对比特错误的保护也较低。

一般来说，FEC带来的延迟和能耗成本分为两类：（1）累积5,140比特的数据和（2）编码和解码编码符号。前者随着链路带宽的增加而减少，后者取决于实现，实际上的延迟在20到100纳秒之间。图2显示了不同链路带宽下的预期RS544 FEC情况。

对于固定的RS544 FEC，延迟随着更快的链路带宽而减少，但不会低于FEC计算开销。然而，更快的通道可能导致显著更高的比特错误率。事实上，RS544可能无法将预期的1e-4的BER纠正到所需的1e-12。因此，未来的以太网标准可能采用更复杂的FEC机制，这可能会显著增加延迟。

在PCIe中使用了一种替代方法，它也涉及由于复杂连接器而导致的相对较高的BER，但它被设计为低延迟的本地互连，目标延迟约为5纳秒。例如，即将推出的PCIe 6.0规范使用6个字节的FEC来保护242字节的块，还有额外的8字节CRC。接收器首先使用FEC来纠正一些比特错误，然后检查CRC。如果此检查失败，它将启动一个简单的链路层重传协议以再次请求数据。FEC将比特错误率从1e-4降低到1e-6，然后CRC触发的重传概率小于1e-5。由于FEC导致的延迟增加不到2纳秒，由于重传导致的带宽减少不到2％。以太网面临的挑战是更长的链路导致更高的链路延迟。

系统问题

不断增长的链路级和因此的端到端延迟可能导致系统级问题增加。较高的延迟导致更高的缓冲区占用和能耗。不太明显的是，较高的延迟导致拥塞控制效率降低：传输速度快于单个往返时间（RTT）的消息无法从依赖接收器通知的拥塞控制机制中受益。因此，对于具有小消息的不良incast情况来说，情况变得更糟或至少更常见，因为“小消息”的大小增加。图3显示了当前数据中心中一些实际延迟下的带宽延迟乘积的大小，显示即使对于1 MiB的消息，通过限制发送者的速度来有效处理incast仍然被认为“太小”。因此，具有较高延迟的问题性incast模式可能会变得更加常见！

换句话说，如果系统可以快速地限制发送者的速度，那么可以将消息大小降低到incast成为问题的下限以下。这可以通过降低延迟或让交换机直接向源报告incast拥塞（而不经过接收器）来实现。此外，如果只有非常小的消息会导致糟糕的incast情况，那么交换机缓冲区可能在常见情况下仅吸收它们，而不会耗尽资源。当沿着incast树传播时，多组交换机缓冲区可以吸收瞬态incast消息，当然，这可能导致网络中的拥塞树。这样的整体系统问题仍然是一个开放的讨论话题，但似乎较低的延迟通常会简化这些问题。

还需要关注整体堆栈的其它方面，这些方面可能相当复杂。例如，简单而清晰的（远程）内存语义很难定义、推理和正确实现[19]。此外，将进程本地虚拟地址暴露给远程主机可能会对安全性和性能造成问题。可以考虑使用相对于内存区域的寻址方案[20]。从安全性的角度来看，这两种方案都有其弱点：暴露地址可以了解远程进程的信息，然而对于攻击者来说，固定偏移量更容易猜测[17]。我们指出，这些问题是所有RDMA系统的普遍问题，而不仅仅是RoCE。

路由和负载均衡仍然是一个开放性挑战-大多数HPC网络使用具有相对先进的网络内部机制的分组级自适应路由[3]，而大多数数据中心网络使用简单的由端点驱动的无感知ECMP，它通过更改头字段以非常简单的方式指导路径选择。数据中心中这种ECMP负载均衡的粒度从传统上的完整流量到最近考虑的流块都有。流块是具有足够间隙的连续数据包序列，即使沿不同路径发送，它们也无法相互交错。这种间隙可以通过延迟数据包或自然产生。最近，数据中心网络正朝着更细粒度的负载均衡机制发展。另一个挑战是一些应用程序要求按顺序传递消息。总的来说，乱序的粒度和能力严重依赖于应用程序的要求和端点NIC的能力。更细粒度和更好的乱序能力简化了网络负载均衡。

预测

基于所有这些观点，我们预测学术界和行业将重新审视数据中心以太网。下一代以太网可能会支持有损和无损的RDMA连接传输模式，以允许智能交换机缓冲区管理。这将使提供预留空间缓冲区成为可选项，并避免无损网络的其它问题，如受害流和拥塞树。下一代以太网也不太可能采用Go-Back-N的重传语义，而是选择更细粒度的机制，如选择性确认。此外，它可能会将拥塞管理作为规范的一部分。对于与其它流共存的情况，将特别注意，尤其是在有损流量类别中。这些协议将以灵活的方式设计，以支持智能的网络堆栈，安全性将最终成为重要的一环。我们还可能在报头和可靠性方法方面看到创新。

这些现代化将推动人工智能、高性能计算和存储系统的新一代高性能网络生态系统，这些系统是超大规模数据中心的核心。这种发展将结束HPC和数据中心网络的融合！

REFERENCES

1. T. Hoefler, A. Hendel, and D. Roweth, “The convergence of hyperscale data center and high-performance computing networks,” Computer, vol. 55, no. 7, pp. 29–37, 2022.

2. T. Hoefler, T. Bonato, D. De Sensi, S. Di Girolamo, S. Li, M. Heddes, J. Belk, D. Goel, M. Castro, andS. Scott, “Hammingmesh: A network topology for largescale deep learning,” in Proceedings of the International Conference on High Performance Computing, Networking, Storage and Analysis, SC '22, IEEE Press, 2022.

3. D. De Sensi, S. Di Girolamo, K. H. McMahon, D. Roweth, and T. Hoefler, “An in-depth analysis of the Slingshot interconnect,” in Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, SC '20, IEEE Press, 2020.

4. Y. Li, R. Miao, H. H. Liu, Y. Zhuang, F. Feng, L. Tang, Z. Cao, M. Zhang, F. Kelly, M. Alizadeh, and M. Yu, “HPCC: High precision congestion control,” in Proceedings of the ACM Special Interest Group on Data Communication, SIGCOMM '19, (New York, NY, USA), p. 44–58, Association for Computing Machinery, 2019.

5. Y. Zhu, H. Eran, D. Firestone, C. Guo, M. Lipshteyn, Y. Liron, J. Padhye, S. Raindel, M. H. Yahia, and M. Zhang, “Congestion control for large-scale rdma deployments,” in Proceedings of the 2015 ACM Conference on Special Interest Group on Data Communication, SIGCOMM '15, (New York, NY, USA), p. 523–536, Association for Computing Machinery, 2015.

6. R. Mittal, V. T. Lam, N. Dukkipati, E. Blem, H. Wassel, M. Ghobadi, A. Vahdat, Y. Wang, D. Wetherall, and D. Zats, “TIMELY: RTT-based congestion control for the datacenter,” SIGCOMM Comput. Commun. Rev., vol. 45, p. 537–550, aug 2015.

7. Message Passing Interface Forum, MPI: a message passing interface standard. Technical Report, September 2012.

8. M. Besta and T. Hoefler, “Slim fly: A cost effective lowdiameter network topology,” in Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, SC '14, p. 348–359, IEEE Press, 2014.

9. Chelsio Communications, “A rocky road for RoCE.” https://www.chelsio.com/wp-content/uploads/2011/05/ A-Rocky-Road-for-Roce-White-Paper-0112.pdf, 2012. Accessed: 2022-12-26.

10. R. Mittal, A. Shpiner, A. Panda, E. Zahavi, A. Krishnamurthy, S. Ratnasamy, and S. Shenker, “Revisiting network support for RDMA,” in Proceedings of the 2018 Conference of the ACM Special Interest Group on Data Communication, SIGCOMM '18, (New York, NY, USA), p. 313–326, Association for Computing Machinery, 2018.

11. P. Goyal, P. Shah, N. K. Sharma, M. Alizadeh, and T. E. Anderson, “Backpressure flow control,” in Proceedings of the 2019 Workshop on Buffer Sizing, BS '19, (New York, NY, USA), Association for Computing Machinery, 2020.

12. “IEEE standard for ethernet,” IEEE Std 802.3-2018 (Revision of IEEE Std 802.3-2015), pp. 1–5600, 2018. Section Four, clause 44.

13. T. Khan, S. Rashidi, S. Sridharan, P. Shurpali, A. Akella, and T. Krishna, “Impact of RoCE congestion control policies on distributed training of DNNs,” in 2022 IEEE Symposium on High-Performance Interconnects (HOTI), (Los Alamitos, CA, USA), pp. 39–48, IEEE Computer Society, aug 2022.

14. G. Kathareios, C. Minkenberg, B. Prisacari, G. Rodriguez, and T. Hoefler, “Cost-Effective Diameter-Two Topologies: Analysis and Evaluation,” ACM, Nov. 2015. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis (SC15).

15. T. Hoefler, S. Di Girolamo, K. Taranov, R. E. Grant, and R. Brightwell, “Spin: High-performance streaming processing in the network,” in Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, SC '17, (New York, NY, USA), Association for Computing Machinery, 2017.

16. K. Taranov, B. Rothenberger, A. Perrig, and T. Hoefler, “SRDMA: Efficient NIC-Based Authentication and Encryption for Remote Direct Memory Access,” in Proceedings of the 2020 USENIX Conference on Usenix Annual Technical Conference, USENIX ATC'20, (USA), USENIX Association, 2020.

17. B. Rothenberger, K. Taranov, A. Perrig, and T. Hoefler, “ReDMArk: Bypassing RDMA Security Mechanisms,” in Proceedings of the 2021 USENIX Security Symposium, USENIX, 2021.

18. D. De Sensi, T. De Matteis, K. Taranov, S. Di Girolamo, T. Rahn, and T. Hoefler, “Noise in the clouds: Influence of network performance variability on application scalability,” 2022.

19. A. M. Dan, P. Lam, T. Hoefler, and M. Vechev, “Modeling and Analysis of Remote Memory Access Programming,” in Proceedings of the 2016 ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications, pp. 129–144, ACM, Nov. 2016.

20. B. W. Barrett, R. Brightwell, R. E. Grant, W. Schonbein, S. Hemmert, K. Pedretti, K. Underwood, R. Riesen, T. Hoefler, M. Barbe, L. H. S. Filho, A. Ratchov, and A. B. Maccabe, “The Portals 4.3 Network Programming Interface,” tech. rep., June 2022. Technical Report SAND2022-8810, 2022.