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

本文主要解决的问题是在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周期。

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）来说明问题。

       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 快速增加速率。

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的设置应取决于剩余的可用资源。如下公式：

4. ANALYSIS OF DCQCN

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

 

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

 

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

 

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