一周一论文（翻译）——[SIGMOD 2015] Congestion Control for Large-Scale RDMA

桃扇骨 2023-07-10 15:57 1阅读 0赞

本文主要解决的问题是在**RoCEv2****体系**中，基于优先级的拥塞控制PFC是一种粗粒度的机制。 它在端口（或端口加优先级）级别上运行，并且不区分流。PAUSE机制是基于每个端口（和优先级）的，而不是基于每个流的。 这将导致**Unfairness**和**Victim flow**等问题。**为了解决这个问题，作者提出了****DCQCN****机制，DCQCN****提供快速收敛以达到公平性，实现高链路利用率，确保低队列建立和低队列振荡。**并且为了优化DCQCN性能，我们建立了一个流体模型，并提供了调整开关缓冲区阈值和其他协议参数的指南。

### Abstract ###

现代数据中心应用要求网络具有高吞吐量（40Gbps）和超低延迟（每跳<10 µs），且CPU开销较低。 标准的TCP / IP堆栈不能满足这些要求，但是可以使用远程直接内存访问（RDMA）。 **在IP****路由的数据中心网络上，RDMA****使用RoCEv2****协议进行部署，该协议依赖于基于优先级的流控制（PFC****）来实现无损网络。** **但是，由于行首阻塞和不公平之类的问题，PFC****可能导致较差的应用程序性能。****为了缓解这些问题，我们引入了DCQCN****，它是RoCEv2****的端到端拥塞控制方案。** **为了优化DCQCN****性能，我们建立了一个流体模型，并提供了调整开关缓冲区阈值和其他协议参数的指南。** 通过使用3层Clos网络测试平台，我们证明DCQCN极大地提高了RoCEv2 RDMA流量的吞吐量和公平性。 DCQCN已在Mellanox NIC中实现，并已部署在Microsoft的数据中心中。

# 1. Introduction #

诸如云存储\[16\]之类的数据中心应用需要高带宽（40Gbps或更高）才能满足不断增长的客户需求。 传统的TCP / IP堆栈不能以这种速度使用，因为它们具有非常高的CPU开销\[29\]。 云服务业务的残酷经济学表明，应将无法货币化的CPU使用率降到最低：用于支持高TCP吞吐量的核心是不能作为VM出售的核心。 其他应用程序，例如分布式内存缓存\[10、30\]和大规模机器学习，都要求超低延迟（每跳小于10 µs）的消息传输。 传统的TCP / IP堆栈具有更高的延迟\[10\]。

我们正在Microsoft的数据中心中部署远程直接内存访问（RDMA）技术，以提供超低延迟和高吞吐量的应用程序，而CPU开销却非常低。 使用RDMA，网络接口卡（NIC）可以在两个终端主机上的预注册内存缓冲区中进出数据。 网络协议完全在NIC上实现，绕过主机网络堆栈。 Kernel-by-pass大大降低了CPU开销和整体延迟。 为了简化设计和实现，该协议采用了无损网络结构。

尽管HPC社区在特殊用途的集群中长期使用RDMA \[11、24、26、32、38\]，但在现代的IP路由数据中心网络中大规模部署RDMA却带来了许多挑战。 一个关键的挑战是需要一种拥塞控制协议，该协议可以在高速，无损环境中高效运行，并且可以在NIC上实现。

为此，我们已经开发了一种称为数据中心QCN（DCQCN）的协议。 DCQCN建立在RoCEv2标准中定义的拥塞控制组件的基础上。 DCQCN在Mellanox NIC中实现，目前正在Microsoft的数据中心中部署。

要了解DCQCN的需求，有必要指出，**从历史上看，****RDMA****是使用InfiniBand****（IB****）\[19****，21\]****技术进行部署的。 IB****使用定制的网络堆栈和专用硬件。** **IB****链路层（L2****）使用基于hop-by-hop****流量控制来防止由于缓冲区溢出而导致数据包丢失。** 无损链路层L2使IB传输协议（L4）变得简单而高效。 大部分IB协议栈都在NIC上实现。 IB通过所谓的单边操作支持RDMA，其中服务器在其NIC上注册一个内存缓冲区MR，客户端从该NIC读取（写入），而无需服务器CPU的进一步参与。

但**是，****IB****网络堆栈无法轻松地部署在现代数据中心中。****现代数据中心采用IP****和以太网技术构建，而IB****堆栈与此不兼容。 DC****运营商不愿在同一数据中心内部署和管理两个独立的网络。****因此，为了启用基于以太网和IP****网络的RDMA****，已经定义了基于聚合以太网（RoCE****）\[20\]****的RDMA****标准及其后继产品RoCEv2 \[22\]****。 RoCEv2****保留IB****传输层，但用IP****和UDP****封装代替IB****网络层（L3****），并用以太网代替IB L2****。 IP****标头用于路由，而UDP****标头用于ECMP \[15\]****。**

为了实现高效运行，例如IB，RoCEv2也必须部署在无损链路层L2上。 为此，使用基于优先级的流量控制（PFC）来部署RoCE \[18\]。 **PFC****允许以太网交换机通过强制级联的上游实体（另一台交换机或主机NIC****）暂停数据传输来避免缓冲区溢出。** **但是，PFC****是一种粗粒度的机制。****它在端口（或端口加优先级）级别上运行，并且不区分流。****这可能导致拥塞扩散，从而导致性能不佳\[1****，37\]****。（基于优先级的流量控制存在的问题）**

**PFC****局限性的基本解决方案是flow-level****级别的拥塞控制协议。**在我们的环境中，该协议必须满足以下要求：（i）通过无损链路层，L3路由的数据中心网络进行的功能；（ii）在最终主机上产生较低的CPU开销；以及（iii）在公共端提供超快速启动没有拥塞的情况。 当前用于DC网络中拥塞控制的建议不能满足我们的所有要求。 **例如，QCN \[17\]****不支持L3****网络。 DCTCP \[2\]****和iWarp \[35\]****包含一个缓慢的启动阶段，这可能会导致突发存储工作负载的性能下降。** DCTCP和TCP-Bolt \[37\]是用软件实现的，并且可能具有很高的CPU开销。

由于当前的提议都不能满足我们的所有要求，因此我们设计了DCQCN。 **DCQCN****是RoCEv2****的端到端拥塞控制协议，用于在大型IP****路由数据中心网络中部署RDMA****。 DCQCN****仅需要数据中心交换机支持标准的RED \[13\]****和ECN \[34\]****。****协议的其余功能在最终主机NIC****上实现。 DCQCN****提供快速收敛以达到公平性，实现高链路利用率，确保低队列建立和低队列振荡。**

本文的结构如下。 在§2中，我们提供证据来证明需要DCQCN。 第3节介绍了DCQCN的详细设计，并简要介绍了硬件实现。 在§4中，我们展示了如何设置PFC和ECN缓冲器阈值以确保DCQCN的正确运行。 在§5中，我们描述了DCQCN的流体模型，并用它来调整协议参数。 在§6中，我们使用3层测试平台和来自数据中心的跟踪来评估DCQCN的性能。 我们的评估表明，DCQCN大大提高了RoCEv2 RDMA流量的吞吐量和公平性。 在某些情况下，它使我们可以处理多达16倍的用户流量。 最后，在§7中，我们讨论了诸如非拥塞包丢失之类的实际问题。

# 2. THE NEED FOR DCQCN #

为了证明对DCQCN的合理性，我们将证明TCP堆栈不能以低CPU开销和超低延迟提供高带宽，而RoCEv2上的RDMA可以提供。 接下来，我们将证明PFC会损害RoCEv2的性能。 最后，我们将争辩说，现有的解决PFC疾病的解决方案不适合我们的需求。

### 2.1 Conventional TCP stacks perform poorly ###

现在，我们比较RoCEv2和传统TCP堆栈的吞吐量，CPU开销和延迟。 这些实验使用通过40Gbps交换机连接的两台机器（Intel Xeon E5-2660 2.2GHz，16核，128GB RAM，40Gbps NIC，Windows Server 2012R2）。

**Throughput and CPU utilization**：为了测量TCP吞吐量，我们使用针对环境定制的Iperf \[46\]。 具体来说，我们启用LSO \[47\]，RSS \[49\]和zero-copy操作，并使用16个线程。 为了测量RDMA吞吐量，我们使用了一个自定义工具，该工具使用IB READ操作来传输数据。 使用RDMA，单个线程会使链接饱和。

**图1****（a****）显示TCP****具有很高的CPU****开销。****例如，消息大小为4MB****，以驱动全部吞吐量，TCP****在所有内核上平均消耗20****％以上的CPU****周期。****在较小的消息大小下，由于CPU****成为瓶颈，TCP****无法使连接传输饱和。** 马里诺斯（Marinos）等人 \[29\]曾报道Linux和FreeBSD的TCP性能同样差。 他们甚至建议的用户级堆栈也会消耗20％以上的CPU周期。 相反，即使对于较小的消息大小，RDMA客户端的CPU利用率也低于3％。 正如预期的那样，RDMA服务器几乎不占用CPU周期。

![20200303204424700.png][]

Latency：延迟是小规模数据传输的关键指标。 现在，我们比较使用TCP和RDMA传输2K消息的平均用户级别延迟。 为了最大程度地减少TCP延迟，已预先建立并预热了连接，并禁用了Nagle。 使用高分辨率计时器（≤1 µs）测量延迟\[48\]。 网络上没有其他流量。

图1（c）显示TCP延迟（25.4 µs）明显高于RDMA（读/写为1.7 µs，发送为2.8 µs）。 在Windows的\[10\]和Linux \[27\]中报告了类似的TCP延迟。

### 2.2 PFC has limitations ###

**RoCEv2****需要PFC****才能启用无损以太网结构。 PFC****可以防止以太网交换机和NIC****上的缓冲区溢出。****交换机和NIC****跟踪入口队列。****当队列超过特定阈值时，将PAUSE****消息发送到上游实体。****然后，上游链路实体停止在该链路上发送，直到获得RESUME****消息为止。** PFC最多指定八个优先级类别。 暂停/恢复消息指定了它们适用的优先级。

**问题在于，PAUSE****机制是基于每个端口（和优先级）的，而不是基于每个流的。****这可能导致行头阻塞问题；****导致个别流的效果不佳**。 现在，我们使用代表现代数据中心网络的3层测试平台（图2）来说明问题。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70][]

**Unfairness**:：考虑图3（a）。 四个发送方（H1-H4）使用RDMA WRITE操作将数据发送到单个接收器（R）。 所有发送者都使用相同的优先级。 理想情况下，四个发送方应平均共享瓶颈链接（T4至R）。 但是，对于PFC，存在不公平。 当队列开始在T4上建立时，它将暂停传入的链接（端口P2-P4）。**但是，P2****仅承载一个流（来自H4****），而P3****和P4****可能承载多个流，这是因为H1****，H2****和H3****必须共享这两个端口，具体取决于ECMP****如何映射这些流。****因此，H4****比H1-H3****获得更高的吞吐量。** 这被称为parking lot problem问题\[14\]。

如图3（b）所示，该图显示了H1-H4在1000次4MB数据传输中测得的最小，中值和最大吞吐量。 H4的吞吐量高达20Gbps，例如 当ECMP将所有H1-H3映射到P3或P4时。 H4的最小吞吐量高于H1-H3的最大吞吐量。

**Victim flow**：由于PAUSE帧可能具有级联效果，因此流甚至可能不在其路径上被拥塞所伤害。 考虑图4（a）。 四个发送器（H11-H14）将数据发送到R。此外，我们有一个“受害者流”-VS发送到VR。 图4（b）显示了受害流的中值吞吐量（每个250MB的250个传输）。

如果在T3下没有发送方，则在中间值情况下（H11-H14中的两个映射到T1-L1，其他映射到T1-L2。每个H11-H14获得10Gbps的吞吐量。VS映射到T1的一个上行链路），一个可能 期望VS获得20Gbps的吞吐量。 但是，我们看到它只能得到10Gbps。 这是由于级联的“暂停”。 由于T4是H11-H14传播的瓶颈，因此最终会暂停其传入的连接。 这进而导致L3和L4暂停其传入的链接，依此类推。 最终，L1和L2最终暂停了T1的上行链路，并且T1被迫暂停发送者。 使用这些上行链路的T1上的数据流同样受到这些暂停的影响，而不论它们的目的地是什么–这也被称为“head-of-the-line blocking”问题。

当我们启动发送器H31和H32并将其发送到R时，问题变得更加严重。我们看到，尽管从H31和H32到R的路径没有任何共同的链接，但中值吞吐量进一步从10Gbps下降到4.5Gbps。发生这种情况是因为H31和H32在L3和L4上与H11-H14竞争，使它们的暂停S1和S2更长，最终使T1暂停发送者更长。

**Summary**：这些实验表明，由于PFC的拥塞扩散特性，RoCEv2部署中的流量可能会看到较低的吞吐量和/或较高的可变性。

### 2.3 Existing proposals are inadequate ###

许多提案试图解决PFC的局限性。 一些人认为，ECMP可以通过在多个链路上分散流量来缓解此问题。 上一节中的实验表明，情况并非总是如此。 PFC标准本身包含优先级概念，以解决最前端的阻塞问题。 但是，该标准仅支持8个优先级类别，并且通过扩展拓扑并添加更多发件方，可以使上述两种情况都变得更糟。 此外，同一类别内的流量仍将受到PFC的限制。

PFC问题的根本解决方案是使用流量级别flow-level的拥塞控制。 如果对每个流应用适当的拥塞控制，则很少触发PFC，因此可以避免本节前面所述的问题。

为此，定义了量化拥塞通知（QCN）\[17\]标准。 **QCN****启用L2****域内的流级别拥塞控制。****使用源/****目标MAC****地址和流ID****字段定义流。****交换机在每个数据包到达时计算拥塞度量。****它的值取决于瞬时队列大小和所需均衡队列大小之间的差异，以及其他因素。****然后，交换机可能（概率取决于拥塞的严重程度）将拥塞度量的量化值作为反馈发送到到达数据包的源。****源响应于拥塞反馈而降低其发送速率。**由于在没有拥塞的情况下不会发送任何反馈，因此发送方使用内部计时器和计数器来提高其发送速率。

QCN不能用于IP路由网络中，因为流的定义完全基于L2地址。 在IP路由网络中，当数据包通过网络传输时，原始的以太网报头不会保留。 因此，拥塞的交换机无法确定向其发送拥塞反馈的目标。

我们考虑将QCN协议扩展到IP路由网络。 但是，这并非易事。 至少要将QCN扩展到IP路由网络，需要使用IP五元组作为流标识符，并在拥塞通知数据包中添加IP和UDP标头，以使其能够到达正确的目的地。 **要实现这一点，需要对NIC****和交换机进行硬件更改。**由于QCN功能已深深集成到ASIC中，因此对开关进行更改尤其成问题。 ASIC供应商实施，验证和发布新的交换ASIC通常需要数月甚至数年的时间。 因此，更新芯片设计不是我们的选择。

在§8中，我们将讨论为什么其他提议（例如TCP-Bolt \[37\]和iWarp \[35\]）不能满足我们的需求。 由于现有建议不足，出于我们的目的，我们提出DCQCN。

# 3. THE DCQCN ALGORITHM #

DCQCN是基于速率的端到端拥塞协议，它基于QCN \[17\]和DCTCP \[2\]。 大多数DCQCN功能都在NIC中实现。

**如前所述，我们对DCQCN****有三个核心要求：（i****）在无损，L3****路由，数据中心网络上运行的能力，（ii****）低CPU****开销，以及（iii****）在没有拥塞的常见情况下超快速启动****。** **此外，我们还希望DCQCN****为公平的带宽分配提供快速收敛，避免在稳定点附近发生振荡，保持较短的队列长度，并确保较高的链路利用率。**

还有一些实际问题：我们不能要求交换机提供任何自定义功能，并且由于该协议是在NIC中实现的，因此我们必须注意实现的开销和复杂性。

DCQCN算法由发送方（反应点（RP）），交换机（拥塞点（CP））和接收方（通知点（NP））组成。

### 3.1 ALGORITHM ###

不改交换机，在NIC上实现，考虑CPU开销。在性能方面上，要求公平带宽分配的快速收敛，避免震荡，维持短队长，确保高链路利用率。

**CP****算法（Congestion Point****）：**在交换机上。与DCTCP机制相同，利用RED功能依据队列长度按照概率分布给数据包打上ECN标签。本方案中改进了DCTCP的参数设置模型。

**NP****算法（Notification Point****）：**在接收端。决定了在收到ECN包后什么时间和怎样构造CNP（congestion notification packet）的问题。在某一时间周期内，最多只发送一个CNP包。N=50us。

**RP****算法（Reaction Point****）：**在发送端。当收到CNP包时，怎么调节速率。当收到CNP包后，依照equation 1 调节；在连续K时间内，未收到CNP包，根据当前计时器（每T个时间单元为1，保证快恢复）和计数器（每B个字节为1）的值，按照equation 2 快速增加速率。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 1][]

# 4. BUFFER SETTINGS #

需求：PFC的触发要晚于ECN，早于缓存溢出，避免丢包和吞吐量下降

讨论的前提：交换机为共享缓存模式，有32个全双工的40Gbps端口，12MB的共享内存，支持PFC的8条优先级队列

**Tflight**：用于存储PAUSE包发送时和生效时到达的数据包的内存大小。根据BDP，每个端口，每个优先级所需要的内存空间为22.4KB。

**Tpfc**：可理解为触发PFC的ingress 队列中可以占用的最大内存区域。每个端口的每个优先级队列的Tpfc值要小于等于24.47KB。而触发PFC的条件一定要比它小。当队列内存占用降低到Tpfc减去两个MTU的值时，会自动发送RESUME信号，恢复发包。

**Tecn**：触发ECN标记的最小egress queue占用的内存空间。该值的设置一定要使ECN先于PFC触发。最坏情况下，所有的egress queue的包都来自于同一条ingress queue，为保证ecn先于pfc触发，则Tecn应小于0.85KB，小于一个MTU长度，不可行。这种想法过于静态，由于交换机内缓存资源是共享的，所以Tpfc的设置应取决于剩余的可用资源。如下公式：

![20200303204612276.png][]

![20200303204621686.png][]

# 4. ANALYSIS OF DCQCN #

建立了当前速率，目标速率，速率增长步长，速率调节参数α，等一系列参数。

实验结果：搭建实验床验证流模型和参数设置的有效性

DCQCN是基于速率调整的拥塞控制方案，DCTCP、iWarp和TCP-Bolt都是基于窗口的拥塞控制算法。

下一步研究方向：将机器学习应用到DCQCN算法中调节参数设置

[20200303204424700.png]: https://img-blog.csdnimg.cn/20200303204424700.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200303204452696.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200303204537961.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz,size_16,color_FFFFFF,t_70
[20200303204612276.png]: https://img-blog.csdnimg.cn/20200303204612276.png
[20200303204621686.png]: https://img-blog.csdnimg.cn/20200303204621686.png