当前位置：首页 > NSDI > 正文

【NSDI 2022】EQDS：用于所有数据中心流量的边缘排队的数据报服务

NSDI
2022-10-18
6841
更新：2023-01-04 21:41:54

# **摘要**

现代数据中心支持各种协议及旨在提高性能的网络交换机增强功能。不幸的是，由此产生的协议往往不能优雅地共存，因为它们不可避免地通过网络中的队列进行交互。在本文中，我们描述了EQDS，一种为数据中心提供的新数据报服务，它将几乎所有队列从核心网络转移到发送主机。这使得它能够支持多个（冲突的）高层协议，同时只根据任何接收端驱动的信用/credit方案向网络发送数据包。EQDS可以透明地加速传统的TCP和RDMA协议栈，并支持传输协议的演进，同时受益于未来的交换机增强功能而无需修改更高层的协议栈。我们通过仿真和多个实现表明，EQDS可以将传统TCP的FCT降低2倍，将NVMeOF-RDMA的吞吐量提高30%，并在同一网络上与RDMA一起安全运行TCP。

# **1、引言**

数据中心网络面临一系列独特的问题，这些问题使其难以有效利用底层高性能冗余多路径网络拓扑的潜力。值得注意的问题包括：流级负载均衡导致的incast流量模式、流冲突和瞬时拥塞、低延迟请求/响应流量与批量传输之间的干扰、增加从主机CPU卸载工作以避免主机协议栈瓶颈的要求，以及需要在与传统协议相同的网络中支持特殊用途的高性能协议，如RDMA。

这些都是部分解决的问题。随着数据中心部署智能NIC，以及NIC供应商提供的对特定传输协议的ASIC支持不断增加，NIC卸载成为一种强劲的趋势。然而，将传输状态转移到NIC中会使不同的协议更难共存，并有可能在硬件中体现出来。

与此同时，研究界已经提出了一系列丰富的解决方案，如pHost、Homa、NDP、1RMA和Aeolus，这些解决方案解决了incast问题，并在不同程度上解决了负载均衡和低延迟请求/响应流量问题。这些解决方案共享的是一个接收端驱动的控制回路，它可以严格管理入站流量，消除网络中的大型队列堆积。每一种协议本身都将是对现状的重大改进，但数据中心不能简单地迁移到单一的新传输协议。即使有人同意采用哪种传输协议，也有太多的传统应用程序和操作系统需要重新编写。那么，我们怎样才能从研究界汲取最好的想法，并将其部署到生产中，同时支持从普通TCP到RDMA的大量传统协议呢？

一个朴素的解决方案是简单地选择一个低延迟接收端驱动的传输协议，并通过该协议隧道传输所有数据中心流量。这种控制回路的最大优点是，它对物理网络执行准入控制，允许使用非常小的交换机缓冲区，同时仍提供较低的端到端丢包。有没有可能用它来提供一个新的数据报服务，让TCP、DCTCP或RDMA等更高层协议运行？

困难在于，在共享底层网络时，TCP、DCTCP、RDMA和其他协议都有自己的期望。特别是，它们使用通过交换机中的队列调节的流之间的交互来驱动自己的控制循环。我们不能仅仅消除交换机队列，期望一切都能正常工作——相反，我们需要在主机或NIC中将队列从交换机移到网络边缘。然后，低延迟控制环路可以将数据包从这些边缘队列调节下/clock发送到网络中。

我们设计并实现了一个叫做边缘排队数据报服务（EQDS，Edge-Queued Datagram Service）的层。EQDS不是常规的传输协议，而是通过动态隧道向更高层提供数据报服务。其接收端驱动的控制回路松散地基于NDP和1RMA，但可以扩展到利用其他可用的网络内控制机制。

将流之间的交互从交换机队列移到EQDS边缘队列中有许多优点。接收方直接控制来自不同发送方的排队数据包何时进入网络，确保隔离，即使更高层协议运行不同的控制循环。例如，在发送到同一主机时，TCP和RDMA通常不会优雅地共存，但EQDS可以进行调解，消除丢包并允许公平共享。

不同的EQDS排队规则也可用于不同的协议，每个协议都向高层控制回路提供适当的反馈；这不仅提高了高层协议的性能，还允许从同一主机发送的不同协议相互保护。添加新的排队规则以支持创新的未来传输机制也得到了简化，因为它们只需要部署在相关的发送主机中，而不需要部署在交换机中。

最后，EQDS使用包spraying来均衡网络核心中的负载，避免流冲突，并提高吞吐量。传统协议，如TCP和RDMA通常不能很好地处理重新排序，因此EQDS在接收端中实现了一个重新排序缓冲区。在传统网络中，这种重排序缓冲区可能会在所有路径上提供最高的延迟，但在良好的负载均衡和较短的交换机队列中，我们发现EQDS重排序缓冲区延迟最小。

在本文中，我们详细介绍了EQDS及其按需零RTT隧道协议的设计和实现，并对其在Linux主机上本机运行和卸载到两个品牌的智能NIC上进行了评估。我们表明，在非常短的时间尺度上运行的EQDS控制回路不会对更高层的控制回路产生不利影响，例如TCP的Cubic或使用DCQCN的RDMA。相反，它允许不同的高层控制循环优雅地共存，保护对延迟敏感的应用程序不受批量传输造成的排队延迟的影响，同时通过消除流冲突提高吞吐量。

# **2、动力**

从互联网诞生之初起，IP就一直是互联网的瘦腰，提供基本的端到端服务。实际上，瘦腰的不仅仅是IP：一个正常运行的互联网还承担着某种形式的TCP兼容的拥塞控制，并有足够的网络队列来完成它的工作，尽管这在协议栈中缺乏一个明确的层。

这种缺乏抽象性的情况尤其损害了数据中心网络。在这里，大量工作推动了跨边界的优化，包括主机协议栈、交换机或两者兼之。由于所有这些增强工作，出现了多个并行协议栈，每个协议栈假设一个稍微不同的“基本”数据报服务，必须在网络中相互隔离，以避免它们发生冲突（见图1）。此外，对一个协议栈的优化往往会损害同一网络中其他协议栈的性能。

许多工作改进了TCP拥塞控制，减少了普通TCP对交换机大缓冲区的需求。这些TCP仍然建立在基本的数据报服务之上，并探测网络容量以感知拥塞。这样一来，它们通过队列彼此交互，增加了延迟。

甚至数据报服务本身也进行了调整，许多改进旨在改善某些流量类别的服务，如图1所示。例如，RoCEv2可以使用PFC提供RDMA假设的无损服务；这带来了一系列独特的功能交互问题。

像TCP和RDMA这样的协议也在很大程度上假定了底层数据报服务的有序交付。在数据中心中，按序/in-order交付由流级ECMP提供，尽管这会浪费CLOS拓扑中的容量。为了更好地使用多路径网络，已经提出了这些协议的变体，但很少部署。随着网络速度的提高，性能问题的另一个来源是终端主机协议栈实现本身。即使TCP也会诉诸分段和校验和卸载，但应用程序编写者通常会使用DPDK等内核绕过机制，甚至使用RDMA将所有工作卸载到NIC，从而在网络上施加独特的动态负载。

**更高层协议和网络内增强功能之间的依赖关系网使得部署新协议变得越来越困难**。**问题的根本原因是基本数据报服务迫使不同的高层协议通过网络中的队列进行交互**。我们认为，在网络中排队(in-network queuing)，除了平滑扇入/fan-in所需的最小值之外，它与构建高性能低时延通用数据中心网络背道而驰。

我们提出了一种新的边缘排队数据报服务(EQDS, Edge-Queued Datagram Service)，作为数据中心网络协议栈的新瘦腰。

为了传输上述协议栈，EQDS通过主机中的虚拟接口队列(virtual interface queues)提供了一种类似于传统数据报的服务，该队列缓冲流量并提供适当的拥塞反馈信号。EQDS然后在可能的情况下发送此流量，利用各种网络内机制最大限度地提高利用率并最小化网络内排队延迟。EQDS在主机上共享网络，允许有冲突传输协议在同一网络上并排运行（run side-by-side）。

# **3、概念**

我们通过例子介绍EQDS的概念。考虑图2a：两个TCP发送端通过传统网络发送到接收端，其中瓶颈是在数据中心中常见的最后一跳。TCP需要构建一个队列来感知拥塞并回退(back off)，迫使共享该队列的任何其他流以类似的行为合理地共享链路。RDMA或其他不会引起问题的传输（见图1），需要与TCP隔离。

相比之下，EQDS概念如图2b所示。现代数据中心网络的underlay延迟非常低，NDP、Homa和Aeolus等协议可以使用信用机制，通过这种机制，接收方可以根据需要为来自发送方的数据包进行调度(clock)，确保网络中永远不会出现队列堆积。像TCP这样的协议仍然需要一个队列来驱动它们的控制循环，但EQDS将这个队列移动到发送主机，在那里它受接收方的控制。如果许多TCP发送方导致incast，他们观察到的默认行为几乎与最后一跳交换机使用大量缓冲运行公平队列时发生的行为相同。

由于排队队列已从网络本身中移除，EQDS可以在发送侧EQDS虚拟接口（*EQIF*, EQDS Virtual Interface）中运行不同的排队规则，以适配所承载的流量。图2c显示了一个传统TCP发送方与RDMA发送方共存，瓶颈链路被公平共享，或者如果网络或主机管理策略认为合适，则按比例共享。

最后，图2d显示了EQDS在底层underlying网络中使用逐包ECMP（又名包spraying），以最小化延迟并增加网络容量。目前很少有传输协议能够很好地处理这通常会导致的重新排序问题，但由于EQDS使网络队列非常小，因此重新排序很容易由接收EQIF中的短重新排序队列来管理，因此它对更高级别的协议是隐藏的/屏蔽的。

总之，EQDS的关键概念是：（1）将排队移出网络，只留下所需的最低限度；（2）在发送主机中的让流量排队，并当接收者请求时释放它；（3）根据需要为不同类别的应用程序运行适当的队列规则；（4）使用逐包ECMP来均衡负载，以最小化延迟，但默认情况下，会将其对更高层协议屏蔽/隐藏。EQIF虚拟接口随后成为网络的控制点，实施共享策略。

# **4、设计**

要实现EQDS，我们需要四个主要组件：

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">发送主机上的一个或多个EQIF，实施排队规则以支持更高级别的协议；
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">接收主机上的一个EQIF，它实现了一个短的重新排序队列，以便尽最大努力对重排序无法容忍的协议提供按序交付服务；
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">通过网络可靠地封装从发送方EQIF到接收方EQIF的数据包的机制；
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">一个边到边（edge-to-edge）控制回路，用于将数据包从发送方法EQIF调度（clock）到接收EQIF（clock）。
</span>

有了这些，EQDS就可以承载不同的高层协议，而EQDS隐藏了网络机制中的底层。在不同的数据中心环境中，甚至在一个数据中心内，边到边控制环路可能会有所不同，这取决于交换机的功能。实际上，EQDS已经成为数据中心协议栈中新的瘦腰。

在虚拟化协议栈中，EQDS与VXLAN在同一层运行，封装了通往支持EQDS的目的地的更高层通信。为了提供数据报服务，EQDS需要提供从EQIF到EQIF的按需隧道，无需事先设置，无需花费一个RTT执行握手以建立控制状态，并且期望在第一个RTT中发送的数据包将由逐包ECMP重新排序。这需要一个新的隧道协议（第5节）。EQDS隧道是单向的；如果用户流量是双向的，则设置两个，每个方向一个。

每个目的地隧道的EQIF状态在发送方接收数据包时建立，在接收方使用零RTT协议（zero-RTT protocol）建立。任何一方都可以在空闲时单方面放弃该状态，以减少内存使用，并根据需要重新建立该状态。

## **4.1 EQDS控制回路**

边到边控制回路对EQDS性能和最小化网络排队至关重要。EQDS允许根据底层underlay网络能力使用不同的控制回路机制。

对于完全配置的网络，我们首选的网络内机制（in-network mechanism）是数据包裁剪，它允许EQDS使用NDP派生的控制回路。这允许在接收方基于信用的控制接管后续RTT之前，在第一个RTT中发送突发数据包。发送EQIF保留数据包，直到它们被接收EQIF确认，或者在收到NACK时重新传输它们。通过这种方式，EQDS提供了高度可靠的服务，但它不保证任何数据包丢失。全面的可靠性保证将防止EQDS有效地管理其自身的状态，避免资源匮乏攻击的风险，但毫无意义因为全面的可靠性需要端到端的确认，而EQDS可能在NIC中实现，因此无法保护数据直到被接收。

在数据包裁剪不可用的情况下，EQDS使用1RMA衍生机制，其中发送EQIF从接收端请求信用，或者它可以使用Homa/Aeolu衍生机制，其中使用低优先级服务发送数据的第一个RTT。在配置不足的网络中，也可能出现核心网络拥塞，但如果使用逐包ECMP，这种情况应该很少见。在这种情况下，可以使用带内网络遥测（INT）来实现HPCC类型的控制回路。我们当前的实现支持NDP类型的主动传输和请求发送。我们预计未来的网络将在这一领域进一步创新。

**EQIF**。EQDS允许多个协议栈在同一网络上运行，如图3所示。主机A上基于DPDK的协议栈正在发送到D上的对等方，而B上的虚拟机也使用TCP发送到D上的虚拟机。如果没有EQDS，DPDK协议栈将使到D的链路饱和，导致TCP吞吐不足（starving）。在D的ToR交换机中使用公平队列可以防止这种情况，但EQDS在不需要配置交换机和更精细控制的情况下实现了相同的效果。

在D处，单个接收EQIF（receiving EQIF）接收来自A和B的流。它维护传入EQDS隧道的状态（重新排序队列、序列号等），允许它有效地管理所有传入流量。默认情况下，D的接收EQIF将向A和B发送相等的信用/credit，以确保公平的份额和无过载。还可以实现比例共享或严格优先级：入站共享策略可以根据需要进行配置——由网络管理员配置，如果VM和本机协议栈由同一用户运行，则也可以由他们配置。

在A处使用三种不同的协议栈：有到C的RDMA和TCP流、到B处VM的TCP流和到D的DPDK本机流(native flow)。这导致在A处为三种不同的边缘队列规则维护三个发送EQIF虚拟接口(sending EQIF virtual interfaces)。这两个TCP流共享相同的发送EQIF，该EQIF运行TCP兼容的队列规则。所有三个EQIF在同一时间使用DRR（deficit round robin）进行合作，因此如果总流量使A的出站链路饱和，它们将公平地（或不公平地，如果这是配置的策略）共享它。

总而言之：EQIF是一个虚拟接口，它实现了一个特定的队列规则或高层协议的反馈机制。一个发送EQIF包含多个队列，每个队列将EQDS隧道提供给单个主机。来自多个VM的多个传输流可以共享一个EQIF，只要使用的协议可以在同一队列中共存。

# **5、隧道协议**

为了将数据从发送EQIF传输到接收EQIF，我们需要一个新的隧道协议。主要要求是：

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">接收EQIF应为其发送EQIF集合中的数据包设置时钟，以免导致网络队列中的数据包生成。至少，这意味着它将以不超过接收方接入链路速度的速率发送信用。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">接收EQIF可以选择如何向发送者分配信用，默认情况下是实现公平共享。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">隧道应预期逐数据包的ECMP服务，并能可靠地重新排序。在可能的情况下，发送EQIF将确定每个数据包所采用的路径。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">隧道应提供从接收EQIF到更高层协议的最大努力、可靠且有序的交付。丢包和重新排序应该足够少，以尽量减少对更高层协议性能的影响。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">隧道应支持不可靠、无序的向更高层协议的传输，这些协议更倾向于最小化延迟。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">隧道应按需提供而无需预数据握手（pre-data handshake），并可随时丢弃。如果端点最终不同步，它应该自同步。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">隧道应该能够利用一系列底层underlay网络增强功能，而无需了解更高层协议。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">发送和接收EQIF都应能够实施共享策略，由网络运营商和用户配置（在用户策略与运营商策略不冲突的范围内）。
</span>

这些要求需要一个不同寻常的隧道协议；它具有传输协议的许多方面，但它是软状态，基于数据包到达建立、丢弃和重新建立，但它提供精细的闭环控制。

在基本设计层面上，EQDS是一种隧道协议，具有NDP派生的控制循环，在UDP之上运行。它可以承载多种类型的流量，包括IP和VXLAN。其控制字段（如图4所示）旨在补充VXLAN，两者之间的功能没有重叠；实际上，如果需要，EQDS可以作为VXLAN封装的有状态扩展来实现。

**数据时钟/Data Clocking**。与NDP一样，接收EQIF向发送EQIF发送包含信用的PULL分组/数据包；然后，发送EQIF从相应的隧道队列发送与该信用匹配的数据包作为响应。接收EQIF对信用的发送进行调整，以便在第一次RTT之后，总到达率与传入链路速度匹配。

如Sigcomm17论文“Re-architecting Datacenter Networks and Stacks for Low Latency and High Performance”所述，对NDP进行总结：当发送方启动时，在不等待信用的情况下发送一个RTT数据；之后，发送方等待从接收方发送的PULL分组/数据包。这意味着第一个RTT中出现了incast，这会导致丢包。NDP使用数据包裁剪来处理这个问题——从会使队列溢出的数据包中移除有效负载，只将报头转发给接收方。这使得网络对元数据（尽管不是数据）是没有丢包的，并通知接收者需求。然后，接收端可以使用PULL数据包请求重新传输裁剪后的数据和传输新数据。在大的incast规模中，可能需要一些时间才能向发送方发送请求，因此接收方ACK或NACK每个数据包，以便发送方知道要释放哪些数据包缓冲区，以及要向其重传队列添加哪些数据包缓存。

在底层网络支持数据包裁剪的情况下，EQDS隧道在第一个RTT中使用如上所述的NDP机制，因为它最小化了延迟。**EQDS使用请求发送机制（request-to-send mechanism）来补充这一点，发送方直接向接收方请求信用**。这是在裁剪不可用时使用的，用于间歇性突发流。

从概念上讲，每个EQDS隧道保持在发送方和接收方之间传递的恒定带宽延迟积（BDP）。这种信用要么从发送方（类似NDP）开始，要么从接收方（RTS）开始。信用通过数据包从发送方流向接收方，通过拉取数据包从接收方流向发送方。EQDS与NDP的不同之处在于，在控制数据包丢失的情况下，EQDS如何保持该窗口不变，因为NDP在极端案例（corner case）中未能做到这一点。

EQDS信用/credit以字节表示。要发送大小为b字节的数据包，发送EQIF必须拥有b字节的信用。PULL数据包包含一个PULL编号，该编号从零开始，每次发送到源时递增。当发送EQIF看到的最大pull数增加n时，这将授予n个MTU信用。

当发送EQIF发送数据时，报头中的*pull target*字段向接收方指示当前pull number之外需要多少信用。这个上限是一个带宽延迟乘积（BDP）——通常是10到30个数据包。

接收EQIF维护一个活跃发送方列表（ASL，active sender list）。活跃发送方是具有待发送数据的传入EQDS隧道。每次MTU时间，接收EQIF将向ASL头（head of the ASL）的发送方发送一个MTU信用。如果这导致pull number达到该发送者的pull target，则该信用将满足该发送者的所有已知需求。然后，发送方将从ASL中删除，并放入非活跃发送方集中。如果pull号码未达到pull目标，则发送的信用将不足，因此发送方将重新插入ASL的尾部。通过这种方式，所有活跃发送方都可以获得公平的容量份额，并且不会向没有排队数据的发送EQIF发送信用/credit。

ASL在概念上与NDP pull队列类似，但与NDP不同，它确保始终保持一个BDP信用窗口不变。从概念上讲，只要仍有足够的需求，存储在发送方的信用、飞行中的数据包、飞行中的pull数据包携带的信用和隐含存储在接收方ASL条目中的信用的总和是恒定的。

将ASL实现为FIFO可确保默认情况下公平分配传入流量。为了实现其他共享策略，可以使用PIFO队列代替FIFO，从而实现多种策略。

为了避免源空闲，然后立即再次突发，接收EQIF使用控制数据包中的忙时间字段（busy time field）告诉发送方其接入链路饱和的最短时间（pull target通知接收方每个发送方的总队列大小）。即使在裁剪网络中，如果一个突发的发送者在这个繁忙的时间内重新启动，它总是在发送之前使用RTS，因为突发会导致不必要的裁剪；繁忙时间过后，发送方可以突发。

**隧道安装和拆除**。当到新目的地的数据包到达时，发送EQIF创建隧道状态。它选择一个具有特定约束的序列号（详见附录A），开始封装数据包而不等待握手完成，在所有数据包中设置SYN标志，直到收到匹配的SYN+ACK数据包作为响应。这将通知接收端新的隧道，并且对逐包ECMP引起的重新排序具有鲁棒性。

任何一方都可以单方面放弃隧道状态。作为一种优化，每一个都会在这样做时通知另一个，但这样的拆除不需要可靠地发出信号，并且两端都不保持时间等待状态。稍后，如果新数据包到达发送EQIF，将建立一个新的隧道。如果接收端从已排队数据包的发送EQIF中拆除隧道，则立即建立新的隧道。

这种简单性允许附录A中的简单EQDS状态机，如果两个端点最终处于不同的状态，它允许EQDS自同步，并将状态要求降至最低——这对于EQDS在硬件中的实现非常重要。我们可以使用这种轻量级协议，因为EQDS服务模型只保证尽最大努力避免丢包、重复/duplication或重新排序。像TCP这样的传统传输协议需要为应用程序提供更可靠的保证。

**重新排序队列**。逐包ECMP极大地改善了负载均衡，减少了网络排队和延迟，但可能会导致重新排序。在等待重新传输时，裁剪也会导致重新排序。为了避免高层协议的性能问题，EQDS在接收EQIF中维护每个隧道的重新排序队列。在网络队列最小的情况下，路径之间的延迟差很小，因此该队列不会增长太多，并且以BDP为界。

**超额订阅的网络/Oversubscribed network**。当网络核心被过度订阅并成为瓶颈时，积极的接收端驱动传输可能会导致高裁剪率，或者在使用RTS时导致高延迟或丢包。在这种情况下，EQDS需要增强，以考虑其他拥塞信号，如ECN、延迟，甚至带内网络遥测，以及接收端调速。由于接收方驱动的传输在incast情况下需要处理高动态范围，因此这种拥塞管理只需要相对有限的动态范围，可以通过接收方降低其拉入速率(pull rate)或发送方降低其拉入目标（pull target）来实现。拓展这样的机制是未来的工作。

**增量部署**。EQDS只将流量封装到配置的内部地址范围，因此外部和传统流量也将出现在数据中心中。它们将如何共存？EQDS的数据包负载均衡（packet spraying）将流的影响扩散到许多核心链路上，大大减少了它对任何传统单路径流的影响。在我们的测试台上，当启用数据包修建功能时，我们使用两个优先级类来分离EQDS和非EQDS流量，并通过小缓冲区确保EQDS的低延迟，即使是存在传统的“大象”流。

随着负载水平的上升，严格的优先级划分可能是不可取的，但EQDS和非EQDS流量类别之间的加权公平排队可以保持核心网中EQDS流的低延迟，只要spraying的负载均衡EQDS聚合不超过其分配的份额。在EQDS流量扩散较少的ToR上行链路上，传统的“大象”流可能会对某些EQDS路径产生比其他路径更大的影响。EQDS提供了精确的逐路径延迟和丢包统计信息，可用于在路径之间执行负载自适应路由，避免暂时性瓶颈。实施这些是未来的工作。

# **6、发送EQIF细化说明**

不同类型的流量对底层数据中心网络有不同的期望。虽然单个EQDS隧道协议对从发送EQIF到接收EQIF的所有流量进行时钟设置，但不同的专用发送EQIF（specialized sending EQIF）支持具有不同网络期望的更高级别协议。

图5显示了发送EQIF作为虚拟接口的行为。每当更高层协议通过该接口发送数据包时，EQDS就会对其进行封装和排队，等待获得足够的信用。发送EQIF为每个隧道维护一个队列，如果还不存在队列，则根据需要分配。当一个数据包被发送时，它会从发送队列移动到正在运行的队列（in-flight queue）中，但在确认之前不会被释放。如果它被NACKED或重传计时器超时，它将被移动到隧道的重传队列。当信用可用时，首先发送重新传输的数据包，然后发送新的数据包。

每个发送EQIF都提供特定类型的服务。我们目前支持三个服务类：TCP兼容、RDMA和本机/native。它们在队列规则以及如何向端到端流量提供反馈方面有所不同。

当多个发送EQIF在同一台主机上使用时，如图5所示，信用避免了接收机下行链路过载，但来自多个接收机的信用可以超过上行链路速度。当这种情况发生时，DRR用于在各种EQIF队列之间公平地共享物理接口。如果需要，还可以配置队列优先级。

发送同一流量类别的多个主机协议栈或虚拟机可以共享同一EQIF。例如，QUIC和TCP可能使用相同的TCP兼容的EQIF，而RDMA将使用不同的EQIF。这些传统协议栈都不需要知道它们正在EQDS上运行。

**TCP兼容的EQIF类**。我们的TCP EQIF为非ECN流量实现了一个简单的尾丢弃队列，为支持ECN的流量实现了一个RED队列。队列的目标是在TCP发送速度超过接收方希望的速度时吸收流量。当队列填满时，数据包将被丢弃。队列需要足够大，以使TCP的拥塞控制能够运行，并使接收端的链路饱和——通常这将是30个以上的数据包。

对于TCP来说，最糟糕的情况是多个流向同一个接收端传输（incast）。在默认的10个数据包初始窗口中，数据包将在EQIF队列中排队，直到接收方发送信用，这可能需要一些时间。TCP的最小RTO时间为250毫秒，在这方面很有帮助——即使是大的incast传输通常也可以在250毫秒内完成。如果数据包的排队时间超过这个时间，可能会发生RTO，但我们的经验是，即使这样，对性能的影响也很小；TCP通过埃菲尔算法（Eiffel algorithm）检测虚假超时，纠正其拥塞窗口，并更新RTO以防止进一步超时。

我们发现，在EQDS上运行的普通TCP几乎总是优于本机运行的TCP，即使不与不兼容的流竞争。这些成功的大部分来自EQDS对逐包ECMP的使用。

**RDMA EQIF类**。RDMA需要一个单独的EQIF，以避免与其他流量发生冲突，避免严重影响RDMA性能的丢包，并向RDMA实现提供适当的流量控制反馈。

RDMA通常在NIC中实现。理想情况下，RDMA EQIF实现将与硬件传输实现耦合，以直接控制RDMA流量。我们目前在智能NIC中部署了原型RDMA EQIF，如图6所示。我们使用端口代理插入SmartNIC向主机及其虚拟机公开其支持RDMA的设备。

我们的EQIF不会修改NIC的RDMA实现，但它确实需要在到达目的地的TX队列增长时通知发送方放慢速度。根据SmartNIC模型，我们使用不同的技术来控制RDMA引擎的发送速率。对于Stingray，我们发出PFC暂停包来减慢发送方的速度；这工作得很好，但它的副作用是减缓所有来自RDMA引擎的流量，而不仅仅是到达积压目的地的流量。BlueField 2支持DCQCN，所以我们的实现使用它来控制RDMA。我们可以使用ECN向DCQCN流发送信号以减慢速度，但我们更喜欢直接从发送EQIF向RDMA发送方发送拥塞通知包（CNP）。这减少了DCQCN控制回路的长度，并允许将DCQCN参数一次性调整到该恒定延迟。不幸的是，RDMA RC数据包的报头中缺少源QP号，这是发送回响应所需的，因此我们为RDMA CM开发了一个连接跟踪模块以支持CNP生成。

**本机EQIF(Native EQIF)**是面向性能的EQDS感知传输的首选选项。它使用一个共享内存区域来存储带有无锁描述符环(lockless descriptor rings)的数据包，无锁描述符环用于通过零拷贝API在EQIF之间移动数据包。该EQIF向主机传输提供额外的低级信息，包括到目的地的TX缓冲区的大小、目的地的pull队列的大小、每个数据包和每个路径的网络RTT以及传递通知(delivery notifications)。

本机EQIF提供的延迟信息与1RMA提供的延迟信息类似，因此，对于核心拥塞很常见的情况，可以在顶部实施基于延迟的拥塞控制器，如Swift或TIMELY。

我们已经实现了*eqdsperf*，这是一个在本机EQIF上运行的性能测试工具，以及一个经过优化以在EQDS上运行的轻量级UDP协议栈。使用UDP套接字API的应用程序可以简单地链接到我们的协议栈，可以在编译时静态链接，也可以使用LD_PRELOAD动态链接。

# **7、实现**

我们实现了两个版本的EQDS，一个使用DPDK，另一个作为Linux内核模块。目标是增加最小的开销，但不可避免地要进行权衡。

我们的DPDK实现是在考虑性能的情况下构建的，无论负载如何，它都使用两个CPU核。这些可以是主机CPU核，但最好在智能NIC上使用ARM核。主线程轮流从面向主机和面向网络的NIC读取数据包块（packet batches）。一旦读取，数据包将被处理直到完成。在发送方，这包括触发排队分组（重新）传输的NACK和pull，在接收方，裁剪的分组引发NACK，而填充重新排序队列头部的空隙的分组触发等待分组的释放。主线程还检查计时器是否过期，这在很大程度上消除了同步的需要。第二个线程用于调整PULL的速度并发送延迟的ACK，以牺牲第二个核为代价提供准确的PULL调整（pull pacing）。当NIC支持细粒度调整时（例如Intel Columbiaville），EQDS可以将PULL调整（pull-pacing）卸载到NIC，从而减少CPU使用。

我们的内核实现旨在降低成本并易于部署。与Linux上的常见情况一样，传出的数据包在发送过程的上下文中进行处理。它们在流程启动后被钩子钩住。如果有足够的信用，处理将继续，直到它们被交给NIC的驱动程序。入站时，EQDS就像一个UDP服务；所有传入的数据包（包括数据包和控制包）都在软IRQ中处理，并反馈到内核UDP套接字。可以直接转发的数据包在解除封装后重新注入IP协议栈。如果必须发回控制或数据包，则使用第3层套接字。

**高精度计时器**用于PULL调整（pull pacing），其处理程序在软IRQ中执行。使用内核计时器的缺点是，它们的计时取决于Linux调度器。这会增加PULL调整的抖动。为了减轻这种抖动，发送方必须使用比通常更高的窗口值。

卸载是Linux实现高TCP性能的关键，因此我们的实现同时利用了TSO和GRO。使用TSO，TCP将发送大段，EQDS将封装它们，然后EQDS不知道的NIC将拆分封装的数据包，在内部TCP/IP报头之前逐字复制额外的报头。问题是，所有拆分的数据包都将具有相同的EQDS序列号。幸运的是，由于TSO执行方式的特殊性，有一个解决方法。NIC增加第一个数据段之后每个数据段的IP ID。我们发送IP ID为零的所有EQDS数据包，并在EQDS序列空间中留下间隙。然后，接收端将接收到的IP ID添加到接收到的序列号中，以获得完整的序列号。未来支持EQDS的NIC将不再需要这种解决方案。不可避免地，使用TSO会导致发送大量未调度的数据包（unpaced packets），这与计时器抖动一样，需要稍微增加EQDS使用的窗口。

# **8、评价**

数据中心网络已被证明存在许多问题，包括流量冲突导致的吞吐量降低、incast导致的高丢包或延迟、RPC类型流量的延迟增大，以及网络共享对兼容拥塞控制机制的依赖。EQDS的主要目标是为实际网络中的所有这些问题部署已知的解决方案，并使未经修改的主机协议栈可以使用由此产生的性能。

我们评估的第一部分检查EQDS是否有助于缓解这些已知的麻烦，并可以提高常规数据中心应用程序的性能。为了确保结果不特定于一个主机协议栈或部署模型，也不依赖于网络支持，我们对未经修改的TCP/IP（Linux）和RDMA NIC协议栈（BlueField 2，CX4）进行了实验，在主机和两个智能NIC上运行EQDS，并使用传统网络和支持微调的网络。

我们发现EQDS有助于将未经修改的TCP/IP和RDMA协议栈的吞吐量提高30-40%，减轻置换流量矩阵（第8.1节）中冲突的影响，以及NVMe对Fabric流量的影响。通过裁剪（我们的测试床和仿真）和RTS（在亚马逊EC2上），它在网络队列中实现了近乎完美的incast行为，将繁忙网络上基于微服务的社交网络应用程序基准的延迟减少了一半，吞吐量增加了一倍，并将memcached的速度提高了10-30倍（第8.2节）。最后，我们证明EQDS可以帮助冲突的上层拥塞控制器很好地共享底层网络，而无需任何网络内支持（第8.3节）。

在第二部分中，我们试图了解EQDS是否引入了自身的问题。最大的担忧是主机开销，比如EQDS软件的内存和CPU成本、处理高速链路的能力以及对特定硬件的性能依赖。

在我们的评估中，我们使用了两个小型测试台：T1是一个用于TCP/IP测试的测试台（10台服务器），T2用于RDMA和TCP/IP混合测试（6台服务器）。两个试验台均采用Leaf-Spine拓扑结构，并支持裁剪，但也可以配置尾丢弃/ECN；附录B中提供了详细的测试台描述。为了测试大规模行为和传统网络上的行为，我们在Amazon EC2中使用了大规模部署以及仿真。

## **8.1 提高吞吐量**

TCP和RDMA需要按序的（in-order）数据包传递才能正常工作，因此数据中心会对数据包的5元组进行哈希，以从多条等长路径中选择一条到达目的地。然而，当流的数量很小且流的带宽很高时，这种放置可能在同一链路上随机放置多个流，从而导致拥塞。之前的工作表明，在使用置换流量矩阵的最坏情况下，流碰撞会使Clos拓扑（Folded CLOS）的性能降低高达60%，其中每个主机向另一个主机发送数据，并从另一个主机接收数据。EQDS的逐包多路径应该避免这种性能损失，代价是在接收EQIF中执行重新排序。我们在T2试验台上进行了RDMA置换实验，在T1和T2试验台上进行了TCP置换实验，并进行了大规模仿真。

图7显示EQDS成功地在所有可用路径上传播单个TCP流和RDMA流量，而不会导致重新排序问题。在置换流量矩阵中，通过EQDS运行的TCP和RDMA流平均达到22Gbps（最大24Gbps），而在没有EQDS的情况下，平均达到12-14Gbps的吞吐。

图8中的仿真结果探索了更大规模的行为（k=16，1024台服务器，10Gbps NIC的FatTree）。流冲突严重损害了TCP，只产生了40%的网络容量。多路径TCP是TCP的一种变体，它将流量分散到多个子流（在我们的实验中为8）上，在平均利用率接近90%的情况下表现更好。NDP的数据包spraying使其能够实现接近最佳的吞吐量。最后，EQDS上的TCP受益于数据包spraying，但避免了EQDS处理的重新排序成本，实现了与NDP类似的性能。

置换流量矩阵强调了最坏情况下的行为，即无限流量和尽可能少的流量。碰撞对其他流量矩阵、较短流量和实际应用是否真的很重要？接下来我们将对此进行研究。

**1MB流量，随机流量矩阵**。在我们的测试台上，我们运行一个工作负载，其中每个服务器以闭环方式从另一个随机选择的服务器下载1MB对象，仿真TCP上的存储工作负载。我们测量流完成时间，并将其绘制在图9中。EQDS将中值和第95百分位完成时间分别降低了2.4倍和2倍。

我们还对EQDS进行了相同的实验，使用请求发送（request-to-send），并且没有在交换机中的裁剪支持。正如预期的那样，由于传输开始时需要额外的RTT，此设置的流完成时间（FCT）略大于基于NDP的实现。尽管如此，与基线相比，EQDS/RTS完成TCP的时间缩短了一半，无论是在中值还是在95%。在99%的情况下，所有变体都有类似的FCT，除此之外，EQDS可能需要更长的时间，因为短流的代码中缺少优化。

**NVMeOF**。我们使用存储性能开发工具包（SPDK）NVMeOF-RDMA目标运行分类存储服务，并使用空块设备（即无存储访问）来强调网络子系统。NVMeOF-RDMA协议是目标驱动的，在通过集合协调访问之后，服务器读取或写入客户机中的内存缓冲区。这涉及对控制的延迟敏感操作和对数据的吞吐量要求很高的操作。

我们在不同的TOR上运行NVMeOF目标机和客户机。每个客户机使用SPDK perf实用程序循环（RR）访问目标，以生成工作负载。图13显示了64 KB块的随机写入和读取的吞吐量，同时改变了NVMeOF目标的队列深度。EQDS支持多路径，提高了峰值读写吞吐量，并降低了标准偏差。请注意，由于我们的BlueField设置增加了延迟（第8.5节），EQDS需要更深的NVMeOF队列以实现更高的吞吐量。

## **8.2 改善应用程序延迟**

在已部署的网络中，通常通过在网络中提供大型共享缓冲区，在优雅地支持多对一incast流量和请求响应应用程序（如微服务或内存键值存储（如memcached））的延迟之间存在严格的权衡。EQDS通过将缓冲区移动到发送主机来解决这一问题，有望同时实现低延迟和良好的incast行为。

**多对一流量**。为了了解基线行为，我们在仿真和Amazon EC2虚拟机上运行了大量多对一工作负载（850个*iperf*发送端到同一个接收端）。

我们使用htsim仿真来了解目标链路以10Gbps运行时TCP NewReno的行为，并改变瓶颈交换机缓冲区的大小。图14是流量平均吞吐量的CDF。当缓冲区很小（每个流大约1个数据包）时，吞吐量差异很大，很多流都会被耗尽。当我们将每个流的缓冲区增加到大约100个数据包时，TCP可以更均匀地共享容量，并且没有饥饿产生。我们还展示了交换机实现公平排队时的结果，这进一步减少了方差并减少了缓冲需求。

我们在EQDS上运行相同的工作负载，EQIF逐目的缓冲区设置为100个数据包，瓶颈处设置15个数据包缓冲区。EQDS完全共享瓶颈容量，仿真瓶颈链路上的公平队列。

虽然我们的仿真显示，TCP多对一需要大量缓冲才能在没有EQDS的情况下正常工作，但生产数据中心的实际行为是什么？我们在Amazon EC2上租用了虚拟机（接收端为5.8x，其他所有设备为5.x，链路速度为10Gbps），并部署了Linux内核版本的EQDS，配置为在RTS模式下运行，因为EC2目前没有实现裁剪。

我们运行了相同的工作负载，850台主机对一个接收端运行iperf，结果如图15所示。请注意此图的线性x轴：EC2中的多对一流量工作得相当好，类似于仿真的公平排队结果。在EC2的EQDS上运行的TCP实现了几乎完美的共享，吞吐量比基线高4%，与我们的仿真相匹配。

为了实现如此良好的共享，EC2似乎使用了大的缓冲区。我们通过在incast之前和期间从空闲VM ping相同的目标来测量这些缓冲区。图16是ping延迟的CDF。EC2 ping延迟在10Gbps incast期间从55us增加到9ms，增加了163x，表明该网络中存在约11MB的缓冲区。相比之下，EQDS实现了类似的多对一吞吐量，ping延迟仅增加了21us。

这种行为是EC2还是RTS后端特有的？我们在我们的试验台上用裁剪代替RTS进行了类似的实验。图10显示了结果。当目的地繁忙时，带裁剪的EQDS会导致ping RTT增加36us，与EC2上的RTS类似。如果没有EQDS，增长速度约为500us，因为我们的TCP交换机缓冲区为1MB（小于EC2），链路速度为25Gbps。总之，EC2似乎正在使用大型缓冲区来应对incast。这会如何影响对延迟敏感的流量？

**Memcached**。我们在EC2目标虚拟机上安装了memcached，并使用基准客户机memcslap以闭环方式发出1000个GET/PUT操作来衡量服务器性能。EC2中空闲memcached服务器的平均请求延迟为700us。在EQDS上运行时，由于EQDS的额外内核处理和RTS的使用，相同的请求大约需要900us。

当目的地100个iperf客户端正忙着向其发送时，EQDS上的平均请求延迟会增加3到3毫秒，主要是因为与iperf共享带宽，而没有EQDS时，由于缓冲区较大，平均请求延迟会增加140倍到100毫秒。在850个iperf客户端发送的情况下，通过EQDS的memcached平均请求延迟为23ms，这是因为与本机EC2上的400ms相比，memcached与8.5倍的流量共享带宽。总体而言，EQDS将繁忙EC2服务器的memcached请求延迟比基线减少了20到30倍。

**微服务应用**。我们在内核EQDS上运行了DeathStarBench的延迟敏感社交网络应用程序。我们分布化了微服务节点，以确保大多数请求不是本地的，必须使用网络，并使用wrk以闭环方式生成请求。

我们测试了两种情况：一种是网络空闲，另一种是流向相同主机的高吞吐量饱和的链路速率流量填充交换机缓冲区。我们注意到社交网络应用程序不会产生太多流量（峰值100Mbps），但对延迟敏感，因此我们预计在“繁忙”场景中会看到更长的网络延迟的影响。

图11和图12显示了结果。在空闲网络上，社交网络请求需~2毫秒完成，基线和EQDS之间几乎没有差异。我们的部署可以维持每秒约500个请求的请求负载，之后DSB会使CPU饱和。然而，当网络繁忙时，EQDS将请求延迟减少50%，并且可以维持基线请求负载的两倍。

## **8.3 共享网络**

EQDS允许细粒度的主机共享策略，而无需网络内支持；我们研究了一些有趣的场景。

**与TCP竞争的无响应流量**。考虑图17中的场景，其中我们的测试平台中的接收端从4个TCP发送端接收数据，然后UDP发送端开始以线速率发送（用iperf3仿真）。由于UDP流不响应拥塞，在传统模式下运行的测试台网络允许UDP流使用近25Gbps的带宽，从而耗尽TCP流。使用EQDS（在本实验中处于裁剪模式），UDP发送方在发送EQIF处被限制，该EQIF强制实现完美的入口共享，而不需要在网络中进行公平排队（公平队列）。

**拥塞控制器很好**。事实上，EQDS可以使现有拥塞控制器的任何组合在没有任何网络内支持的情况下公平共存。在图18中，我们展示了两个发送方发送到同一个接收方时的共享结果，其中一个发送方使用Cubic，另一个使用x轴标签上显示的拥塞控制算法。

我们使用了Linux内核中所有可用的拥塞控制实现，以及Mellanox DCQCN实现。EQDS能够公平地共享接收端的链路，而几乎所有拥塞控制器都不需要网络内支持，于此对比的是BBR等基于延迟的方案被基于丢包的方案（例如Cubic）给饿死。一个例外是Vegas控制器，它在单独运行时无法通过EQDS利用25Gbps链路，在与Cubic竞争时获得的份额较小。这似乎是由于Vegas测量了一个小的基准RTT，并在达到BDP之前停止了窗口增加。

EQDS TX队列中的缓冲量如预期的那样取决于拥塞控制算法。BBR是最好的，以线速率发送时的平均延迟为243us，而DCTCP（K=16）为435us，Cubic为1315us。

**RDMA和TCP**。为了了解EQDS如何帮助不同主机协议栈之间的有效共存，我们在T2（BlueField NIC）中运行单个TCP和n个RDMA流，以到达同一目的地。图19显示了竞争流之间的带宽分布，因为RDMA流的数量从0到4不等。如果没有EQDS，TCP会填充交换机缓冲区，而DCQCN会导致RDMA回退，一些RDMA流会被耗尽。通过EQDS，数据在发送主机上进行缓冲，带宽分配由接收端决定，从而保护RDMA并公平共享带宽。

**NVMeOF与TCP shuffle并行**。为了理解单瓶颈链路之外的共享，并在EQDS上测试CX4 RDMA协议栈，我们在T2测试台（CX4主机）上仿真MapReduce shuffle操作，同时运行NVMeOF RDMA基准测试（第8.1节）。具体来说，一个ToR上的三个节点同时运行iperf发送端和NVMeOF目标。这三个节点发送到另一个ToR上的三个节点，该ToR同时运行iperf接收端和执行随机读取的NVMeOF客户端。

我们观察到，使用EQDS时，单独使用TCP shuffle比不使用EQDS时快约30%（26.1 Gbps vs 19.6 Gbps），这与之前的实验一致。当TCP和RDMA在没有EQDS的情况下同时运行时，shuffle/洗牌吞吐量将下降到17.6 Gbps，NVMeOF将下降到2.56 Gbps，这远远不是最佳的公平份额。在EQDS下，shuffle和NVMeOF分别达到15.8 Gbps和10 Gbps，这既是更公平的分配，也是更高的总体吞吐量。

## **8.4 传统网络中的EQDS**

为了研究具有core超额订阅的EQDS，我们在T1试验台上用两个25Gbps spine链路互连了两个TOR。公平排队已启用。一个ToR承载三台服务器（2台100Gbps，1台10Gbps）；另一个ToR承载八个客户端（10和25Gbps链路的混合）。每个客户端连接到一台服务器，并以闭环（closed-loop）形式连续请求1MB对象，每次都创建一个新的TCP连接。客户机在服务器之间是均衡的。

我们将活动客户端的数量从1（核心利用率≈50%）增加至8（400%的core超额订阅）。我们绘制了基线TCP、带裁剪的TCP-over-EQDS和使用RTS的TCP-over-EQDS的中值和99%FCT。当core负载较轻时，EQDS的数据包级负载均衡给出的中值稍小（图20），第99百分位FCT小2到5倍（图21）。随着我们添加更多客户端，core变得过载，EQDS最终的行为与本机基线类似，而RTS比基线稍慢，因为它需要大量缓冲。对于具有裁剪功能的EQDS，随着核心变得更加繁忙，裁剪率会增加，并且每个数据包可以多次重新发送。虽然这不会影响FCT，但这是不可取的；当检测到核心拥塞时，最好降低pull的速率。

**传统“大象”流**。为了了解传统流量如何与EQDS共存，我们使用相同的配置，但两个客户端从两台服务器下载1MB对象，并创建一个到另一个客户端的持久iperf3流。我们将此传统流的吞吐量从0更改为25Gbps，并测量其他流的FCT。图22显示了本机1MB流和大象流之间spine上的流碰撞如何影响FCT：大象流完全占据spine链接时，中值增长2.5倍。通过EQDS，包spraying有助于减轻大象流的影响，FCT的增加是适度的。负载感知路由的未来实现应该会进一步改进。

## **8.5 EQDS的主机处理评估**

到目前为止，我们的实验研究了EQDS如何帮助现有协议栈，并使用了25Gbps（我们的试验台）和10Gbps链路速度（EC2，仿真）。现在，我们检查两个EQDS实现的性能和开销，并评估它们在更高速度下的性能。我们使用几种配置进行了测试：

**设置1**。主机上的DPDK，包括本机传输和虚拟机协议栈下的DPDK，EQDS在虚拟化中扮演软件交换机的角色。

**设置2**。基于SoC的SmartNIC（Broadcom Stingray PS225或Mellanox BlueField 2）上的DPDK，支持传统TCP和RDMA流量。

**设置3**。主机上的DPDK，处理与Mellanox CX4 NIC之间的RDMA通信。

**设置4**。我们的Linux内核5.4实现，EQDS内核模块在TCP/IP协议栈下运行。

DPDK实现是最通用且性能最好的，尽管这取决于更高级别的协议栈和使用的设置（图23）。设置1中使用零拷贝本机EQDS传输的*eqdsperf*提供了最佳性能。在两台配备Intel Columbiaville NIC的2.5GHz Xeon Silver 4215机器之间，*eqdsperf*可实现40Gbps（1.5KB数据包）和100Gbps（4KB数据包）。瓶颈是发送者；当两个发送方连接到同一个接收端时，链路会被3KB的数据包占满/饱和。

在设置1中，当我们使用vhost用户网络在KVM中的Linux虚拟机下运行EQDS时，它以1.5KB的数据包达到27Gbps，而基线（testpmd）为40Gbps。testpmd和EQDS的成本都来自从客户端/guest到主机的数据包拷贝。

在设置2中，我们在Broadcom PS225 SmartNIC和Mellanox的BlueField 2 NIC上运行EQDS。我们的EQIF为两个链路中的每一个使用一个NIC核，一个用于信用调节/pacing。在Stingray上，当MTU为1.5KB或更大时，EQDS用单核填满/saturate链路。在PS225上，结果与EQDS在8KB MTU下达到50Gbps时相似。我们注意到SmartNIC ARM内核比x86内核弱，内存带宽似乎有限；达到100Gbps可能需要更多的卸载。

在设置3中，我们通过主机核从Mellanox ConnectX-4 Lx NIC传输RDMA流量。这并不理想，因为它需要通过PCIe总线进行额外的往返时间，但即使没有智能NIC，也可以通过EQDS演示RDMA。由于CX4 PCIe带宽为56Gbps，我们将链路带宽限制为10Gbps，以避免PCIe瓶颈。使用EQDS，两个RDMA节点之间的单个RDMA流的带宽与基线RDMA相同（图23），但额外的PCIe往返会在空载系统上增加9us的平均延迟，在负载下增加14us的平均延迟。

在设置4中，我们在内核模块中运行EQDS。图25显示了有EQDS和没有EQDS的TCP性能，并探讨了TCP卸载的影响。我们的内核实现可以达到55Gbps（一个内核）的超大程序，或27Gbps的1.5KB MTU。TCP对卸载支持的依赖是显而易见的。当以55Gbps的速度运行iperf时，EQDS将发送方和接收方的CPU利用率分别提高2%和5%。

**建立隧道开销**。当EQDS隧道已经建立时，EQDS只会增加几微秒的延迟，如图23所示。然而，当接触到新主机时，将使用零RTT方法动态设置隧道。我们通过拆除隧道，然后发送一系列ping来测量这一点；第一次ping时间与后续ping时间之间的差异约为20us。此设置延迟是由于隧道数据结构的内存初始化成本造成的。

**EQDS内存消耗**。EQDS内存消耗如何随数据中心的大小而扩展？有三种类型的内存需要考虑。

发送EQIF缓冲等待传输的数据包。对于TCP，我们默认每个目的地使用100个数据包，但我们发现，如果需要，在发送到多个接收端时，每个目的地可以减少到4个数据包。对于RDMA，上限标记阈值设置为375个数据包。

接收EQIF对每个发送方都有一个重新排序缓冲区。在链路故障的最坏情况下，缓冲区可以到达EQDS窗口，该窗口介于50个数据包（DPDK）和150个数据包（内核）之间。在实践中，这被限制为少于10个数据包。

飞行中的数据包在等待重新传输的发送方进行缓冲，但等待的缓冲区大小受到BDP的限制。我们通过向越来越多的接收端启动iperf来验证这一点。无论接收端的数量如何，所有隧道中的飞行中数据包总数都会达到约400个数据包的饱和值（NIC环大小加上一个BDP）的。

使用1.5GB的DRAM，EQDS可以为10000个活跃目的地缓冲数据包；这适用于我们使用的SmartNIC（8-16GB）以及主机的RAM。实际上，活跃目的地的数量和实际缓冲区利用率都较小；在EC2上，对于850个发送端，EQDS的接收端内存使用量不超过100MB。

# **结论和下一步工作**

EQDS是一个新的网络层，通过将共享队列从数据中心网络核心拉出并移动到边缘，在共存的传输之间提供强大的性能隔离。更重要的是，它引入了一种新的数据报服务抽象，它将上面的传输服务与下面的网络实现完全分离，从而实现这些层的独立演化，同时确保它们之间未来的兼容性。

EQDS是为逐步部署使用而设计的。从应用程序的角度来看，RDMA和TCP EQIF允许在不修改任何应用程序的情况下无缝部署EQDS。从长远来看，我们设想在EQDS原生API上实现并优化的应用程序协议的出现，从而充分利用它们提供的对网络性能的改进可见性。

从网络基础设施的角度来看，可以在Linux内核、SmartNIC或/和主机中使用我们的纯软件实现，以低性能成本以获得EQDS隔离的好处，也可以在没有交换机支持的情况下运行数据包裁剪。

从部署的角度来看，NIC实现是理想的，因为它与主机软件完全分离，主机软件可以像以前一样使用卸载支持。然而，我们的智能NIC设置增加了一些不必要的延迟（12-16us），在1.5KB MTU的情况下，每个核心的延迟限制为25Gbps。这些限制应该可以通过对EQDS的NIC ASIC支持来解决。

连接传输协议的现有ASIC和FPGA实现有很多例子，从RDMA到TCP卸载引擎。EQDS NIC将建立在这些工作的基础上，其硬件版本实际上可能更简单：为每个连接的端点而不是每个流保持状态意味着可以在片上内存中存储更多连接，其宽松的顺序和可靠性保证允许实现更简单的状态机。通过卸载控制包处理，我们期望显著缩短EQDS控制环路延迟，并减少其抖动，从而最大限度地减少交换机缓冲区的使用。此外，卸载连接设置和拆除逻辑将允许低延迟小流量接近本机性能。

**参考文献**：Vlad Olteanu, Haggai Erran, Dragos Dumitrescu, Adrian Popa, Cristi Baciu, Mark Silberstein,Georgios Nikolaidis, Mark Handley, Costin Raiciu，“**An edge-queued datagram service for all datacenter traffic**”，**NSDI2022**.

> <span style="font-style: italic;">声明：本文素材来源于网络，仅供学习使用，如有侵权请联系网站删除(ngdcn_admin@163.com)。由于本人水平有限，如有纰漏，请以参考文献文章为准。</span>

<font color=red>**欢迎扫码关注微信公众号“网络技术风云汇”，更快速接收更多网络技术咨询。**</font>