今年的NSDI2022会议上，谷歌发布了其实验性的数据中心网络架构--Aquila，该架构支持谷歌提出的1RMA协议（SIGCOMM'20，解决RDMA用于多租户场景存在的隔离和安全问题），并在网络架构和芯片设计方面有诸多可学习之处，在此将文章翻译为中文，以飨读者。

摘要：数据中心的负载已经从十年前数据集中、耦合松散的工作负载转化为耦合紧密的工作负载，其中，超低延迟通信对于网络上的资源分解和启用新兴的编程模型至关重要。

我们介绍Aquila，Aquila是一种实验性的数据中心网络架构，将超低延迟作为核心设计目标，同时也支持传统的数据中心业务。Aquila使用了一种新的二层基于单元的协议、GNet、一个集成交换机和一个定制的ASIC，这个ASIC是和GNet一同设计，并具有低延迟的远程存储访问（RMA）。我们证明了：Aquila可以实现低于40us的IP流量往返时间（RTT），和跨越数百台主机甚至在面向后台吞吐量的IP流量中的低于10us的远程内存访问完成时间。这意味着运行在一个Aquila原型网络上的产品质量键值存储在尾部延迟方面减少了5倍以上。

简介

在过去的几十年中，数据中心网络已经取得了巨大的发展：在控制平台有了根本性的进步[18，27，44，49]，非阻塞拓扑结构的商品硅的出现[4，23，36，49]，网络管理与验证[7，8，29，41]，以及可用的网络设计技术[21]。总的来说，目前业界普遍采用具有成本效益、易于管理和可扩展的网络设计和部署。数以万计的服务器集群规模[49]的充足网络带宽可以用于型超大规模服务器及其承载的服务。

然而，所有这些进步都是在假设基于TCP的拥塞控制和以太网第2层协议的情况下实现的。经过几十年的部署和增量演进，这个2-4层协议栈已经非常稳固和有弹性。然而在数据中心出现了僵局[12]，分布式计算的进步越来越受到性能可预测性的缺乏和多用户数据中心网络隔离的限制。在网络架构设计者的目标以及应用程序的预期和编程方面，两到三个数量级的性能差异[15]并不少见，这严重限制了基于集群的更高级别分布式系统的创新速度。

当考虑到超算/HPC集群[17]和新兴的机器学习pods[22，28]的状态时，这种担忧被放大了，单个应用程序得益于低延迟的RDMA[16，51]、集体操作[46]和紧密集成的计算和通信能力。这些更专业的设置与生产数据中心环境的主要区别包括：

🔹 能够采用单用户部署，或者至少是空间共享而不是时间共享；

🔹 减少了对失败处理的关注；

🔹 愿意采用向后不兼容的网络技术，包括有线格式。

最近对分解机架架构[13，34]的研究进一步突出了一些挑战：相同的网卡和交换机是否支持跨广域的主机到主机通信，例如，SSD和GPU设备半径小得多的时候？分解网络是否必须是一个独立的专用架构，或者它可以多路传输TCP/IP流量，以潜在的100ms或更长的距离发送给远程主机? 虽然有一些吸引运行第二（或第三）网络专用对于单个用例，但是控制，和同样重要的每个网络引入了循环依赖的管理开销，在底层技术被证明/成熟之前，第二个网络相对于现状是不值得的。然而，没有机会在替代技术上进行迭代，因为这样做的成本和复杂性对未来几代都是负面的，因为在新硬件上展示端到端优势之前，应用程序必须实质性的发展。对向后兼容性的需求，加上部署小众“侧包”网络的挑战，威胁着数据中心网络和分布式系统的僵化，在这些分布式系统中，我们只能编程到TCP传输的最小公分母，以及与延迟、CPU效率和隔离限制相关的商用以太网交换机。

在这篇文章中。我们第一次提出了一种可选择紧耦合（或基于Clique）的数据中心架构——Aquila，一种支持可预测、高带宽和超低延迟通信的硬件实现。在我们的方法中，数据中心网络由几十个Clique组成，每个Clique托管大约1-2k个网口。Clique通过标准以太网和IP在数据中心接口（例如，现有的基于Clos的数据中心网络的主干层）上相互操作。然而，在Clique内部可以部署任意传输和二层网络协议。适合单个Clique边界的应用程序可以使用Clique本地功能，包括稳固的RDMA、可预测的低延迟通信、设备分解、支持ML聚合模块等。我们假设基于IP传输用于Clique之间的通讯，这意味着任何Clique内部的通信模块和创新必须与标准传输共存。然后Clique成为部署、创新和同质化的单元，允许增量的、向后兼容的部署到现有的数据中心。Clique也足够大，可以承载除最大的分布式系统之外的所有分布式系统，特别是每台服务器几百个计算核的时候。

Aquila，是基于一个定制的内部ASIC和通信软件，由一个单元交换的非以太网基板GNet组成的第一个Clique实现。

🔹 Aquila网络由单独的硅组件构成，这些硅组件充当网卡和传统机架顶部（ToR）交换机；每个ToR-in-NIC（TiN）芯片连接到主机上，并直接连接到其他TiN芯片上，以实现一个划算的网络，这种网络是由单个、重复的硅组件构建，而不是来自不同供应商的NIC和硅组件。

🔹 GNet为Aquila内部的主机以及在Aquila集群范围之外的非Aquila网络组件提供了以太网的假象，这是通过在Aquila网络边界终止以太网，和让流量通过一个完全定制的、自我防御的、几乎无损的L2衬底实现的。

🔹 Aquila建立了一个直接的网络而不是简洁的拓扑结构，这样进一步降低了成本。为了完全解锁Dragonfly拓扑[30]的功能、摆脱以太网事实上的约束，Aquila利用自适应路由，通过利用多个非最小路径，在主机对之间提供完整的点对点带宽。

🔹 Aquila以信元来传输数据，而不是数据包，降低了小型交换的延迟，例如基于RDMA和类似技术[51]的分布式系统那个所使用的。网卡和网络之间异常紧密的耦合实现了在至多1152个主机存储系统之间的超低远程存储访问读性能（4us 中位数）。

Aquila的设计和传统设计的不同体现在以下几个方面：1）链接使用基于信用的流量控制；2）交换机缓冲较浅；3）请求限定了端到端的接纳。任意一条原则在以太网中都是有问题的，但是一同考虑，就形成了一个成功的设计。例如，流控的、几乎无损耗的链接可以增加树饱和，尤其是浅缓冲，但是端到端接纳控制限制这些树的大小和扩展，并确保它们是短暂的。类似地，当有可能出现下降时，接纳控制会崩溃，但链路级流量控制出现下降的现象非常罕见，反过来又允许在切换元素中使用浅缓冲，因为不可能出现超限。

我们介绍了Aquila的详细设计、实现和评估。Aquila并不是Clique设计的最终定论。事实上，我们第一次使用Aquila系统的经验表明，未来几代有许多需要改进的地方。然而，我们希望带来垂直整合的方法，包括主机软件协议栈、网卡、交换机以及基于Clique的数据中心架构，可以使数据中心创新的新模型以及分布式系统的新能力成为可能，分布式系统可以在数千台或数十万台服务器的边界内是有优势的，而不是最低公分母的通信和分解能力。

>  目标及方法

Aquila的设计偏离了以太网，设计基于一系列共同的目标，描述如下。单独来看，这些设计选择——例如流量控制、自定义2层，将很难增量地应用于现有的网络。但同时，Aquila的特点实现了一个完整的、高性能的设计点。

硬件的可持续发展。为了用一个适度规模的团队来维持硬件开发工作，我们选择在同一硅片中构建一个具有NIC和交换功能的单芯片。我们的基本观点和出发点是，中基数的交换机可以以适度的额外成本集成到现有的NIC硅中，这些NIC/交换机组合称为ToR-in- nic（TiN）芯片，TiN芯片可以通过一个铜背板连接在一起，这个外壳只有传统ToR（Top of Rack）开关大小。服务器可以通过PCIe连接到pod实现网卡功能。TiN交换机可以通过最优的2层协议和GNet联通相同Clique下的服务器，通过标准以太网连接其他Clique下的服务器。插图1简要说明了TiN的主要组件。

图1:Aquila Clique数据平台和控制平台概述图。TiN芯片在右上角插入图部分展开。TiN芯片被安排在一个单元交换的Dragonfly网络中，通过以太网连接到其他的数据中心网络的主干交换机，通过PCIe连接到主机。传统的以太网/IP数据包在每个数据包经过一轮征求后在入口处被分成单元，然后在出口重新组装和排序。一同设计的1RMA协议直接将单元放入单元网络，拓展了Clique的内存访问，Aquila SDN控制器通过DCN对带内TiN交换机进行配置和管理。

成本低，非阻塞技术。考虑到效率和低延时，我们选择了一种直接连接的技术、Dragonfly、研究拓扑，当为实现统一的随机通信模式提供非阻塞带宽时，网络中长光链路的数量达到了最小，最坏情况对抗通信时超额认购为2：1。图1绘制了简单的Gragnofly拓扑结构，一个pod中的TiN完全连接在一个网格中，多个pod同样连接所有对所有，形成一个紧密耦合的Clique网络。最大的Aquila网络有48个pod，一个pod中支持12TiNs，可以服务至多1152台主机。

将NIC和ToR设计在单个TiN芯片上，相比独立的NIC和交换机ASIC程序是一种低成本的创新，同时由一个共同的单一组件实现的设计是为了简化Aquila的库存管理。此外，我们实现了一个可选的功能，允许每一对主机共享一个TiN，将每台主机网络的标准化拥有成本减半，同时降低了每台机器的持续带宽供应。

超低延迟网络：为了优化尾部带负载的超低延迟，Aquila实现了基于单元的通信，并为网络中的单元提供了浅层缓冲，为接近无损的单元传输提供了流量控制链路，硬件自适应路由在纳秒内对链路故障作出反应，并在高负载下保持网络负载平衡。为了确保接收方不会过载，Aquila在入口为每个包实现端到端请求，这保证了在包被分割成很多个单元并从源TiN传输之前，目的TiN的资源是可用的。我们将这些延迟保护协议构建在Aquila的二层协议中。如图1所示，Aquila网络架构在其边缘处有以太网包接口，Aquila通过GNet传输传统的以太网/IP包，在Clique的入口拆分并在出口处重新组装和排列。

用于传统流量和 RMA/内存分解的统一结构：为了应对数据中心负载日益增长的多样性[5， 42， 45]，Aquila将低延时的通讯模块（RMA）和商用模块（IP）统一到一个普通的架构中。同时具有高性能和传统连接的结构避免了侧边包网络（bag-on-the-side network）和辅助 NIC 的缺陷，从而降低了拥有成本和与两个独立网络的生命周期管理相关的工作量。管理单个网络的可用性、安全性、监控和升级十分有挑战——为单个用例管理单独的网络会在成本/收益分析中引入非常高的标准。为了在传统协议的基础上实现高效的远程内存访问和内存分解，我们共同设计了一个远程内存访问协议1RMA[51]，直接在GNet上扩展Aquila Clique的内存访问，而不是在IP上分层。

在更大的基于Clos软件定义的数据中心生态中共存：典型的数据中心网络是基于可拓展的Clos拓扑结构，其中聚合块通过主干交换层连接；Aquila通过以太网端口接入这样的网络。层次化的软件定义网络（SDN）具有模块化和微服务架构，管理和控制数据中心中虚拟的网络块。

图2描述了Aquila集成在更大的数据中心网络数据平台和控制平台生态中。Aquila网络块通过以太网连接到数据中心的主干交换层，类似于其他聚合块。数据中心网络的层次化架构实现了一种混合拓扑结构，即Dragonfly网络集成为一个更大的Clos拓扑中的一个块，据我们所知，这是第一次实现。

图2:Aquila Alique集成到更大的数据中心网络和SDN生态中和其他以太网聚合块共存。在拓扑结构上，Aquila块像其它基于以太网的块一样连接到基于Clos的数据中心。在控制平面，Aquila SDN控制器与其他块的控制器类似，与四个分片的块间路由控制器 （IBR-C）交互，实现跨块路由。

对于控制平台，我们采用了一个SDN控制器，通过一个运行在TiN CPU上的薄on-box固件来控制、管理、编程带内TiN（图1）。Aquila SDN控制器和其他聚合块的SDN控制器相同，和四个分片的块间路由控制器交互来实现和其他聚合块以及数据中心之外的网络的通讯。

Clique作为托管超低延迟应用的基础。为了利用Aquila提供的紧耦合、低延迟通信，我们使用作业调度程序来感知Clique的位置。高带宽或延迟敏感的作业可以有选择地在Clique的主机中进行调度，其他作业仍然可以跨块打包而不考虑位置。

硬件设计

在这一部分我们讲述了核心设计目标是怎么驱动硬件设计的，总结如下：

🔹 低延迟的目标促使选择浅缓冲单元交换的GNet结构。3.1节详细说明了GNet和链路级别协议的设计。

🔹 低成本的目标促使选择集成交换机和NIC芯片，TiN，以及直接拓扑结构，如Dragonfly。3.2节概述了选择Dragonfly的根本原因和设计中这样选择的影响。

🔹 IP流量和低延迟RMA的共享结构。3.3节描述了IP包怎么穿过GNet结构，3.4节详细讲述了1RMA协议和GNet架构的协同设计方面的内容。

> GNet交换机和链路

单元交换机：TiN芯片的交换能力由一个低延迟50端口单元交换机提供。选择160字节的最大单元大小来保持25G链路的序列延迟小（~50ns）。32 个端口是面向外部的 GNet 端口（其中 24 个是 Pod 本地端口，8 个是 Pod 间端口）。其余的18个端口是芯片内的，用于由各种流量端点（例如，IP和1RMA）传输和接收的单元。核心单元交换机的下降延迟为20ns，没有正向纠错（FEC）时每一跳的总延迟为40ns。GNet链路支持32个虚拟通道（VCs[14]）——FIFO队列用于避免死锁和QoS。VCs用于无死锁的路由，用于区分服务类别，并将请求流量和非请求流量分开。集中式仲裁器实现了iSLIP仲裁协议[38]的一个变体，支持每个VC每个端口一个仲裁请求，确保VC或端口不会出现吞吐量不足的情况。为了支持可变单元大小，我们修改了 iSLIP，以便入口和出口端口向交叉开关仲裁器传递“busy”信号。“busy”信号表明端口正在跨交叉开关传递单元。仲裁器在评估下一个请求-授予-接受周期的待处理请求时会考虑到这一点。VCs之间的服务质量（QoS）在输出缓冲区中实现，支持加权轮询和严格优先级。每个 VC 都有自己的输入 FIFO 空间，由可靠的信用机制保护，类似于 PCI Express 中使用的机制。为了节省内存，考虑了共享缓冲区、共享信用方案，但对于Aquila所需的相对较短的链接，首选的是独立fifo的简单性和完全QoS隔离。

GNet链路级协议：GNet链路支持大小在为16字节和160字节之间的单元，具有频繁的反向流控制流量。使用可变长度单元可以在网络上提供非常高的协议效率（例如，1RMA请求很小），即使在为准入控制增加了额外的控制流量之后。每一个GNet单元都有8字节的常规路由报头，包含16b的源和目的GNet地址、1单元长度和类型、VC、递减的跳数、8b的包头CRC和跟踪使能位。为了确保GNet单元的高效传输，开发了一个定制的66/64位物理编码子层（PCS），它最小化了单元划分开销，并允许反向流控制流量以非常紧凑的有序集发送。控制有序集用于：（1）规定单元的开始，（2）流程控制，（3）时间同步，（4）管理命令集（MOS）和（5）物理层上下控制和故障检测。

> Dragonfly单元结构

我们选择 Dragonfly 拓扑来管理光链路的成本，如图 1 所示。Dragonfly 单元结构使用两种类型的 GNet 链路实现：每个 TiN 24 个本地链路，完全连接 Pod 内的 TiN，每个TiN 8 个全局链路实现pod之间的连接，至多在数据中心那层上连接相距 100m 的 Pod。本地链路实现为单通道、28 Gbps 铜背板连接。全球链路是光学的，并使用专门开发的低成本 GNet 光学模块。FEC 可减轻全局链路上的噪声，导致每跳延迟损失 30ns 和 6% 的带宽开销。本地链路在没有 FEC 的情况下运行，以可接受的余量实现最低延迟。本地和全局链路最终都实现相同的链路级协议。由于 Dragonfly 拓扑的分层特性，GNet 地址具有三个组成部分：pod id、TiN id 和端点 id。端点代表稍后详述的协议引擎（IP、1RMA 和 CPU）

避免死锁：我们使用转向规则和 VC 在 Dragonfly 拓扑中实现死锁避免。使用我们 32 个 VC 的预案，希望尽量减少用于避免死锁的 VC 数量。在实现的路由方案中，我们在一个 pod 内采用类似于 [20] 中的奇偶校验符号方法的轮流规则，用于无死锁的 pod 内路由。当从全局链路移动到本地链路时，VC 会增加 [30]，总共需要 3 个 VC 用于在最差的无故障路由中避免死锁，即通过中间 pod 的非最小路由。考虑到 10 个流量类别，每个类别有 3 个路由 VC，另外两个 VC 在某些动态故障避免场景中可用作逃逸 VC。

自适应路由选择：大多数流量路由自适应地在 Aquila 的 Dragonfly 网络上实现高吞吐量和最低延迟。TiN 实现了本地自适应路由 [30， 48]，这是一种基于 GNet 交换机上的可用信息做出自适应路由决策的方案，特别是每个端口的每个 VC 输出队列长度。由于 GNet 的链路级流量控制和浅缓冲，这些队列深度反映了附近的拥塞。链路故障的表现类似，这也允许自适应路由算法绕过故障链路进行路由，直到 SDN 路由引擎删除已失去连接的链路条目。

自适应路由从路由表提供的 8 条路由中随机选择 2 条最小路由，并从 24 个非最小路由候选中考虑 3 条非最小路由。使用有利于最少路线的加权比较来评估五个候选路线。随机选择（而不是 24 路比较）使我们能够避免集群、协调自适应路由决策以及将拥塞从一个地方转移到另一个地方 [40]。其他路由模式通过将路由限制为仅最小路由来启用，或通过使用源地址和目的地址的哈希值强制确定选择路由启用。这些约束产生了 Aquila 的四种主要路由模式：完全自适应、最小自适应、确定性和最小确定性。确定性路由模式用于需要排序的单元类型。单元交换机使用基于表的路由，因为需要使用第 4.2 节中描述的 SDN 路由来处理故障和升级，以及其他拓扑的灵活性。

> IP流量

主机 IP 流量由传统 100 Gbps NIC 发送和接收，NIC支持最多两个独立主机的多主机操作的。多主机功能选项被认为很重要，以便在每台机器分配带宽方面提供一定程度的灵活性。TiN 芯片上还有另外两个 IP 流量来源：用于连接 Aquila 结构外部的 100 Gbps 外部以太网端口，以及连接到嵌入式管理处理器的低带宽端口。来自所有 IP 源的流量以相同的方式处理：数据包处理流水线执行 IP 路由和单元化，即使用 Aquila 的 IP over GNet 协议将 IP 数据包分成 GNet 单元并将它们传输到目的地址。

包处理逻辑：通过 GNet 结构的每个 IP 数据包只经过输入数据包处理和输出数据包处理块一次。实际上，整个 GNet Clique 充当单级 IP 数据包交换机。输入数据包处理流水线处理：

🔹L3到GNet L2的地址转换（一对一或者WCMP[55]）

🔹 有选择地将一些数据包放入嵌入式控制处理器

🔹 输入缓冲区QOS

处理后从入站数据包中剥离 L2 以太网 MAC 地址；通过GNet安源网络的包传输仅适用于 IPv4/IPv6。非 IP 数据包（例如 ARP）可以封装或发送到嵌入式控制处理器，符合我们的 SDN 控制平台（§4）的要求。

GNet上层的IP协议：IP 流量通过 GNet 上层协议穿过 Aquila，如图 3 所示。通过单元结构发送的每个 IP 数据包都会发出请求发送 （RTS），并在传输任何数据之前等待清除发送 （CTS） 握手。这些以 16 字节 GNet 单元的形式发送，以最大限度地减少带宽开销。握手协议执行三个功能：

🔹 当目标端点已经发出信号，它有足够的输入带宽和缓冲空间来接收它们时，通过只允许数据单元进入GNet网络来实现对IP数据包的请求。

🔹 它在数据单元传输之前，先在目的地址分配硬件资源，例如单元数据包重组缓冲区，以便始终有保证的重组空间。

🔹 RTS 定义了包间顺序。尽管数据单元会自适应路由并可能乱序到达目的地址，但 RTS 排序确保可以在接收端重建原始传输顺序。

图3:单元化：IP 数据包被拆分为多个 GNet 数据单元，这些单元仅在入口 TiN 接收到 CTS 时才被允许进入 GNet 结构。在出口数据包处理程序中，信元按照原始传输顺序重新组装成数据包，然后发送到 NIC（都在 TiN 芯片内）。

经过数据包处理流水线且具有有效 GNet L2 地址的数据包存储在数据包入口缓冲区中。会立即生成 RTS；事实上，对于长数据包，可以在收到整个数据包之前发出 RTS。RTS 本身由 8 个字节的路由标头和另外 8 个字节的有效载荷组成，其中包括 IP 数据包长度、服务等级 （CoS）、数据包在入口缓冲区中的位置以及入口缓冲区使用情况的指示器。紧凑性很重要，因为 RTS 单元是未经请求的，并且仍然可能导致 incast。但是，考虑到平均数据包大于 1K，RTS单元的 incast 表示网络中的 incast 量减少了 64 倍。

RTS 单元在它们自己的 VC 上传输，允许它们以高优先级发送，并保持请求信元和非请求信元之间的隔离。RTS VC 在 GNet 结构上确定性地路由，使用由信元的流不变字段的哈希值选择的路径，确保给定 IP 流的 RTS 单元按照它们发送的顺序被接收。RTS 单元在数据包出口处被接收到 FIFO 队列中。数据包数据传输由出口端通过将 CTS 发送回合适的入口端口来启动。除了 8 字节的路由报头，CTS 还携带一个指向入口缓冲区（从 RTS 复制）中的数据包的指针和一个指向出口单元到数据包重组缓冲区中分配位置的指针。CTS 单元由 CTS 调度程序发布，该调度程序跟踪出口重组缓冲区容量的可用性，仅当有空间可用于将单元重组为数据包时才发布 CTS。

当在数据包源接收到 CTS 时，相关数据包会从入口缓冲区中作为一系列纯数据单元取出，然后进行传输。数据单元可以（自适应地）采用许多不同的路线通过，并且数据单元可以以任何顺序到达最终目的地。单元在目的地的出口缓冲区中重新组装成数据包。出口缓冲区的大小由输出端口带宽和单元结构往返延迟的带宽延迟乘积以及数据包重新排序延迟的余量决定。数据包在主要用于重组的出口缓冲区中没有明显排队，因此出口缓冲区明显小于入口缓冲区。

为了保持流中的数据包顺序，当调度程序发出 CTS 时，根据RTS到达顺序，将包重排序逻辑写入包描述符。一个数据包在接收到其所有数据单元后可在出口传输，但可传输数据包将被保留，直到同一流中按 CTS 发出顺序在其前面的所有数据包已成功转发到 NIC。

RTS/CTS 方案的一个显着好处是，RTS 队列可以本地查看整个 GNet 结构中对该目标端口的所有请求数据包需求，而数据包数据仍然在入口缓冲区中排队。在存在严重 incast 的情况下，可以在保留带宽的同时丢弃数据包，即没有数据包数据穿过单元结构。出口端可以通过发出 CTS 的变体（Clear To Drop，CTD）来选择丢弃数据包，该变体从入口缓冲区中取出数据包并将其丢弃。当在深度超过给定阈值的 RTS 队列中接收到 RTS 时，发送 CTD。RTS 队列的深度还为显式拥塞通知 （ECN） 标记提供了信号；如果 RTS 队列在数据包已重新组装并准备好发送时超过标记阈值，则应用 ECN。

IP的QoS支持：每个独立端口和服务等级都有单独的 RTS 队列，总共 32 个 RTS 队列，在四个独立端口上支持八个 CoS：一个端口用于外部以太网 MAC，两个用于双主机 NIC，一个用于控制处理器。CTS单元由数据包目的地址的 CTS 调度程序发出，该调度程序在 32 个 RTS 队列之间分配带宽，在各个队列之间实现每个 IP 数据包的 QoS。CTS 调度程序可以通过根据未完成的数据包获取的窗口限制 CTS 问题来限制进入出口缓冲区的流量，可以调整该窗口以最小化单元结构内的数据单元的排队。调度程序不会尝试在源之间实现带宽公平，因为到给定目标端口的所有源共享相同的 RTS 队列。

> 1RMA

为了将 Aquila Clique 的低延迟功能直接提供给分布式系统程序员，我们在 TiN 芯片中构建了 1RMA [51] 。1RMA 是一种 RMA 协议，它为主机上的软件提供无序、分段、请求的远程内存访问模块（读、写和atomics）——这些原则与 RTS/CTS 管理的 GNet 数据包传输的原则完全匹配。

这种排列不仅仅是巧合。我们共同设计了Aquila和1RMA基于GNet的协议。我们不是简单地将1RMA协议报文分层到数据包层之上，而是将1RMA协议交换在GNet中与RTS和CTS一起表示为一级单元类型，而不是在顶部，并确保它们在共享Aquila结构时遵守类似的端到端请求规则。协同设计的优点是显著节省了延迟：虽然Aquila上的UDP/IP或TCP/IP往返会在其关键路径（RTS、CTS、数据，每个方向）上产生六次GNet半往返，但1RMA读取操作只会产生两次，从面向用户的延迟中节省宝贵的微秒。

我们通过完全在GNet帧内编码1RMA读取请求来实现协议协同设计。从根本上说，读取请求启动了从接收方到发送方的数据传输，也就是说，这种请求本质上已经是在传输层表达的请求。但在L2层，GNet也建立在请求的基础上。关键见解是在单个单元类型Req中表达GNet（L2）和1RMA（L4）请求行为。由于Req单元请求反向数据移动，所以GNet处理Req的方式与CTS类似；主要区别在于单元大小，因为Req对读取请求（主机地址、内存标识符、HMAC等）进行了完全编码，从而在48B时产生比CTS大3倍的单元。Req在其他方面的行为类似于CTS，因为它可以自由地重新排序，而不会违反上面协议层的假设。由于1RMA对无序传输具有高度容忍度，因此Req本质上与Aquila的自适应路由兼容。

我们还利用1RMA与面向主机的PCIe的紧密耦合，对响应单元进行编码。1RMA NIC将每个单独的PCIe读取完成负载作为不同的协议响应发送，这是一种硬件简化，可避免NIC中的响应合并逻辑、缓冲和开销。为了促进GNet中的这种行为，Resp单元的大小可以处理我们从主机根复合体观察到的最常见PCIe完成大小。与Req一样，Resp可以自由地重新排序和自适应路由，并且启动的1RMA网卡按到达顺序在目标主机内存中获取单个响应段，因为不需要恢复整体互操作或请求内响应顺序。

最后，为了将延迟关键的1RMA流量与不太敏感的IP流量隔离开来，我们映射了大约一半的 GNet 虚拟通道来传输低延迟协议报文，1RMA 与低延迟 IP 流量共享这些报文。由于IP流量是单元化的，1RMA响应不会在来自竞争流的批量传输之后排队。总之，Aquila 上的1RMA可在4us端到端内向大约 864TB 的 DRAM 提供近乎平坦的查找延迟（即使在传统流量的负载下）。Aquila 遍历仅占 2.5-3us；剩余时间归因于 PCIe 延迟。

> 嵌入式控制处理器

TiN 芯片具有嵌入式控制处理器 （ECP），可处理所有开关侧控制和监控动作。硅成本迫使 ECP 尽可能简单，因为它在每个 TiN 芯片中都使用。ToR 的典型控制处理器可能是具有 8-16 GB 内存的多核 64 位处理器，而 TiN 的 ECP 是只有 2 MB SRAM 的 32 位 ARM Cortex M7 处理器。

为了在 GNet 逻辑完全初始化（第 4.4 节）之前引导嵌入式控制处理器，使用管理有序集 （MOS） 在 GNet 结构上实现低带宽但可靠的带内控制路径。每个 MOS 64 位字允许在直接连接的 TiN 芯片之间传输 6 个字节的数据，无论 GNet 链路层是否启动。我们在 MOS 模块之上分层了一个强大的的数据包实现 PMOS，以承载调试和引导流量。

> 所有总和在一起

图4绘制了TiN芯片的整体结构：

🔹 单元交换机（单元结构的构建块）；

🔹 传统的IP 主机接口（NIC）；

🔹 一个面向外部的以太网MAC，用于连接外部网络；

🔹 1RMA 主机接口，支持跨单元结构的直接协议； 

🔹 IP 数据包到单元（入口）和单元到IP 数据包（出口）逻辑；

🔹 嵌入式控制处理器，作为SDN 控制软件的本地代理。该设备具有以下接口：

🔹 两个 x16 PCIe 第 3 代接口，为一个主机提供 256 Gbps 的连接，或为两台主机中的每一个提供 128 Gbps 的连接；

🔹 32 个 28 Gbps 单通道 GNet 链路，用于构建低延迟单元结构；

🔹 一个100 Gbps 以太网接口，可连接到更广泛的数据中心网络（DCN）。

大约 50% 的 TiN 硅面积用于实现主机接口或 NIC 功能，50% 用于交换功能。

图4:Aquila 芯片架构展示了 GNet、IP、嵌入式控制处理器、1RMA 和 PCIe 组件。

软件定义的网络

正如第 3 节所说，将交换机和 NIC 集成在单个芯片中会导致管理子系统在 Aquila Clique 中的所有 TiN 上大量使用。为了保持 Aquila Clique 的成本效益，TiN ASIC 的管理子系统保持简单——一个32位 ARM Cortex M7 处理器，具有适中的 2MB SRAM，没有专用的管理以太网端口。最后，很多路由计算和状态需要从交换机卸载到逻辑集中的分布式控制器，该控制器必须协调带内结构的引导、管理和控制。在本节中，我们将描述 Aquila 的软件定义网络 （SDN） 控制平台及其简化的固件如何能够解决控制和管理 Aquila Clique 的问题，特别是：

🔹 SDN 中流状态的爆炸式增长（第4.2节）。

🔹 切换具有受限 CPU/内存的固件（第4.3节）。

🔹 整个网络的带内引导（第4.4节）。

> 控制架构概述

Aquila 控制器建立在 SDN 控制器平台 [18]、由微服务组成的模块化 SDN 控制平台和被称为网络信息库 （NIB） 的中央发布者/订阅者数据库之上。多个应用程序形成一个 Aquila SDN 星座，每个应用程序的冗余实例部署在单独的控制服务器上。图5的上半部分详细介绍了 Aquila SDN 控制器应用程序。

图5:Aquila 的 SDN 和固件架构概述

控制器的路由应用程序——路由引擎 （RE） 计算 Aquila 网络块的路由解决方案，以响应拓扑状态和外部可达性的变化。RE 以类似于 OpenFlow [39] 的流和组的形式将解决方案按顺序批量写入 NIB，以实现无命中的路由状态转换。另外，块间路由控制器 （IBR） 是数据中心范围的 SDN 控制域中的一个应用程序，它计算各种网络块之间流量的路由解决方案，并为Aquila的RE提供到达 Aquila Clique 外部目的地地址出口路径。

在接收到来自 NIB 的路由更新时，流管理器（FM）对流和组编程操作进行排序。例如，只有在安装其引用组以实现无命中转换之后，才会安装流，然后再通过RPC将它们发送到Switch Front-End应用程序（SFE）。SFE将流和组编程到TiN交换机，在流/组和硬件寄存器值之间进行转换，并用编程结果完成RPC。然后FM将结果写回NIB以供RE使用。

> 处理路由状态

架构中的大量GNet端点和TiN交换机中每个端点的GNet 路由表导致路由状态比非Aquila块大得多，这增加了SDN系统中的CPU和内存需求。Aquila 路由为IP和GNet流带来了扩展挑战。

IP流。一个由1152台主机和576个管理 CPU 组成的网络，可通过 IPv4 和 IPv6 寻址，需要大约190万个流，每个流都有一个输出端口。利用所有这些流都来自少数子网的观察结果，我们引入了一种新的索引组表示，其中组中端口的索引对应于子网中的相同索引，从而减少了流的数量576倍（架构中 TiN 的数量）。

GNet流。如第3节所示，流量控制的 GNet 需要每个输入端口、每个虚拟通道的流量，这会导致具有50个端口的交换机的状态爆炸。一个简单的实现会导致近500万个流量。为了适应如此大的规模，我们利用了路线的显着相似性。例如，第3.1节中描述的所有终端端口都使用相同的路由，并且在NIB中只表示一次。类似地，死锁避免转向规则为 TiN 芯片中的每个Pod内端口定义了类似的角色。此外，所有 pod间端口的行为都相同。我们引入了六个端口类——表示与路由规则相关的端口等价类——将流的数量减少到大约700k。GNet 流使用端口类作为匹配字段和输出操作。在使用端口类接收 GNet 流时，SFE 将其扩展为针对每个成员端口的 GNet 流表的流，然后从输出中删除不正确的成员端口，例如，以避免将流量发送回源。然后在交换机中对产生的流量进行编程。

🔹 即使进行了这些优化，SDN 系统的其余部分也需要进行更多修改：

🔹 尽管进行了端口级优化，NIB 中的流量数量仍然是非 Aquila 网络块的10倍左右。为了弥补内存的增加，NIB 的 pub-sub 接口被更改为保持压缩格式的状态并仅在必要时解压缩。

🔹 TiN 交换机中可用的 SRAM 不够大，无法保存所有路由状态的快照。SFE 具有对硬件编程操作进行速率限制的能力，以避免交换机上的内存溢出。SFE 和交换机之间的 RPC 接口的设计方式是最大的 RPC 可以容纳在内存中，并且一次只允许一个未完成的 RPC。

> 状态受限的切换固件

开关固件（参见图5的下半部分）在集成到 TiN 开关芯片中的 ARM Cortex M7 CPU 上运行。由于物理尺寸和成本限制，固件只有2MB的片上 SRAM 可用。因此，它建立在 FreeRTOS [1] 和 lwIP [2] 开源库的基础上，以适应空间限制。该固件以大约100k行的C和C++代码实现。

我们明确的是固件不负责完全配置 TiN 芯片。开机时，固件会启动 GNet 和以太网链路并尝试通过以太网进行 DHCP。这使控制器能够在初始化期间及早连接并完成必要的配置以允许 TiN 芯片开始传递流量（详情请参考第4.4节）。

固件公开的编程API是低级的，也允许SDN控制器直接访问硬件寄存器。API由硬件寄存器描述生成，并允许SDN控制器代码为方便使用芯片寄存器的符号名称。TiN芯片的统计数据和计数器也可以使用低级API报告。SDN控制器能够配置一组应由固件定期报告的寄存器。其中一个编程API设置 ARP/NDv6 响应以响应来自连接机器的请求，以便即使固件失去与 SDN 控制器的连接，IP到MAC的解析也可以正常工作。

该固件支持不间断转发（NSF）重新启动，以最大限度地减少升级和意外软件错误造成的中断。在重新启动期间，固件会避免更改任何可能影响流量的配置。由于带内连接没有中断，控制器能够在重新启动后快速重新连接，而无需通过引导过程。由于不需要保存和恢复状态信息，因此寄存器级 API 的存在简化了NSF 重启的实现，因为 TiN 芯片在重启期间保持所有控制器可见状态。

虽然固件本身是无状态的，但 TiN 芯片和 SDN 控制器却不是。在固件和 SDN 控制器之间的任何连接丢失后，必须启动协调过程以解决硬件寄存器和 SDN 控制器意图之间的任何差异。如果在连接失败时丢失了任何命令，这些差异就会出现。

> 带内控制和引导

Aquila SDN 控制的一个关键挑战是从 SDN 控制器到 Aquila 交换机的控制通道是带内的。这意味着控制器需要先与TiN的管理 CPU 通信，然后才能对TiN的路由表进行编程。在引导期间，控制器通过数据中心网络在迭代“波”中建立与Clique中所有TiN的带内TCP连接，配置和编程路由表，因为它在每个后续波中获得对TiN的控制。

k个Aquila pod通过pod内铜GNet链路以及pod间光GNet链路连接。一些TiN（例如，Pod 1和Pod k中的 TiN 1、TiN 3）也通过以太网数据中心网络（DCN）链路连接到数据中心的主干层。我们将这些TiN称为DCN连接。Aquila SDN 控制器——在外部控制服务器上运行——最初只能通过 DCN 链路访问。如果可用，TiN 固件会通过DCN链路发送DHCP发现报文。这些DHCP报文由主干交换机中继到DHCP服务器，然后根据TiN MAC地址为TiN管理CPU分配一个 IP 地址。

Aquila 控制器根据自己的配置记录了用于每个TiN的CPU的IP地址。控制器不断尝试使用分配的IP地址和L4端口号通过TCP会话连接到每个TiN CPU。一旦TiN的固件知道IP地址，发往该IP的控制器报文就会被固件安装的ACL规则捕获并到达固件。响应Ack从数据包传入的同一接口发送出去，从而在控制器和连接DCN的TiN的交换机 CPU之间启用TCP连接。然后，控制器可以配置连接DCN的TiN并对其路由表进行编程。

一旦控制器与DCN连接的TiN 建立TCP会话，它就会使用该TiN 作为代理TiN（例如，Pod 1、TiN 3）来使用指向直接连接的目标 TiN（例如，Pod 1、TiN 2），被使用的TiN会引导TiN CPU 之间的点对点低带宽数据包管理有序集 （PMOS） 协议 （第3.5节）。目标TiN（尚未配置其 IP 地址）还通过所有 GNet 链路通过 MOS 发送 DHCP 发现报文，这些报文被代理TiN 捕获并通过其自己的会话发送到控制器。控制器依次将发现报文中继到DHCP服务器，并同样中继DHCP响应，以便目标TiN间接了解其分配的IP地址。控制器通过PMoS上的代理 TiN 继续配置和编程目标TiN中的路由表。在对足够的路由状态进行编程后，控制器可以通过GNet路由流水线建立到目标TiN的TCP连接，然后可以依次使用代理TiN（Pod 1、TiN 3）来引导另一个目标TiN（例如，Pod 1、TiN 4）。一旦和新TiN对象建立了TCP会话，TCP会话也可以用作代理来引导直接连接的 TiN（例如 Pod 1、TiN 5）等等。

DCN 连接的TiN通常比目标TiN引导得更快，目标TiN通过较慢的PMOS协议进行配置，导致引导时间分布在3分钟到48分钟之间。几波引导程序同时发生，导致全尺寸Clique的启动时间约为2.5小时。

实验结果

我们展示了一组研究 Aquila 网络关键方面的结果，包括其数据平台性能及其对应用程序指标的影响。

> 数据平台性能

Aquila 的数据平台性能在由576个 TiN 组成的原型 Aquila 测试台中进行了评估。我们使用了500台主机。除非另有说明，否则两台主机共享一个NIC。我们使用了两个工作负载，它们都运行基于延迟的拥塞控制 [33]：

1. UR：基于用户空间微内核 Pony Express [37] 的 IP 流量生成器，可生成具有泊松到达的统一随机流量模式。

2. CliqueMap：通过Pony Express或1RMA使用远程内存访问 （RMA） 的键值存储[50]。

对于我们的评估，我们使用了三个指标：

1. IP组件RTT（µs）：我们使用NIC硬件时间戳来测量Aquila架构 RTT，不包括远程主机上的处理和合并延迟。这是对GNet和IP组件在 Aquila结构内的传输和排队延迟的真实测量。

2. 1RMA 总执行延迟（µs）：从硬件接收到RMA 命令到硬件发出完成该命令的时间。该指标衡量的不仅仅是结构中的排队和传输延迟，因为它包括远程端的 PCIe 事务延迟。

3. 以 Gbps 为单位实现的网络吞吐量（平均超过 30 秒）。

负载下的延迟。我们检查了负载下 IP 和 1RMA 流量的延迟。我们使用了一个CliqueMap客户端基准测试，它使用 RMA 发出 4 KB 大小的值的查找。通过改变 500 台主机上CliqueMap客户端的 QPS，我们以类似于均匀随机的流量模式更改了每台机器提供的负载。图6绘制了结构 RTT 与提供的负载的关系。它显示即使网络接近每台机器 NIC 线速 50Gbps，结构延迟保持在 40 µs 以下，并且在 70% 负载时低于 20 µs。

1RMA 与 GNet（第3.4节）共同设计，图 7 显示了这种共同设计的成效，即使在高负载下使用500个CliqueMap客户端从500个 CliqueMap中读取 4 K RMA， 读取的总执行时间低于 10 µs。

图6（左图）延迟随负载的变化，结构队列在负载下仍然较低

图7（右图）变化1RMA负载时 RMA的读延迟

1RMA 延迟隔离。 Aquila 是一个低延迟 1RMA 流量和可能对延迟不敏感的常规IP流量共享的统一网络。在我们接下来的评估中，我们展示了Aquila尽管与IP流量共享网络，但仍以低尾部延迟提供对延迟敏感的流量。为此，我们比较了 Aquila 和传统以太网网络中具有和不具有背景 IP 流量的延迟敏感流量的延迟。

对于以太网，我们采用标准 QoS 技术将低延迟（或重要）流量与面向批量吞吐量的流量隔离开来。我们在较高优先级QoS类 （H） 上运行200个4 KB 值的CliqueMap查找实例，在10，000 QPS上运行具有64 KB报文的UR流量模式，在较低优先级类（L）上平均负载为 10 Gbps。H类和L类之间的相对出口调度优先级为8:1。图 8 中的橙色和青色条显示，此类基于 QoS 的方案为CliqueMap流量与大量 IP 流量提供了合理的隔离，导致HiPri CliqueMap流量的结构 RTT 中的排队适度增加，尽管基线延迟较高。

使用1RMA传输重复相同的实验，我们可以看到尽管与 IP 流量共享相同GNet结构，Aquila上的1RMA提供了低得多的基线（小于5 µs的中部和尾部延迟）。高优先级1RMA流量使用与低优先级 Pony Express IP流量使用不同的虚拟通道，因此几乎不受添加批量流量（蓝色和红色条）的影响。即使低优先级1RMA流量与批量 IP 流量（黄色和绿色条）共享虚拟通道，总体延迟也略高于 10 µs，但仍低于以太网网络上的Pony Express流量（橙色和青色条）。

图8:1RMA 隔离：Aquila 为 1RMA 流量提供低延迟，在与 IP 共享网络时也是如此（H：高优先级，L：低优先级，CM：CliqueMap，PX：Pony Express）

突发尺寸的影响。我们 在Aquila中吸取到的一个教训是自我拥塞现象。Aquila中IP网络的注入效率100G每TiN，然而完整Aquila 拓扑中两个pod之间最小路径的总带宽限制为50 Gbps。这会导致单元采用非最小路由，即使由于突发，整体注入速率远低于链路速率。我们通过将点对点流量的注入速率保持在0.6 Gbps 但使用Pony Express 改变RPC的报文大小来展示这种效果。改变报文大小只会影响注入的突发性。图9显示，随着我们增加报文大小，尾部结构延迟增加超过40 µs。然而，在Aquila的半比例版本中重复相同的实验，我们将Pod间带宽与每个TiN IP注入率相匹配，我们发现报文大小对结构中的排队没有影响。提供更高的最小路径带宽会在突发流量条件下以更好的性能换取更小的最大拓扑规模。

图9:在一个全尺寸的Aquila(左)和半尺寸的Aquila(右)中，突发性对排队的影响。

通过保持注入速率不变并改变消息大小，我们可以看到突发性对队列延迟的影响。

> 应用影响

为了查看应用程序的影响，我们比较了使用1RMA和Pony Express的CliqueMap 查找（具有4 KB大小的对象）延迟，1RMA 和Pony Express作为 Aquila 网络上RMA传输。我们使用O（100） 后端和客户端，并改变每个客户端每秒的查询。图10显示了 Aquila 上的1RMA如何在低QPS下将中部和尾部延迟减少50%，在高 QPS 下减少300%以上。与之前的工作[51]一样，1RMA的负载水平越高，延迟越低，因为单个服务器可能会在低负载时处于低功耗状态。

图10:基于cell的RMA协议对端到端CliqueMap查找延迟的影响。

讨论

虽然我们对 Aquila 的设计方法使我们能够为数据中心网络开发统一的低延迟网络结构，但我们必须克服许多挑战。接下来，我们将重点介绍一些关键挑战。

单芯片部分和直接连接拓扑。虽然单芯片设计为 Aquila 网络提供了具有适度规模团队和成本效率的可持续发展模型，但该方法对架构和部署有几个关键影响。首先，单个部分意味着我们必须将 Aquila 部署为直接连接的网络拓扑，因为间接拓扑（例如 Clos 网络）对于 TiN 芯片是不可行的。虽然本身不是缺点，但直接连接拓扑不利于增量部署。其次，从多代路线图的角度来看，NIC 和交换机架构的演进是耦合在一起的。

为简单起见，我们将 Aquila Clique 设计为一个同质的部署单元，而不打算混合不同代的硬件。此外，整个 Clique 的网络占用空间（最多 24 个机架容纳所有 TiN 卡以及网络光纤）被设计为预先部署，并且主机可以按需增量填充。使用间接拓扑，可以预先部署少量网络机架（例如 4 个），并逐步部署服务器机架。对于直接拓扑，必须预先部署所有服务器机架（可能没有服务器）。此外，对于给定的光学技术，间接拓扑支持更大的部署灵活性：所有服务器机架只需要在网络机架的（例如）100m 半径范围内。使用我们的直接拓扑结构，必须注意布置机架占用空间，以使所有机架对之间的 GNet 光纤长度在（例如）100m 的预算范围内。

由于细的最小路径链接而导致的自拥塞。可以增加Dragonfly拓扑的规模，直到我们在每对pod之间只有一个全局链接。然而，来自TiN 的注入带宽和pod到pod带宽之间的不匹配会导致自拥塞，即使在低负载下，尤其是对于大型MTU数据包，一些信元可能会被最小地路由，而其他单元可能会穿越非最小路径。因此，由于单元和数据包的重新组装，产生的延迟会甚至低平均负载下的点对点流也会如此。

对于我们最初的 Aquila 原型，我们选择了576个TiN的Clique大小，其中pod到pod带宽为2x25Gbps，这是每个TiN的200Gbps最大注入带宽的1/4，这是Dragonfly配置中Clique规模和自拥塞之间的平衡。此外，我们调整了自适应路由以从最小路径切换到非最小路径，以减少由于自拥塞导致的方差。

单元交换和请求的开销。单元交换和请求是Aquila中实现可预测的低网络延迟的关键特性。由于每个160字节的GNet单元有一个8字节的GNet报头，因此切换GNet单元会带来大约5%的开销。尽管 RTS/CTS 单元通过GNet网络获得高优先级，并且对于具有大MTU的数据包，该开销进一步减轻，但每个IP数据包的RTS/CTS请求会导致通过网络进行额外往返的延迟开销。我们认为这两种开销换取低尾部延迟是可以接受的，即使在高注入负载下也是如此。考虑到更大的GNet单元大小以及在低负载下不产生请求开销的能力，我们正在研究进一步减轻这些开销的技术。

调试单元交换网络。由于Aquila Clique内部不是IP路由结构，因此标准调试工具（例如traceroute）仅显示通过整个Aquila结构的1跳。为了调试Aquila中的数据黑洞，我们在TiN中实现了单元追踪功能。标有位的单元由单元路径中的每个TiN采样，并通过UDP发送到中央收集器。然后，收集器可以重现数据包的组成单元的路径，并对任何配置错误或有故障的硬件进行三角测量。

TiN 和低级固件API上的RAM有限。为了节省成本和电路板空间，我们只为在TiN芯片上运行的固件配置了2MB的RAM，实现了自定义固件。固件开发大大增加了开发工作，因为许多基本内容必须定制或重新实现（例如，日志记录、内存分配和闪存存储）。

向SDN控制器公开寄存器级API以对TiN芯片进行编程的决定有利于将复杂性从资源受限的固件中转移出来，同时简化使用不间断转发（NSF）升级固件的能力。这也意味着无需推出新的固件版本即可实现新功能，因为硬件的所有功能都已公开。这种方法的一个挑战是在多代硬件之间维护这个接口，因为SDN控制器需要了解每个芯片的寄存器级细节。

对于未来的设计，我们正在研究向NIC添加更多计算，以便它可以基于Linux。相对于开发速度的预期收益，将RaspberryPi等效计算添加到每个NIC可能会最低限度地增加单位成本。此外，更多的计算将解除对具有更高抽象级别的API的使用，例如P4 Runtime [24]。

旧版应用程序性能。虽然Aquila为共同设计的案例（例如带有 1RMA的CliqueMap）提供了显着的应用程序性能改进 （第五章），但它对传统应用程序没有显着的积极影响。我们观察到传统应用程序的尾部延迟主要由主机软件堆栈控制，包括线程唤醒延迟。此外，使用 IP 软件堆栈，RTS队列长度由主机拥塞控制算法而不是GNet结构单元延迟控制。展望未来，我们正在转变传输和网络协议来利用面向未来的硬件改进，从而造成一种有趣的局势，即在大多数设备部署新设计的硬件之前，大量的软件投资可能不会产生净积极影响。

相关工作

拓扑和单元交换。 Aquila 使用直接连接拓扑，Dragonfly [30]。Cray Cascade 系统 [17] 使用Dragonfly 拓扑作为 HPC 结构的基础。此设计使用具有 4 个集成主机接口的高基数交换机，使用专有数据包格式和虚拟直通。以太网网关需要连接到这两种网络的处理节点。Aquila 与该系统（以及在Flattened Butterflies [31]和HyperX [3] 上的工作）不同，它使用拓扑作为单元结构，而不是具有虚拟直通的分组网络。JellyFish [52] 是一种随机图拓扑，具有其自身的部署挑战。Sirius [6] 是一种平面拓扑，其目标与Aquila相似，但它使用光路交换而不是单元或分组交换。早期的ATM网络提供Ethernet-on-A TM [26]。最近，Stardust [56] 采用了单元的想法，通过在结构中使用单通道通道来提供更高的有效交换机基数。

拥塞控制。请求是GNet控制GNet结构中拥塞的关键要素之一。少数最近的拥塞控制方案，例如 Homa [42]、NDP [25]、ExpressPass [11]、pHost [19]和Stardust [56]使用类似于GNet 的接收器驱动的请求方案来避免incast拥塞和实现低延迟。Aquila 的请求控制从GNet结构边缘的缓冲区传输IP数据包，而不直接控制IP NIC。这意味着它可以处理网关和主机接口 IP 流量，但它需要基于主机的拥塞控制 [33] 以在发生拥塞时使流量源回退。

控制平台。 Aquila 的控制平台采用分布式软件定义控制平台设计。大多数以前的 SDN 控制器，Onix [32]、ONOS [9]、Flowlog [43]、Ravel [54] 都假设 IP 流量的路由并依赖 OpenFlow 来编程交换机。Aquila 的控制平台从 Switch Frontend 模块引入了较低级别的通信协议，以控制灯光嵌入式开关控制器。[18， 43， 54] 中基于表格的设计允许扩展路由和排序以支持除 IP 流之外的 GNet 流。

结论

在本文中，我们介绍了 Aquila，这是我们首次涉足集成在数据中心网络生态系统中的紧密耦合网络 （Cliques），实现了 Clique 规模的资源分解和可预测的低延迟通信。我们的主要目标是倡导围绕 Cliques 的数据中心网络的新设计架构，并鼓励在紧密耦合网络方面进行新的研究和开发，以支持高性能计算、ML 训练和网络分解，同时与数据中心规模的TCP/IP/以太网流进行互操作。我们相信，我们对 Aquila 原型的正面和负面经验将为未来在该领域的探索奠定基础