翻译：AWS⾼性能⽹络技术SRD-⽤于弹性可扩展的HPC云优化传
输协议
啥也不是
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尽可能靠近物理⽹络层，并避免主机操作系统和管理程序注⼊的性能噪⾳。这允许快速适应⽹络⾏为：快速重传并迅速减速以响应队列建⽴。
图1 不使⽤和使⽤EFA的HPC堆栈
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传输类型夯实系数
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。
图2 最⼤FCT，突发48流incast
“突发”Incast FCT
我们在EFA/SRD或TCP上运⾏了MPI带宽基准测试，此时发送⽅使⽤屏障在⼤约同⼀时间开始每个传输。图2显⽰了不同传输⼤⼩的理想和最⼤FCT。SRD FCT接近最优，抖动⾮常低，⽽TCP FCT有噪声，最⼤时间⽐理想值⾼3-20倍。
图3显⽰了⽤于2 MB传输的FCT的CDF。超过50毫秒的TCP尾部延迟反映了重传，因为最⼩重传超时为50毫秒。即使仅查看50ms以下的样本（即，当延迟不是因于超时），⼤量样本也⽐理想情况⾼3倍。
图3 2 MB传输的FCT的CDF，突发48流incast
持续拥塞Incast下的流量吞吐量
为了了解TCP的⾼FCT⽅差（即使忽略长尾导致的超时），我们检查了incast下的单个流吞吐量。我们使⽤绕过MPI的底层基准测试来测量连续发送数据时的吞吐量。我们每秒对每个流的吞吐量进⾏采样。在100 Gb/s的组合速率下，每个流的预期公平份额约为2 Gb/s。
图4分别显⽰了两个有代表性的发送⽅的TCP和SRD吞吐量。SRD流吞吐量对于所有流来说都是⼀致且接近理想的，⽽每个流的TCP吞吐量都在剧烈振荡，并且某些流的平均吞吐量远低于预期，这解释了FCT抖动。
