IEEE发的公有云一哥AWS高性能网络协议论文，SRD-Scalable Reliable Datagram不鸟RDMA自己搞，原文地址
https://ieeexplore.ieee.org/document/9167399
0 摘要
亚马逊网络服务 (AWS) 对网络进行了重新梳理，以提供超级计算应用程序所需的持续低延迟，同时保持公共云的优势：可扩展性、按需弹性容量、成本效益以及快速采用更新的CPU和GPU。我们构建了一个新的网络传输协议，可扩展的可靠数据报 (SRD，Scalable Reliable Datagram)，旨在利用现代商业化的多租户数据中心网络（具有大量网络路径），同时克服它们的局限性（负载不平衡和无关流冲突时的不一致延迟）。SRD不保留数据包顺序，而是通过尽可能多的网络路径发送数据包，同时避免路径过载。为了最大限度地减少抖动并确保对网络拥塞波动的最快响应，在AWS自定义Nitro网卡中实施了SRD。SRD由EC2主机上的HPC/ML框架通过AWS弹性结构适配器（EFA，Elastic Fabric Adapter）内核旁路接口使用。
1 概述
云计算的主要好处之一是按照需要，瞬间提供和取消配置的资源。这与传统的超级计算截然不同，传统的超级计算机是定制的（需要数月或数年），因为其成本和容量限制，超级计算机通常是难以获取的。使用定制系统进行超级计算的主要原因之一是构建高性能网络并在应用程序之间共享的挑战。在云计算环境中，使用InfiniBand等专用硬件或专用于HPC工作负载的商用硬件都非常昂贵、难以扩展且难以快速发展。
AWS选择使用现有AWS网络（从100 Gbps开始）为客户提供经济实惠的超级计算，并添加了新的HPC优化网络接口，作为AWS Nitro卡提供的网络功能的扩展。
正如预期的那样，在共享网络上运行HPC流量会带来一系列挑战。AWS使用商用以太网交换机来构建具有等价多路径(ECMP)路由的高基数折叠 Clos 拓扑。ECMP通常用于使用流哈希在可用路径上静态地对流进行条带化。流到路径的这种静态映射有利于保持TCP的每个流的顺序，但它不考虑当前的网络利用率或流率。哈希冲突会导致某些链路上出现“热点”，从而导致路径间负载分布不均匀、数据包丢失、吞吐量降低和尾部延迟高（如 Al-Fares等人、Ghorbani等人、Handley等人、Hopps等人和Vanini等人在文章中广泛研究的那样)。即使在过度配置的网络中，大量流量也可能影响不相关的应用程序。
数据包延迟和数据包丢弃会干扰HPC/ML应用程序的低延迟要求，从而降低扩展效率。延迟异常值对这些应用程序具有深远的影响，因为它们通常遵循批量同步并行编程模型，计算的周期之后是整个集群的批量同步。单个异常值将使整个集群等待，阿姆达尔定律决定了可扩展性。
1.1 为什么不是 TCP
TCP是IP网络中可靠数据传输的主要手段，它自诞生以来一直很好地服务于Internet，并且仍然是大多数通信的最佳协议。但是，它不适合对延迟敏感的处理。对于TCP在数据中心，而最好情况的往返延迟差不多是25us，因拥塞（或链路故障）的等待时间异常值可以是50 ms，甚至数秒，即使当替代无拥塞网络路径之间的任何地方可用。这些异常值的主要原因之一是丢失TCP数据包的重传：TCP被迫保持重传所以超时很多，这也解释了操作系统延迟问题。
1.2 为什么不RoCE
InfiniBand是一种用于高性能计算的流行的高吞吐量低延迟互连，它支持内核旁路和传输卸载。RoCE（RDMA over Converged Ethernet），也称为InfiniBand over Ethernet，允许在以太网上运行InfiniBand传输，理论上可以提供AWS数据中心中TCP的替代方案。我们考虑了RoCEv2支持，弹性结构适配器(EFA)主机接口与InfiniBand/RoCE接口非常相似。但是，我们发现InfiniBand传输不适合AWS可扩展性要求。原因之一是RoCE [v2]需要优先级流量控制(PFC)，这在大型网络上是不可行的，因为它会造成队头阻塞、拥塞扩散和偶尔的死锁。郭在文章中描述了一种大规模PFC问题的解决方案，但它明确依赖于比AWS数据中心小得多的数据中心规模。此外，即使使用PFC，RoCE在拥塞（类似于TCP）和次优拥塞控制下仍会遭受ECMP冲突。
1.3 我们的方法
由于TCP和其他传输协议都不能提供我们需要的性能级别，因此在我们使用的网络中，我们选择设计自己的网络传输协议。可扩展的可靠数据报 (SRD) 针对超大规模数据中心进行了优化：它提供跨多个路径的负载平衡以及从数据包丢失或链路故障中快速恢复。它利用商用以太网交换机上的标准ECMP功能并解决其局限性：发送方通过操纵数据包封装来控制ECMP路径选择。SRD采用专门的拥塞控制算法，通过将排队保持在最低限度，有助于进一步降低丢包的机会并最大限度地减少重传时间。
我们做出了一个有点不寻常的“协议保证”选择：SRD提供可靠但乱序的交付，并将次序恢复留给上层。我们发现严格的有序交付通常是不必要的，强制执行它只会造成队列头部阻塞、增加延迟并减少带宽。例如，如果使用相同的消息标签，消息传递接口 (MPI) 标记的消息必须按顺序传递。因此，当网络中的并行导致数据包无序到达时，我们将消息顺序恢复留给上层，因为它对所需的排序语义有更好的理解。
我们选择在AWS Nitro卡中实施SRD可靠性层。我们的目标是让SRD尽可能靠近物理网络层，并避免主机操作系统和管理程序注入的性能噪音。这允许快速适应网络行为：快速重传并迅速减速以响应队列建立。
SRD作为EFA PCIe设备公开给主机。EFA是Amazon EC2实例（即虚拟和裸机服务器）的网络接口，使客户能够在AWS上大规模运行紧密耦合的应用程序。特别是，EFA支持运行HPC应用程序和ML分布式训练，目前支持多种MPI实现：OpenMPI、Intel MPI和MVAPICH，以及NVIDIA集体通信库。如图1所示，EFA提供了一个“用户空间驱动程序”，它利用操作系统 (OS) 绕过硬件接口来增强实例间通信的性能（减少延迟、抖动、避免OS系统调用、并减少内存副本），这是扩展这些应用程序的关键。
2 可扩展的可靠数据报设计
2.1 多路径负载平衡
为了减少丢包的机会，流量应该在可用路径上均匀分布。即使对于单个应用程序流，SRD发送方依然需要在多个路径上喷洒（Spray）数据包。尤其是对于重量流，以最小化热点的机会并检测次优路径。我们将SRD设计为与未启用多路径的传统流量共享网络，因此仅随机喷射流量是不够的。为了尽量减少繁重的传统流的影响，SRD避免使用过载路径，这可以通过为每条路径收集的往返时间 (RTT) 信息获取。
在规模上，偶尔的硬件故障是不可避免的；为了允许从网络链路故障中快速恢复，如果用于原始传输的路径变得不可用，SRD能够重新路由重传的数据包，而无需等待，需要2-3个数量级时长的，整个网络范围的路由更新收敛。此路由更改由SRD完成，无需重新建立昂贵的连接通路。
2.2 无序交付
平衡多条可用路径之间的流量有助于减少排队延迟并防止数据包丢失，但是，它不可避免地导致大型网络中的无序数据包到达。众所周知，恢复网卡中的数据包排序非常昂贵，这些网卡通常具有有限的资源（内存带宽、重排序缓冲区容量或开放排序上下文的数量）。
我们考虑让Nitro网卡按顺序发送接收消息，类似于常见的可靠传输，如TCP或Infiniband可靠连接(RC)。但是，这将限制可扩展性或在出现丢包时增加平均延迟。如果我们推迟向主机软件发送乱序数据包，我们将需要一个大的中间缓冲区，并且我们将大大增加平均延迟，因为许多数据包被延迟，直到丢失的数据包被重新发送。大多数或所有这些数据包可能与丢失的数据包无关，因此这种延迟是不必要的。丢弃乱序数据包“解决”了缓冲问题，而不是延迟问题，并增加了网络带宽消耗。因此，我们决定将数据包传送到主机，即使它们可能是乱序的。
应用程序处理乱序数据包对于字节流协议（如TCP）是站不住脚的，其中消息边界对传输层是不透明的，但在使用基于消息的语义时很容易。每个流的排序或其他类型的依赖跟踪由SRD之上的消息传递层完成；消息层排序信息与数据包一起传输到另一端，对SRD不透明。
2.3 拥塞控制
多路径喷洒减少了网络中间交换机的负载，但它本身并不能缓解incast拥塞问题。Incast是一种流量模式，其中许多流会聚在交换机的同一接口上，耗尽该接口的缓冲区空间，从而导致数据包丢失。这在以多对一通信模式连接到接收器的最后一跳交换机中很常见，但也可能发生在其他层。
喷洒实际上会使incast问题变得更糟，因为来自同一发送者的微突发，即使最初受到发送者链路带宽的限制，即使不同的路径依然有可能同时到达。因此，对于多路径传输的拥塞控制将所有路径上的聚合排队保持在最低限度是至关重要的。
SRD拥塞控制的目标是以最少的传输中字节获得公平的带宽份额，防止队列增长和数据包丢失（而不是依赖它们进行拥塞检测）。SRD拥塞控制有点类似于BBR，有额外的数据中心多路径考虑。它基于每个连接的动态速率限制，并结合飞行限制。发送方根据传入确认数据包的时间指示的速率估计调整其每个连接的传输速率，同时考虑最近的传输速率和RTT变化。如果大多数路径上的RTT上升，或者如果估计速率变得低于传输速率，则会检测到拥塞。该方法允许检测影响所有路径的连接范围的拥塞，例如，在incast的情况下，拥塞机制通过重新路由独立处理单个路径。
3 用户接口：EFA
Nitro卡上的SRD传输通过EFA向AWS客户公开。EFA接口类似于InfiniBand verbs。然而，其SRD语义与标准InfiniBand传输类型截然不同。EFA用户空间软件有两种形式：基本的“用户空间驱动程序”软件公开可靠的乱序交付，由Nitro卡EFA硬件设备本地提供；而 libfabric “供应者”层在驱动之上，实现数据包重新排序作为消息分段和MPI标签匹配支持的一部分。
3.1 EFA 作为Elastic Network Adapter的扩展
Nitro卡是一系列卡，可卸载和加速AWS EC2服务器上的网络、存储、安全和虚拟化功能。特别是，用于VPC的Nitro卡包括弹性网络适配器 (ENA) PCIe控制器，该控制器将经典网络设备呈现给主机，同时还为AWS VPC实现数据平面。ENA使用 PCIe SR-IOV来提供高性能网络功能，而无需管理程序参与；它将专用PCIe设备暴露给在AWS主机上运行的EC2实例，与传统的半虚拟化网络接口相比，可实现更高的I/O性能、更低的延迟和更少的CPU利用率。EFA是AWS上的Nitro VPC卡提供的附加可选服务，适用于HPC和ML的高性能服务器。
3.2 EFA SRD传输类型
与InfiniBand verbs一样，所有EFA数据通信都是通过队列对 (QP) 完成的，队列对是包含发送队列和接收队列的可寻址通信端点，用于提交请求以异步发送和接收消息，直接来自/送到用户空间。QP是昂贵的资源，传统上需要大量QP才能在大型集群（其中通常在每个服务器上运行大量进程）中建立全对全进程连接。EFA SRD传输允许如https://github.com/amzn/amzn-drivers/blob/master/kernel/linux/efa/SRD.txt中所述，所需数量的QP显着节省。EFA SRD语义类似于InfiniBand可靠数据报(RD)模型，但消除了RD限制（由处理从不同发送方到同一目标QP的交错分段消息的复杂性难以维持，同时提供有序传递）。与RD不同，SRD QP提供无序数据并限制消息大小以避免分段。这允许支持多个未完成的消息，而不会创建队头阻塞，以便可以多路复用单独的应用程序流而不会相互干扰。
3.3 乱序数据包处理挑战
EFA SRD QP语义为EFA上层处理引入了一种陌生的排序要求，我们称之为“消息层”，通常由HPC应用程序用于抽象网络细节。与成熟的传输实现（如TCP）相比，这种新功能是轻量级的，因为卸载了可靠性层。
理想情况下，消息传递层完成的缓冲区管理和流量控制应该与应用程序紧密耦合，这是可行的，因为我们的主要关注点是类似HPC的应用程序，它已经支持并且实际上更喜欢具有管理能力的用户空间网络用户缓冲区。
对于消息语义，如果应用程序消息传递层希望将数据接收到虚拟连续的缓冲区而不是收集列表中，那么对于大型传输的消息段的无序到达可能需要进行数据复制。这并不比 TCP 差，后者需要从内核缓冲区到用户缓冲区的副本。可以在 EFA 中使用 RDMA 功能避免此副本（超出本文范围）。
4 SRD性能评估
我们将 EFA SRD性能与AWS云上同一组服务器上的TCP（使用默认配置）进行了比较。我们不分析由于操作系统内核绕过而产生的差异，因为它对EFA的影响与经过充分研究的InfiniBand案例没有本质区别，并且它是与拥堵情况下网络流量通行为差异相比较小。
MPI实现是另一个对HPC 应用程序性能产生深远影响的因素，特别是对于早期版本 EFA 上的 MPI，如 Chakraborty等人的文章所示。12 由于我们的目标是评估传输协议，并且 MPI 实现超出了本文的范围，我们只在 OpenMPI 中使用了基本的 MPI 原语（包括重新排序逻辑），或者绕过 MPI 层的微基准测试。
4.1 Incast FCT 和公平
我们评估了从4个服务器发送的48个独立流，每个流运行12个进程，发送到单个目标服务器，在最后一个网络跃点处造成瓶颈。我们测量SRD和TCP的流完成时间( FCT)，并将其与最佳FCT进行比较，即在100%的瓶颈链路利用率在流之间均分的情况下的理想 FCT。
“突发”Incast FCT
我们在EFA/SRD或TCP上运行了MPI带宽基准测试，此时发送方使用屏障在大约同一时间开始每个传输。图2显示了不同传输大小的理想和最大FCT。SRD FCT接近最优，抖动非常低，而TCP FCT有噪声，最大时间比理想值高3-20倍。
图3显示了用于2 MB传输的FCT的CDF。超过50毫秒的TCP尾部延迟反映了重传，因为最小重传超时为50毫秒。即使仅查看50ms以下的样本（即，当延迟不是因于超时），大量样本也比理想情况高3倍。
持续拥塞Incast下的流量吞吐量
为了了解TCP的高FCT方差（即使忽略长尾导致的超时），我们检查了incast下的单个流吞吐量。我们使用绕过MPI的底层基准测试来测量连续发送数据时的吞吐量。我们每秒对每个流的吞吐量进行采样。在100 Gb/s的组合速率下，每个流的预期公平份额约为2 Gb/s。
图4分别显示了两个有代表性的发送方的TCP和SRD吞吐量。SRD流吞吐量对于所有流来说都是一致且接近理想的，而每个流的TCP吞吐量都在剧烈振荡，并且某些流的平均吞吐量远低于预期，这解释了FCT抖动。
4.2 多路径负载平衡
我们还评估了一个要求较低的案例，没有相关的负载。如图5所示，我们从位于同一个机架到位于另一个机架中的8个服务器，在一个全平分网络中。每台机器运行16个MPI等级（进程），所有数据都在不同的流上发送或接收到/从同一台远程机器。TOR交换机上行链路的利用率为50%，下行链路预计不会拥塞，因为只有一个发送方向发送数据到每个接收方。
图6显示了TCP和EFA的8个发送方之一的所有流的FCT（其他发送方看起来类似）。即使在理想的负载平衡下根本不会出现拥塞，但由于交换机间链路的ECMP平衡不均匀，TCP显然会遇到拥塞甚至丢包。TCP中位延迟变化很大，平均值比预期高50%，而尾部延迟比预期高1-2个数量级。中值SRD FCT仅比理想值高15%，最大SRD FCT低于平均TCP FCT。
5 结论
EFA允许HPC/ML应用程序在AWS公共云上大规模运行。它提供始终如一的低延迟，尾部延迟数量级低于TCP。这是通过SRD提供的新型网络传输语义，结合网络接口卡和不同主机软件层之间的非正统功能拆分来实现的。通过在Nitro卡上运行SRD多路径负载平衡和拥塞控制，我们既减少了网络中丢包的机会，又可以更快地从丢包中恢复。