【SIGCOMM 2015】出道即是巅峰！DCQCN：数据中心大规模部署RDMA的拥塞控制方案

内容提要

现代数据中心应用程序要求网络具有高吞吐量（40Gbps）和超低延迟（<10us/跳），且CPU开销较低。标准的TCP/IP协议栈不能满足这些要求，但是远程直接内存访问（RDMA）可以。在基于IP路由的数据中心网络上，RDMA使用RoCEv2协议部署，该协议依赖于基于优先级的流量控制（PFC）来实现无丢包网络。然而，PFC会由于诸如头阻塞（head-of-line blocking）和不公平等问题导致应用程序性能低下。为了缓解这些问题，我们引入了DCQCN，一种用于RoCEv2的端到端拥塞控制方案。为了优化DCQCN性能，我们建立了一个流体模型，并提供了调整交换机缓冲阈值和其他协议参数的指南。使用三层Clos网络测试平台，我们表明DCQCN显著提高了RoCEv2 RDMA流量的吞吐量和公平性。DCQCN已在Mellanox NIC中实现，并将部署在Microsoft的数据中心。

1. 引言

云存储等数据中心应用程序需要高带宽（40Gbps或更高）以满足不断增长的客户需求。传统的TCP/IP协议栈无法在这样的速度下使用，因为它们有非常高的CPU开销。云服务业务的残酷经济性/陈本考虑决定了CPU的使用应该最小化。其他应用程序，如分布式内存缓存和大规模机器学习，需要超低延迟（每跳少于10us）的消息传输。传统的TCP/IP协议栈具有更高的时延表现。

我们正在微软的数据中心部署远程直接内存访问（RDMA）技术，以极低的CPU开销为应用程序提供超低延迟和高吞吐量。使用RDMA，网络接口卡（NIC）在两个终端主机上的预注册内存缓冲区中传输数据。网络协议完全在NIC上实现，绕过主机网络协议栈。旁路（bypass）显著降低了CPU开销和总体延迟。为了简化设计和实现，该协议采用无损网络结构。

虽然HPC社区长期以来在特殊用途集群中使用RDMA，但在现代基于IP路由的数据中心网络中大规模部署RDMA带来了许多挑战。一个关键的挑战是需要一个能够在高速、无损的环境中高效运行并且能够在NIC上实现的拥塞控制协议。

为此，我们开发了一个称为数据中心QCN（DCQCN）的协议。DCQCN基于RoCEv2标准中定义的拥塞控制组件。且DCQCN在Mellanox NIC中实现，目前正在微软的数据中心部署。

为了理解对DCQCN的需求，有必要指出，从历史上看，RDMA是使用InfiniBand（IB）技术部署的。IB使用自定义网络协议栈和专门构建的硬件。IB链路层（L2）使用基于信用的hop-by-hop（逐跳）流控制来防止由于缓冲区溢出而导致的数据包丢失。无损L2允许IB传输协议（L4）简单且高效。IB协议栈的大部分是在NIC上实现的。IB通过所谓的单边操作支持RDMA，在这种操作中，服务器向其NIC注册内存缓冲区，客户端从中读取（写入）内存缓冲区，而无需服务器的CPU进一步参与。

然而，在现代数据中心中无法轻松部署IB网络协议栈。现代数据中心采用IP和以太网技术构建，IB协议栈与这些技术不兼容。DC运营商不愿意在同一数据中心内部署和管理两个独立的网络。因此，为了在以太网和IP网络上实现RDMA，定义了RDMA over Converged Ethernet（RoCE）标准及其后续RoCEv2。RoCEv2保留IB传输层，但用IP和UDP封装替换IB网络层（L3），用以太网替换IB L2。路由需要IP报头，而ECMP需要UDP报头。

为了实现像IB一样的高效操作，RoCEv2还必须部署在无损L2上。为此，RoCE使用基于优先级的流控制（PFC）进行部署。PFC允许以太网交换机通过强制直接上游实体（另一个交换机或主机NIC）暂停数据传输来避免缓冲区溢出。然而，PFC是一种粗粒度机制。它以端口（或，端口加优先级）级别运行，不区分流。这可能导致拥塞扩散，导致性能不佳。

PFC限制的根本解决方案是流量级拥塞控制协议。在我们的环境中，协议必须满足以下要求：（i）在无损、L3路由的数据中心网络上运行，（ii）在终端主机上产生较低的CPU开销，以及（iii）在无拥塞的常见情况下提供超快速启动。目前关于DC网络拥塞控制的建议并不能满足我们的所有要求。例如，QCN不支持L3网络。DCTCP和iWarp包括一个缓慢的启动阶段，这可能会导致突发性的存储工作负载的性能低下。DCTCP和TCP Bolt是在软件中实现的，会有很高的CPU开销。

由于目前的方案都不符合我们的所有要求，我们设计了DCQCN。DCQCN是RoCEv2的端到端拥塞控制协议，用于在大型基于IP路由的数据中心网络中部署RDMA。DCQCN只需要数据中心交换机的标准RED和ECN支持。其余的协议功能在终端主机NIC上实现。DCQCN提供快速收敛到公平性，实现高链路利用率，确保低队列累积和低队列振荡。

2. 需要DCQCN

为了证明DCQCN的必要性，我们将证明TCP协议栈不能提供低CPU开销的高带宽和超低延迟，而RoCEv2上的RDMA可以。接下来，我们将说明PFC会影响RoCEv2的性能。最后，我们将指出，现有的治疗PFC痼疾的解决方案不适合我们的需要。

2.1传统TCP协议栈性能较差

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

吞吐量和CPU利用率：为了测量TCP吞吐量，我们使用为我们的环境定制的Iperf打流工具。具体来说，我们启用LSO、RSS和零拷贝操作，并使用16个线程。为了测量RDMA吞吐量，我们使用一个自定义工具，该工具使用IB读取操作来传输数据。使用RDMA，单个线程就会使链路饱和。

图1（a）显示TCP有很高的CPU开销。例如，对于4MB的消息大小，为了提高吞吐量，TCP在所有核心上平均消耗超过20%的CPU周期。在较小的消息大小下，TCP不能使链路饱和，因为CPU成为瓶颈。Marinos等人报告说，Linux和FreeBSD的TCP性能也很差。即使是他们建议的用户级协议栈也会消耗超过20%的CPU周期。相比之下，RDMA客户端的CPU利用率低于3%，即使对于较小的消息大小也是如此。正如预期的那样，RDMA服务器几乎不占用CPU周期。

延迟：延迟是小型传输（小消息）的关键指标。现在，我们比较使用TCP和RDMA传输2K消息的平均用户级延迟。为了最大限度地减少TCP延迟，预先建立并预热了连接，并禁用了Nagle。使用高分辨率测量延迟(\leq 1us）计时器。网络上没有其他流量。

图1（c）显示TCP延迟（25.4us）明显高于RDMA（读/写为1.7us，发送为2.8us）。一些文献中针对Windows和Linux的报告也展现出了类似的TCP延迟。

2.2 PFC具有局限性

RoCEv2需要PFC来启用无丢包以太网结构。PFC可防止以太网交换机和NIC上的缓冲区溢出。交换机和NIC跟踪入口队列。当队列超过某个阈值时，将向上游实体发送暂停消息。然后，上行链路实体停止在该链路上发送数据，直到收到恢复消息。PFC最多指定八个优先级类别。暂停/恢复消息指定其应用的优先级级别。

问题在于暂停机制是按端口（和优先级）运行的，而不是按流量运行的。这可能导致线路阻塞（头阻）问题；导致单个流的性能不佳。现在，我们使用代表现代数据中心网络的三层测试床（图2）来说明这些问题。

不公平性：考虑图3（a）。四个发送端（H1-H4）使用RDMA写入操作向单个接收端（R）发送数据。所有发送方使用相同的优先级类别。理想情况下，四个发送方应该平等地共享瓶颈链路（T4到R）。然而，PFC存在不公平性。当队列开始在T4上建立时，它会暂停传入的链接（端口P2-P4）。然而，P2仅承载一个流（来自H4），而P3和P4可能承载多个流，因为H1、H2和H3必须共享这两个端口，这取决于ECMP映射流的方式。因此，H4比H1-H3接收到更高的吞吐量。这就是所谓的停车场问题。

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

受害流：因为暂停帧可能具有级联效应（cascading effect），所以流可能会受到甚至不在其路径上的拥塞的影响。请考虑图4（a）。四个发送端（H11-H14）向R发送数据。此外，我们还有一个“受害者流”——VS发送数据到VR。图4（b）显示了受害流的中值（median）吞吐量（250次传输，每次250MB）。

当T3下没有发送者时，在中间情况下（H11-H14中的两个映射到T1-L1，其他映射到T1-L2）。H11-H14中的每一个都可以获得10Gbps的吞吐量。VS映射到T1的一条上行链路），人们可能期望VS会获得20Gbps的吞吐量。但是，我们看到它只能获得10Gbps。这是由于级联暂停（cascading PAUSE）。由于T4是H11-H14 incast的瓶颈，它最终会暂停其传入链接。这进而导致L3和L4暂停其传入链接，以此类推。最终，L1和L2暂停T1到它们的上行链路，T1被迫暂停发送方。T1上使用这些上行链路的流量同样受到这些暂停的影响，而不管它们的目的地是什么——这也被称为线路阻塞问题。

当我们启动同样发送到R的发送端H31和H32时，问题变得更糟。我们发现，尽管从H31和H32到R的路径与VS和VR之间的路径没有任何共同的链接，但平均吞吐量进一步从10Gbps下降到4.5Gbps。这是因为H31和H32在L3和L4上与H11-H14竞争，使它们暂停S1和S2的时间更长，最终使T1暂停发送端的时间更长。

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

2.3 现有方案不充分

许多方案试图解决PFC的局限性。一些人认为ECMP可以通过在多个链路上分散流量来缓解这个问题。上一节的实验表明，情况并非总是如此。PFC标准本身包含一个优先级概念，用于解决线路阻塞问题。但是，该标准只支持8个优先级类，并且上面所示的两种情况都可以通过扩展拓扑和添加更多发送者而进一步恶化。此外，同一优先级中的流仍将受到PFC的限制。

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

为此，定义了量化拥塞通知（QCN）标准。QCN实现了L2域内的流级拥塞控制。流是使用源/目标MAC地址和流id字段定义的。交换机在每个数据包到达时计算拥塞度量。它的值取决于瞬时队列大小和所需平衡队列大小之间的差异，以及其他因素。然后交换机概率地（概率取决于拥塞的严重程度）将拥塞度量的量化值作为反馈发送到该到达分组的源。信源根据拥塞反馈降低其发送速率。由于如果没有拥塞，则不会发送反馈，因此发送方使用内部计时器和计数器提高其发送速率。

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

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

其他诸如TCP-Bolt和iWarp等其他方案也不能满足我们的需要。由于现有方案不充分，出于我们的目的，我们提出了DCQCN。

3. DCQCN算法

DCQCN是一种基于速率的端到端拥塞协议，它建立在QCN和DCTCP的基础上。大部分DCQCN功能在NIC中实现。

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

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

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

3.1 算法

CP算法：CP算法与DCTCP算法相同。在出口队列中，如果队列长度超过阈值，则对到达的数据包进行ECN标记。这是通过使用所有现代交换机上支持的RED功能（图5）实现的。为了模拟DCTCP，我们可以设置Kmin=Kmax=K和Pmax=1。稍后，我们将看到这不是最佳设置。

NP算法：到达NP的带有ECN标记的数据包表示网络拥塞。NP将此信息传回发送者。RoCEv2标准为此定义了显式拥塞通知包（CNP）。NP算法规定了生成CNP的方式和时间。

对于每个流，该算法遵循图6中的状态机。如果流的标记数据包到达，并且在最后N微秒内没有为流发送CNP，则会立即发送CNP。然后，如果标记了在该时间窗口内到达的任何其他数据包，但NIC最多每N微秒为流生成一个CNP数据包。我们在部署中使用N=50us。处理一个标记的数据包，并生成CNP是昂贵的操作，因此我们尽量减少每个标记数据包的活动。

RP算法：当RP（即流发送端）获得CNP时，它会降低其当前速率（R_C），并更新速率降低因子\alpha的值，如DCTCP，并将当前速率记为目标速率（R_T），以便稍后恢复。更新值如下：

公式1：

R_T=R_C

R_C=R_C(1−\frac{\alpha}{2})

\alpha= (1 − g）\alpha+g

如果NP没有得到任何标记的数据包，则不会生成反馈。因此，如果RPK个时间单位都没有得到反馈，它将更新\alpha，如等式（2）所示。请注意，K必须大于CNP生成计时器。我们的实现使用K=55us。

公式2：

\alpha= (1 − g)\alpha

此外，RP使用定时器和字节计数器增加其发送速率，方式与QCN相同。字节计数器每B字节增加一次速率，而计时器每T时间单位增加一次速率。计时器可确保即使流量降至较低值，流量也能快速恢复。这两个参数可以调整以达到所需的反应速度（aggressiveness）。速率增加分为两个主要阶段：快速恢复，在快速恢复阶段，对于F=5个连续迭代，速率向固定目标速率快速增加：

公式3：

R_C = (R_T + R_C)/2

快速恢复之后是加性增加，当前速率缓慢接近目标速率，并且目标速率以固定步骤R_{AI}增加：

公式4：

R_T = R_T + R_{AI}

R_C = (R_T + R_C)/2

还有一个快速上升的超增长阶段。图7显示了状态机。

请注意，没有慢启动阶段。当流启动时，如果没有来自主机的其他活动流，它将以全线路速率发送。此设计决策优化了流传输相对少量数据且网络不拥挤的常见情况。

3.2 收益

通过提供每流拥塞控制，DCQCN减轻了PFC的限制。为了说明这一点，我们在启用DCQCN的情况下重复第2.2节中的实验。

图8显示了DCQCN解决了图3中描述的不公平问题。所有四个流都获得了相等的瓶颈带宽份额，并且差异很小。图9显示了DCQCN解决了图4所示的受害者流问题。使用DCQCN，VS-VR流的吞吐量不会随着我们在T3下添加发送者而改变。

3.3 讨论

CNP生成：DCQCN对反向路径上的拥塞并不特别敏感，因为发送速率不依赖于准确的RTT估计，如TIMELY。尽管如此，我们还是以高优先级发送CNP，以避免错过CNP截止日期，并实现更快的收敛。请注意，在无阻塞的常见情况下，不会生成CNP。

基于速率的拥塞控制：DCQCN是一种基于速率的拥塞控制方案。我们采用了基于速率的方法，因为它比基于窗口的方法更易于实现，并且允许更细粒度的控制。

参数：DCQCN基于DCTCP和QCN，但在关键方面各不相同。例如，与QCN不同，没有量化反馈，与DCTCP不同，没有“per-ack”反馈。因此，建议用于DCTCP和QCN的参数设置不能盲目用于DCQCN。

对PFC的需求：DCQCN并不排除对PFC的需求。使用DCQCN，流量以线路速率开始。如果没有PFC，这可能导致数据包丢失和性能差。

硬件实现：NP和RP状态机在NIC上实现。RP状态机需要为每个速率受限的流保留一个计时器和一个计数器，除了少量的其他状态，例如\alpha的当前值。此状态在NIC芯片上保持。速率限制基于每个数据包的粒度。在ConnectX-3 Pro中实现NP状态机可以以每1~ 5微秒一个的速率生成CNP。在40Gbps的链路速率下，接收端每50微秒可接收约166个全尺寸（1500字节MTU）数据包。因此，对于10~ 20个拥堵流量，NP通常可以支持以所需速率产生CNP。当前版本（ConnectX-4）可以以要求的速率生成超过200个流量的CNP。

4. 缓冲区设置

DCQCN的正确运行需要平衡两个相互冲突的要求：（i）PFC未触发得太早（即在给ECN发送拥塞反馈的机会之前），以及（ii）PFC未触发得太迟，从而导致缓冲区溢出导致的数据包丢失。

现在，我们计算三个交换机关键参数的值：t_{flight}、t_{PFC}和t_{ECN}，以确保即使在最坏的情况下也能满足这两个要求。请注意，不同的交换机供应商对这些设置使用不同的术语；我们使用通用名称。讨论与任何共享buffer交换机相关，但计算仅限于Arista 7050QX32等使用Broadcom Trident II芯片组的交换机。这些交换机有32个全双工40Gbps端口，12MB共享缓冲区，支持8个PFC优先级。

Headroom缓冲区t_{flight}：发送到上游设备的暂停消息需要一段时间才能到达并生效。为了避免数据包丢失，暂停发送方必须保留足够的缓冲区来处理在此期间可能接收到的任何数据包。这包括发送暂停时正在飞行的数据包，以及上游设备在处理暂停消息时发送的数据包。最坏情况的计算必须考虑几个额外的因素（例如，交换机不能放弃它已经开始的分组传输）。按照一些文献中的指导原则，并假设一个1500字节的MTU，我们得到每个端口、每个优先级的t_{flight}=22.4KB。

PFC阈值t_{PFC}：这是在向上游设备发送暂停消息之前，入口队列可以增长到的最大大小。每个PFC优先级在每个入口端口都有自己的队列。因此，如果总的交换机缓冲区是B，并且有n个端口，则表示t_{PFC} \leq (B−8nt_{flight}）/（8n）。对于我们的交换机，我们得到了t_{PFC}\ leq 24.47KB。当队列低于t_{PFC}两个MTU时，交换机发送恢复消息。

ECN阈值t_{ECN}：一旦出口队列超过该阈值，交换机就开始标记该队列上的数据包（图5中的Kmin）。为了使DCQCN有效，此阈值必须确保在交换机有机会使用ECN标记数据包之前，不会达到PFC阈值。

但请注意，ECN标记是在出口队列上完成的，而暂停消息是基于入口队列发送的。因此，t_{ECN}是一个出口队列阈值，而t_{PFC}是一个入口队列阈值。

最坏的情况是所有出队列上等待(pending)的数据包来自单个入口队列。为了保证在任何出口队列上触发ECN之前，不会在此入口队列上触发PFC，我们需要：t_{PFC} > n *t_{ECN}。使用t_{PFC}值的上限，我们得到t_{ECN}<0.85KB。这少于一个MTU，因此不可行。

然而，我们不仅不必使用t_{PFC}的上限，甚至不必使用t_{PFC}的固定值。由于交换机缓冲区在所有端口之间共享，因此t_{PFC}应取决于共享缓冲区的空闲量。直观地说，如果缓冲区大部分是空的，我们可以等待更长的时间来触发暂停。我们交换机中的Trident II芯片组允许我们配置参数\beta，以便：t_{PFC}=\beta \times (B− 8nt_{flight}-s)/8，其中s是当前占用的缓冲区数量。较高的\beta触发PFC的频率较低，而较低的\beta触发PFC的频率更高。

请注意，s等于所有出口队列上等待的数据包的总和。因此，在任何出口端口上触发ECN之前（都没有触发ECN达标），我们有：s \leq n*t_{ECN}。因此，为了确保ECN总是在PFC之前触发，我们设置：t_{ECN} < \beta * (B− 8nt_{flight})/(8n(\beta + 1))。显然，\beta越大，t_{ECN}的空间就越大。在我们的测试平台中，我们使用\beta=8，这导致t_{ECN}<21.75KB。

讨论：以上分析是保守的，并确保PFC不会在ECN之前触发，即使在最坏的情况下，当所有8个PFC优先级都使用时。优先级较少或交换机缓冲区较大时，阈值将不同。

该分析并不意味着永远不会触发PFC。我们所能确保的是，在任何交换机处，在ECN之前不会触发PFC。发送方接收ECN反馈并降低其发送速率需要一些时间。在此期间，可能会触发PFC。如前所述，我们依靠PFC允许发送方以线路速率启动。

5. DCQCN的分析

我们使用DCQCN的流体模型来确定正确的参数设置以获得良好的性能。

5.1 流体模型

表1和表2中分别列出了流体模型中使用的变量和参数。方程(5)~(9)描述了该模型。与其他分析方法类似，我们在容量为C的单个瓶颈处对N个贪婪流进行建模。我们假设DCQCN早于PFC触发，因此在以下分析中忽略PFC。

等式（5）建模了数据包在瓶颈处被标记的概率。设置Kmin==Kmax，将给出类似于DCTCP的“截止/cut-off”行为。出于后面讨论的原因，我们对更一般的行为进行建模。方程（6）建模了瓶颈处队列的演化。我们假设所有流量具有相等的速率。稍后我们将放宽这一假设。方程（7）建模了\alpha在RP处的演化。

根据图7所示的算法和QCN规范，等式（8）和（9）模拟了RP处当前速率和目标发送速率的演变。我们对速率降低以及由于字节计数器和计时器导致的速率增加进行了建模，忽略了超加法增加阶段。 \tau*对控制回路的延迟进行建模。它包括RTT和NP的CNP生成间隔。为了简单起见，我们使用 \tau*= 50us（CNP产生的最大可能延迟）。

通过将方程(6)~(9)的LHS设为零，我们发现流体模型在满足方程（10）时有一个唯一的不动点。

公式10：

R_C(t) = \frac{C}{N}

此固定点表示所有流获得公平带宽共享C/N的状态。流体模型的其余部分变为三个方程，包含三个变量：R_T、\alpha和p。我们通过数值求解方程来确定固定点上的ECN标记概率p。p的解是唯一的。

为了简洁起见，我们省略了证明。我们验证了对于合理的设置，p小于1%。根据方程（5），当启用RED-ECN时，由于p接近于0，因此在Kmin附近存在一个固定的队列长度点。g的值对确定队列的稳定性起着重要作用，我们将在后面看到。

为了分析DCQCN协议的收敛特性，有必要将流体模型扩展到不同流速的流动。以两个流为例。我们分别对每个流的当前和目标发送速率及其\alpha的演变进行建模，即我们为每个流编写方程(7)-(9)。流通过其对队列的影响进行耦合：

公式11：

\frac{dq}{dt} = R_{C1}(t) + R_{C2}(t) − C

我们对该模型进行数值求解，以了解各种参数（表2）对DCQCN行为的影响；特别是收敛和队列累积。

实验表明，流体模型与实现非常匹配。我们在图10中显示了一个示例。

5.2 参数选择

我们关注的是一个双流系统，其中一个流以40Gbps开始，另一个流以0Gbps开始。对于每个参数设置，我们使用数值分析来求解前200ms。结果如图11所示。Z轴显示了两个流的吞吐量差异。为了可读性，我们省略了前10ms。

我们从QCN和DCTCP规范中推荐的参数开始。具体地说，B＝150KB；T=1.5ms；Kmin=Kmax=40KB；Pmax=1，g=1/16。

不幸的是，我们发现使用这些参数值，流无法收敛（图11（a）的最内侧边缘）。使用这些设置，QCN字节计数器控制着速率的增加，并且更快的流增长得更快。QCN使用概率反馈对此进行补偿，而DCQCN没有概率反馈。相反，解决方案是要么减慢字节计数器，要么加快速率增加计时器。图11（a）显示减慢字节计数器有助于提高收敛速度，但会降低收敛速度。加速计时器（图11（b））更好。请注意，计时器不能小于50us，这是NP的CNP生成间隔。由于定时器的设置过于激进，字节计数器应设置为较大的值，例如10MB，以避免触发超增加阶段过快，这可能会损害收敛。

另一种解决方案是使用一种具有较小Pmax的像RED(RED-like)概率分组标记方案，而不是DCTCP中使用的截止（一旦队列长度超过一定限制，标记所有分组）行为。直觉是DCQCN CNP的生成是由计时器驱动的，通过使用类似RED的标记方案和较小的Pmax，我们增加了更大流量获得更多CNP的可能性，因此后退速度更快。图11（c）和11（d）证实了这一直觉。

总之，为了实现快速收敛到公平性，我们在Kmax=200KB和Pmax=1%的交换机上配置了RED-ECN。我们将Kmin设置为5KB，因为我们发现它足以保持100%的吞吐量。虽然5KB的Kmin数看起来很浅，但Kmin周围的标记概率很小。流体模型预测，稳定队列长度通常比5KB Kmin大一个数量级。我们的部署经验和实验证实了这一点。我们还将速率增加计时器设置为55us，字节计数器设置为10MB。如果反馈延迟与我们假设的值显著不同（例如，如果RTT较高），则参数值将不同。

瓶颈处的队列长度取决于g的值。我们测试了从2:1 incast到16:1 incast场景下的不同g（图12），发现更小的g会导致更低的队列长度和更低的变化。较低的g导致收敛速度稍慢，但这是值得为较低的振荡付出的代价。

我们现在简要讨论其余参数。回想一下，由于硬件限制，CNP生成间隔固定为50us。我们假设反馈延迟( \tau)等于此值。我们已经验证，即使添加额外的50us延迟，流也能快速稳定地收敛。我们选择\alpha更新间隔\tau’和最小定时器值为55us。这些值需要大于CNP生成间隔，以防止在接收连续CNP之间不必要的速率增加。我们认为5us的空间（margin）足以满足当前硬件的需求。DCQCN通常对\tau’值不敏感：110us（默认值的两倍）几乎不会减慢收敛速度。我们还分析了R_{AI}和F的影响。它们都提供了收敛速度和吞吐量波动之间的折衷。此外，R_{AI}与g合作，影响DCQCN的可伸缩性(可扩展性)。例如，在当前设置中，16:1 incast没有缓冲区不足（图12）。将R_{AI}减半会降低收敛速度，但可以确保在32:1 incast时不会出现缓冲区不足。当前值是可接受的折衷方案。

讨论：DCQCN模型基于QCN模型，但有两个区别。首先，DCQCN的降低率是显著不同的。我们的模型还解决了字节计数器和定时器的速率提升机制，QCN只对字节计数器进行了建模。

6. 结果

现在，我们使用Mellanox ConnectX-3 Pro NIC评估DCQCN在各种设置下的性能。结果分为两部分。首先，我们在小型试验台上使用微基准点验证第5节中根据流体模型的发现。在实际部署中使用从模型派生的参数设置之前，此步骤是必不可少的。接下来，我们使用从流量跟踪中导出的基准流量来评估DCQCN，这些流量跟踪大致模拟了数据中心中正在进行的DCQCN部署。

6.1 微基准/Microbenchmarks

验证流体模型：第一步是显示流体模型是实现的良好代表。我们使用由三台机器组成的简单设置，通过Arista 7050QX32交换机连接。三台机器中的一台充当接收端，而另外两台充当贪婪的发送者。第一个发送端在时间0时启动，而第二个发送端在10毫秒后启动。DCQCN参数根据第5节中的讨论进行设置，交换机根据第4节中的讨论进行配置。图10显示了前100毫秒第二个发送端发送速率的变化。我们发现模型与固件实现非常匹配。

验证参数设置：虽然我们已经证明流体模型是我们实现的一个很好的表示，但是我们仍然需要用实际硬件验证模型预测的各个参数值。为此，我们使用与以前相同的3机设置进行了几次测试。在每个测试中，第一个发送端在时间0开始，第二个发送端在500毫秒后开始。

我们首先测试strawman参数值。图13（a）证实了模型预测的两个竞争流之间存在不公平。

接下来，我们验证了加速速率增加计时器可以减轻不公平性。图13（b）显示了实际情况（计时器值=55us）。注意，我们在这个实验中使用了DCTCP-like截止（cut-off）ECN。

我们还测试了第二种解决方案，即RED标记减轻了不公平问题，即使不改变计时器。为了测试，我们将交换机配置为Kmin=5KB、Kmax=200KB和Pmax=1%。图13（c）显示这两个流平均获得相似的吞吐量。然而，我们看到了流体模型没有显示的缺点：由于标记的随机性，吞吐量不稳定。

这些结果意味着在我们的部署中，我们应该像DCTCP一样标记数据包，并依靠更快的速率增加计时器来实现公平性。然而，我们发现在多瓶颈场景中，更快的计时器和RED标记的组合可以获得更好的性能。图13（d）显示了简单双流程场景中组合解决方案的行为。

我们还验证了g=1/256的值在这种情况下运行良好，正如流体模型所预测的那样。最后，使用通过单个交换机连接的20台机器，我们验证了使用55us定时器、RED-ECN和g=1/256时，K:1 incast, K=1~19, 总吞吐量始终大于39Gbps。交换机计数器显示队列长度从不超过100KB（在40Gbps时转换为20us）。

总之，我们在部署中使用了表14中所示的参数，在其余的评估中也使用了这些参数。

6.2 基准流量/Benchmark traffic

大规模RDMA部署的一个重要场景是云存储服务的后端网络。在这样的网络中，通信量包括用户请求以及由相对罕见的事件（如磁盘恢复）生成的通信量。磁盘恢复流量具有类似incast的特性，因为故障磁盘可以通过从其他几个服务器获取备份来修复。现在，我们使用图2所示的三层测试床（每个ToR连接五台主机）来评估此场景中DCQCN的性能。

为了模拟用户请求流量，我们使用从数据中心的单个集群收集的跟踪数据。这些数据是在480台机器的集群上收集的，收集时间为一天，其中包括1000多万条流的流量。跟踪不能直接在我们的测试台上重放。相反，与之前的工作一样，我们提取跟踪数据的显著特征，例如流大小分布，并生成合成流量来匹配这些特征。我们将磁盘恢复流量建模为incast。我们并不声称这个基准测试准确地模拟了真实的流量，只是说它在测试床设置中是一个合理的替换。

为了模拟用户流量，每个主机与一个或多个随机选择的主机通信，并使用从跟踪中导出的分布传输数据。通信对的数量固定为20（我们将在后面的实验中对此进行更改）。流量还包括一个磁盘恢复事件（因为这些事件不是很频繁）。我们将incast的程度从2变为10，以模拟不同的擦除编码模式（erasure coding pattern）。我们重复实验五次，使用和不使用DCQCN。根据表14设置DCQCN参数。每次运行随机选择通信对以及参与incast的主机。每次运行持续两分钟。

感兴趣的指标是吞吐量的中位数和尾部（第10个百分位）。提升的中间值意味着更好地利用网络，而提升的尾部性能则带来更可预测的应用程序性能，从而带来更好的用户体验。

结果如图16所示。图16（a）和图16（b）显示，如果没有DCQCN，用户流量的吞吐量会随着incast程度的增加而迅速下降。这个结果是令人惊讶的，因为即使incast的程度提高了，incast发送方产生的总流量也保持不变（因为瓶颈总是在接收方）。原因是PFC造成的“损害”。随着incast程度的增加，会产生更多的暂停消息。当这些数据通过网络级联时，会对用户流量造成严重破坏。影响spine交换机下行链路的暂停消息可能会造成广泛的损坏，因为许多流会通过这些交换机。例如，在incast程度为10的一次实验中，两个spine交换机一起接收超过600万条暂停消息。因此，像不公平和受害者流这样的场景变得更可能，并影响用户流的吞吐量。相反，当使用DCQCN时，spine交换机只看到3000条暂停消息（见图15）。因此，用户流量的性能要好得多。事实上，使用DCQCN，随着incast程度的提高，用户流量的中位数和尾部吞吐量几乎没有变化——这正是人们所希望的。

磁盘恢复流量也受益于DCQCN，因为DCQCN有助于在竞争流之间公平分配带宽。在理想情况下，每个incast流的吞吐量应等于40Gbps除以incast程度（数量）。图16（d）显示，对于DCQCN，第10百分位吞吐量非常接近该值，表明高度公平。相比之下，没有DCQCN，第10百分位吞吐量要低得多。例如，当incast次数为10时，不使用DCQCN的第10百分位吞吐量小于1.12Gbps，而使用DCQCN的吞吐量为3.43Gbps。注意，使用DCQCN的平均吞吐量（图16（c））似乎更低。然而，这是具有欺骗性的：如果没有DCQCN，后端将受到影响，其他流将攫取更多的“公平份额”。因此，中位数似乎更高。对于DCQCN，中值和第10百分位值几乎相同。

更高的用户负载：在图16中，我们看到DCQCN继续为用户流量提供良好的性能，即使incast的程度提高了。现在，我们将incast的度保持为10，并通过将同时通信对的数量从5更改为80来改变使用流量。在图17（a）中，我们看到，在不使用DCQCN的情况下，5个通信对的用户流量的性能与使用DCQCN时80个通信对的用户流量的性能相匹配。换句话说，使用DCQCN，我们可以处理16倍以上的用户流量，而不会降低性能。图17（b）显示，即使使用DCQCN，磁盘恢复流量的性能也比不使用DCQCN时更加均匀和公平。

PFC的需求和缓冲区阈值的重要性：我们现在演示PFC的需求，以及配置正确缓冲区阈值的需要。为此，我们使用另外两种设置重复图16的实验。首先，我们完全禁用PFC，尽管我们使用DCQCN。其次，我们启用PFC，但故意“错误配置”缓冲区阈值，如下所示：即我们不使用动态t_{PFC}，而是使用静态上限，即t_{PFC}=24.47KB，并设置t_{ECN}=120KB，即该值的五倍。有了这些阈值，就不再保证在PFC之前触发ECN。

图18显示了8:1 incast情况下的实验结果。除了上面讨论的两种配置外，我们还显示了DCQCN和No DCQCN（即仅PFC），它们是从图16（b）和16（d）复制的。

考虑PFC完全禁用时的性能。回想一下，DCQCN没有慢启动，因此它依赖PFC来防止拥塞期间的数据包丢失。如果没有PFC，数据包丢失是常见的，这会导致性能不佳。事实上，第10个百分位incast吞吐量为零——这表明一些流根本无法从持续的数据包丢失中恢复。这一结果强调了在DCQCN中使用PFC的必要性。

接下来，考虑启用PFC时的性能，但是缓冲阈值被错误配置。有了这些阈值，可以在ECN之前触发PFC，从而阻止DCQCN的全部好处。我们看到情况确实如此。用户流量和incast流量的尾部吞吐量都比没有DCQCN的情况好（即仅使用PFC），但比使用DCQCN的情况差。此结果强调了需要正确的缓冲区阈值设置。

6.3 对延迟的影响

上述基准使用吞吐量作为主要指标。然而，与DCTCP相比，DCQCN还可以减少延迟。作为一个微基准，我们在20:1 incast期间查看了拥塞端口的出口队列的队列长度，包括DCTCP和DCQCN。对于DCTCP，我们根据原文中提供的准则配置了160kb的ECN阈值。DCQCN的配置如前所述。

在这种设置下，使用DCQCN的队列长度明显短于使用DCTCP的队列长度（图19）。例如，使用DCQCN时，第95百分位队列长度为76.6KB，使用DCTCP时为162.9KB。这些数字与DCQCN流体模型和DCTCP模型一致。DCTCP会导致更长的队列，因为DCTCP需要更大的ECN阈值来吸收数据包突发，这是操作系统和NIC之间交互的结果。DCQCN使用硬件速率限制器，因此可以使用较浅的Kmin。

7. 讨论

多瓶颈场景：我们前面提到过，在多瓶颈场景中，更快的计时器和RED标记的组合比单独使用更快的计时器提供更好的性能。现在我们来说明这一点。多瓶颈问题也称为停车场场景。图20（a）中显示了一个示例。有三个流：f1:H1->R1、f2:H2->R2和f3:H3->R2。考虑当ECMP将f1和f2映射到与T1相同的上行链路的情况。通过这种映射，f2最终有两个瓶颈（T1上行链路和T4->R2），而f1和f3各只有一个瓶颈。Max-min公平性要求每个流的吞吐量为20Gbps。然而，在DCTCP等常见的拥塞控制协议中，双瓶颈流由于获得拥塞信号的概率较大，吞吐量较低。DCQCN，如果与DCTCP-like的“截止”标记一起使用（Kmin=Kmax；Pmax=1，见图5）也有同样的问题。使用不太突兀的RED标记方案（见表14中的参数）可以缓解（但不能完全解决）该问题。

直觉和前面解释的一样：CNP的生成是由一个计时器驱动的，因此使用类似RED的包标记，我们增加了更快的流获得更多CNP的概率。图20（b）显示了两种标记方案的性能，并表明直觉是正确的。我们计划扩展流体模型，以更好地理解该场景，并提出更具体的解决方案。

数据包丢失：PFC防止由于缓冲区溢出导致的数据包丢失。然而，在大型网络中，数据包损坏、间歇性端口故障或意外的交换机或服务器配置错误都会导致数据包丢失。与TCP传输层不同，RoCEv2传输层假设数据包丢失很少。例如，当使用读取操作时，协议不向数据发送方提供有关数据包是否正确接收的信息。接收端可以通过中断序列号检测数据包丢失，并且必须启动任何丢包恢复。ConnectX-3 Pro实现了一个简单的go-back-N丢包恢复方案。这对于数据包丢失率较低的环境就足够了，如图21所示。一旦数据包丢失率超过0.1%，吞吐量就会迅速下降。对于go-back-N丢包恢复模型，消息的大小也很重要。在我们的部署中，大多数消息传输的大小预计将小于4MB。

死锁：一个常见的担忧是使用暂停可能导致路由死锁。死锁形成需要一组对彼此的缓冲区具有循环依赖性的流。在Clos结构的网络中，服务器仅连接到TOR，一对服务器之间的通信永远不会通过另一台服务器或两个以上的TOR。因此，如果设备没有故障或配置错误，就不会产生循环缓冲区依赖关系。由于篇幅不够，我们省略了详细的证明。我们目前正在研究如何避免故障卡（例如端口或喷出PFC的NIC）可能导致的停机。

TCP友好性：TCP友好性不是DCQCN的设计目标之一，因此我们在本文中没有尝试研究TCP和DCQCN之间的交互。使用802.3优先级标记可以很容易地在交换机级别将TCP和DCQCN流量彼此隔离，并对每种类型的流量强制执行不同的传输优先级、交换机缓冲区利用率限制和速率限制。

增量部署：在数据中心环境中，增量部署不是一个问题。

大规模评估：我们设计了用于部署在大型数据中心网络中的DCQCN。本文中的评估基于一个小型、受控的测试平台环境。我们还通过大规模仿真（由800多台机器组成的三层网络）评估了DCQCN。由于缺乏空间，我们省略了模拟结果，也因为它们与试验台评估的结果相似。我们的数据中心正在全面部署DCQCN。

8. 结论和今后的工作。

拥塞控制算法的历史就是在响应性和稳定性之间斗争的历史。虽然我们已经将DCQCN作为解决PFC问题的解决方案，但它也代表了一种解决响应性和稳定性之间矛盾的新方法，至少在数据中心环境中是这样。DCQCN使用朴素而快速的PFC流控制来及时防止数据包丢失，并使用细粒度且较慢的端到端拥塞控制来调整发送速率以避免持续触发PFC。这种组合使DCQCN在短期内具有响应性，在长期内保持稳定。我们相信，这一设计点值得在多个不同方向进行探索。例如，我们正在探索在其他具有不同RTT和链路带宽的环境中使用DCQCN。更具体地说，我们正在为100和400Gbps网络建模和调整DCQCN和PFC。我们还计划使用第5节中描述的模型研究DCQCN算法的稳定性。

参考文献：Zhu, Y., Eran, H., Firestone, D., Guo, C., Lipshteyn, M., Liron, Y., Padhye, J., Raindel, S., Yahia, M.H., & Zhang, M. (2015). Congestion Control for Large-Scale RDMA Deployments.SIGCOMM 2015.