拥塞控制技术对于构建大规模无损以太网至关重要。清华、北邮和北航的几位研究人员在2024年NSDI《 Revisiting Congestion Control for Lossless Ethernet 》上从新颖视角出发，深入探讨并利用无损网络的内在特性，对传统拥塞控制问题进行了深入的思考，主要利用无损网络的数据包守恒特性为准确估计网络管道容量及过量数据包数量提供了重要线索。

摘要

文章进一步阐述了处理拥塞流与受害者流的策略，以有效解决队首阻塞问题。在此基础上文章提出了一种新颖的ACK驱动拥塞控制（ACC）机制，该机制巧妙地利用ACK时间序列信息，通过临时停止发送来精确清除拥塞流中的过量数据包，并将其发送速率与网络管道容量精准匹配。通过实验测试和大规模模拟分析，证实了ACC机制在提升无损以太网性能方面的优势，尤其是在降低延迟和提高吞吐量方面表现卓越。

引言

随着数据中心对远程直接内存访问（RDMA）技术的日益普及，无损网络的部署逐渐成为行业发展的趋势。无损以太网利用PFC（基于端口的流量控制）机制的流控功能有效避免了数据包的丢失。然而，持续性拥塞仍有可能导致头部阻塞（HoL）和死锁问题，从而凸显了端到端拥塞控制机制的重要性。现有的拥塞控制算法并未完全发挥无损网络的数据包守恒特性——即所有发送的数据包最终都将被确认。针对现有拥塞控制机制存在的不足，本文提出了一种新的ACK驱动拥塞控制（ACC）机制。该机制立足于数据包守恒原则和ACK驱动范式，通过精细调控拥塞流与受害者流，有效缓解了HoL阻塞的问题。ACC机制借助TCD（三态拥塞检测）技术来监测流的状态，对拥塞流执行暂停和速率匹配策略，同时根据拥塞的严重程度动态调整受害者流的发送速率，以此优化整体网络性能。

设计空间

理想属性

我们首先重新审视无损以太网拥塞控制的理想属性。

（1）快速收敛。拥塞控制的主要目标是为每个流分配适当的速率，从而使聚合速率收敛到瓶颈容量。然而，在无损以太网中，快速收敛对以下问题尤为关键： 限制拥塞的传播和缓解HoL阻塞。

降低死锁风险。

（2）低延迟和高吞吐量。今天的应用越来越多地追求严格的延迟和吞吐量性能。拥塞控制应该能够为短流实现低延迟，并为长流实现可预测的高吞吐量。

无损以太网中的三态流状态

最近的工作TCD开发了一种针对无损网络的三态拥塞信号，它可以区分交换机端口是拥塞树的根（即，拥塞端口）和仅仅是受PFC影响的分支上的交换机端口（即，不确定端口）。

原则

在本节中，我们旨在提出设计原则，以回答无损以太网拥塞控制的关键问题：

（1）如何调整拥塞流的速率以实现快速收敛？ （2）如何分别处理拥塞流和受害者流以处理HoL阻塞？

实验设置

为深入阐释上述原则，文中采用ns-3模拟工具进行了细致的实验分析。如图1(a)所示，构建了特定的网络拓扑结构。在模拟中，链路的传输容量设定为100Gbps，信号传播延迟固定在2微秒。F0和F1作为长期存在的数据流，H1至HN之间的节点发送了持续时间约2毫秒的64KB数据突发，由于其持续时间小于链路的带宽延迟乘积（BDP），这些突发难以通过传统的端到端拥塞控制机制进行有效调节。在本实验中选择DCQCN算法作为主机端的速率减少算法，并设定PFC的阈值为512KB。鉴于交换机内嵌了TCD功能，主机能够识别数据流的三种状态。具体实验场景设定为：F0和F1在实验开始时同步启动，并迅速实现了带宽的公平分配，随后触发了数据突发。在1毫秒后，端口P4处发生拥塞事件，导致F0在\u003cP4-S1\u003e分支上转变为受害者流。为了模拟不同程度的拥塞引入了变量N，代表并发发送节点的数量。当N值增大时，端口P4的拥塞程度加剧，从而形成了更深层的拥塞树结构。

ACK驱动的力量

为深入挖掘控制拥塞流的潜在机制，本文综合了网络内部的视角——如交换机内积压的拥塞数据包情况，以及主机端的视角——如发送方追踪的飞行字节状态，进行了细致的分析。以实验设置I（N = 20）为例，图2(a)展示了F1数据流在各个交换机端口的积压变化（上图）以及发送方H1所监控的飞行字节数量变化（下图）。观察图2(a)可以发现，飞行字节的总量与P4、P3、P2和P1端口处排队的数据包总数，以及F1数据流的网络管道容量之间存在着密切的关联。进一步从发送方的角度分析，图2(b)描绘了拥塞流F1在接收端R1的数据包到达模式和在S1处生成的确认应答（ACK）模式。研究发现，对于拥塞流，积压在交换机中的过量数据包数量恰好等于当前飞行数据包数与网络管道容量之差；同时，ACK的到达频率能够反映出当前可用的带宽情况。这些发现实际上验证了无损以太网的一个核心属性——数据包守恒原则，即所有发送的数据包均不会被丢失，而是会在交换机的分支缓冲区中积压，直至网络管道被填满并最终完成数据包的交付，随后由ACK进行确认。数据包守恒原则的深层含义表明，可以通过ACK的时间序列准确推断出拥塞流中过量数据包的具体数量以及网络管道的容量。基于此，ACK驱动的控制范式在无损网络中显示出其强大的效力。据此，我们得出了第一个核心原则：在无损以太网的背景下，ACK驱动的控制策略是确定适宜的调节速率和拥塞流过量数据包数量的有效工具。

处理HoL阻塞

一旦PFC生效，可能会出现受害者流，并遭受HoL阻塞。接下来的问题是如何处理拥塞流和受害者流以分别处理HoL阻塞。理想情况下，HoL阻塞应该尽快消除，而不是带来不必要的性能损失。

接下来，文中专注于不同拥塞程度下拥塞流的速率控制策略对HoL阻塞缓解和受害者流的影响（例如，N = 20和N = 10）。在交换机中启用TCD，因此通过带有UE标记的数据包识别的流被视为受害者流。默认的速率控制策略是，一旦检测到拥塞流，只有拥塞流会被限制，而受害者流将根据DCQCN调整发送速率，与未拥塞流相同。

图3(a)报告了当N = 20时，使用DCQCN在交换机端口P3的各个流的队列占用情况。我们注意到F0的队列积累与F1的队列增长同时发生，这证实了HoL阻塞源于拥塞流沿分支的队列积累。

从测试数据得出如下结论：长时间停止拥塞流可以尽快消除关联的缓冲区。然而，在不同的拥塞情况下，HoL阻塞仍可能发生，受害者流有引起进一步拥塞传播的风险。尽管停止拥塞流并不一定能阻止暂停帧影响受害者流，但它确实有助于尽快摆脱这种阻塞状态，只要拥塞流的累积缓冲区被充分排空。在这个过程中，受害者流可能会出现，并有拥塞传播的风险。因此，文中主张根据拥塞的严重程度动态处理受害者流，而不是同等对待。给出如下原则：长时间停止拥塞流是抑制HoL阻塞的首要手段。在拥塞流停止的同时，受害者流应该通过适应拥塞的严重程度来平衡HoL阻塞的缓解和吞吐量。

结合上述原则，文中为无损以太网中的拥塞流和受害者流提出了以下策略：拥塞流应首先停止，等待累积的拥塞队列排空，然后以网络管道容量的速率发送。而受害者流应尽量少牺牲吞吐量，并从HoL阻塞的缓解中受益。

ACK驱动的拥塞控制

遵循上述原则文中提出了ACK驱动拥塞控制（ACC）的设计。交换机支持TCD并在数据包中标记三态拥塞通知。带有CE标记的数据包表示通过拥塞端口的拥塞流。带有UE标记的数据包表示该流仅通过了受PFC影响的端口。如果既没有CE也没有UE标记（表示为NO），则流是未拥塞的。PFC基于入口队列长度触发。在当今的商业共享缓冲区交换机中，入口队列长度是一个计数器，当数据包进入入口并从出口出队时更新。

发送方在接收到ACK时复制TCD标记到相应的ACK中，并将ACK发回发送方。ACC进行ACK驱动的速率调整，包括根据ACK序列强制执行源停止，并参考ACK到达速率来指导拥塞流的速率减少。源停止状态涉及一个停止时间，该时间确保在避免链路未充分利用的同时，排空累积在网络中的数据包。对于受害者流，ACC根据ACK标记的持续时间模式自适应地调整速率。

状态机概览

ACC发送方每周期T（例如，基础RTT）进行一次速率调整决策。在每个周期T结束时，发送方根据TCD标记识别流的当前状态，并进行相应的速率调整。

图5展示了ACC发送方ACK驱动速率调整的状态机。TCD标记在每个T中按优先级顺序CE > UE > NO进行聚合。如果在周期T内收到带有CE标记的ACK，则流可能经历了拥塞。ACC发送方记录每个流的CE标记ACK的数量。如果在周期T内CE标记的分数超过阈值（例如，90%），则认为是稳定拥塞的流。如果没有收到带有CE标记的ACK，但收到了带有UE标记的ACK，则该流被视为经历未确定状态的受害者流。只有当既没有收到UE也没有收到CE标记时，流才被认为是未拥塞的。具体来说，当流被识别为拥塞时，它将首先进入源停止状态，在该状态下连接停止传输，并记录ACK到达率以供后续发送。离开源停止状态后，拥塞流以从ACK到达率导出的适当速率进行限制。对于未拥塞的流，发送方直接增加发送速率。对于受害者流，发送方根据UE标记的持续时间模式调整发送速率。

停止拥塞流

对于拥塞流，ACC引入了一个源停止状态，该状态在以适当速率发送之前主动停止了拥塞流的传输。源停止的关键是对停止时间的把控。适当的停止时间应确保在不利用链路的情况下排空累积的数据包。实际上，应该有足够的数据包填充网络管道，而不在交换机缓冲区中引起队列积压。具体来说，ACC发送方根据ACK序列的时间序列计算源停止状态的持续时间。

限制拥塞流

对于拥塞流，在离开源停止状态后，发送方利用ACK到达率指导速率减少。ACK到达率可以反映接收方的数据接收速率。聚合接收速率是瓶颈链路的容量。为了减少由于反向路径中的拥塞而造成的干扰，ACK以比数据包更高的优先级发送，以避免显著的排队延迟。

适应未确定流

如果在周期T内收到带有UE标记的ACK，则相应的流是未确定流（即受害者流）。ACC根据拥塞的严重程度自适应地处理受害者流。实际上，接收UE标记的持续时间可以指示拥塞的严重程度。如果拥塞不严重，ACC发送方将收到很少的UE标记，因为拥塞可能不会扩散，或者由于拥塞流的源停止，拥塞可以迅速被抑制。然而，如果拥塞严重，拥塞传播可能会持续很长时间，ACC发送方可能会观察到UE标记跨越多个周期。因此，在识别出受害者流后，ACC 发送方会持续观察UE标记的到达模式来调整发送速率。

具体来说，ACC发送方首先保持速率不变，然后根据连续出现UE标记的周期数减少发送速率。如下图算法1（第23-24行）所示，如果连续出现UE标记的周期数超过周期阈值Pthresh，受害者流将通过将当前速率减半来减少注入速率，以防止进一步的拥塞传播。这样，受害者流避免了盲目降低速率而损失吞吐量的副作用，但在拥塞传播持续时间长时有助于缓解HoL阻塞。

未拥塞流的速率增加

如果周期T内既没有收到带有CE也没有收到带有UE标记的ACK，则流未拥塞，应尝试增加发送速率。原则如下：

1. 未拥塞流的增加步长应考虑当前的发送速率。具有较小发送速率的流应增加更多，而具有较大发送速率的流应增加较少。

2. 速率增加过程应最初逐渐进行，以避免立即引起拥塞，而在认为可用带宽足够时则更为积极。

实现

在本节中，我们描述了使用SoftRoCE在Linux中实现ACC的方法，SoftRoCE是RDMA的软件实现，并且在以太网NIC上实现了RoCE NIC的功能。图8展示了带有我们ACC扩展的灰色阴影的内核SoftRoCE架构。ACC涉及三个主要模块的修改，如下所述。

评估

评估设置

我们搭建了一个由5台服务器和1个交换机构成的测试环境，用于评估ACC和DCQCN等拥塞控制方案。服务器配置包括AMD Ryzen 9 3950X CPU、64GB RAM和10GbE NIC，运行Ubuntu 20.04及Linux内核5.4.127。通过32×100Gbps的Tofino交换机连接，采用默认共享缓冲区设置，并在SoftRoCE中实现了ACC和DCQCN。在大规模模拟中，采用了320台服务器的胖树拓扑，服务器连接至ToR交换机的链路为100 Gbps，核心层和聚合层之间的链路为400 Gbps，链路延迟为1µs，交换机缓冲区大小设置为32MB，PFC和XOFF分别为默认和512KB。

测试环境

在SoftRoCE平台上实现了ACC和DCQCN，并进行了性能比较。测试环境中，RTT大约20µs，ACC和DCQCN的周期T均设置为50µs以匹配DCQCN的CNPs生成周期。在incast场景下，TCD的拥塞检测效果与ECN相当。SoftRoCE配置为对每个数据包生成ACK，以支持ACC的速率调整。实验结果显示，ACC在快速收敛和维持稳定性方面超越DCQCN。在拥塞发生时，DCQCN需要约0.5ms降低发送速率至10Gbps，并最终在18ms后达到公平速率分配。相对地，ACC能够迅速在一个周期内将速率调整至适当水平，即10Gbps，显著提高了响应速度和网络效率。

微基准测试

ACC在无损以太网性能上表现优异，尤其在收敛性、链路利用率和公平性方面。它有效控制拥塞和HoL阻塞，维持高链路利用率，实现公平速率分配。在100Gbps链路中，ACC相比DCQCN和TIMELY更快减少瓶颈队列，保持稳定。ACC还有效预防死锁，与HPCC相比，在模拟中未出现死锁，而DCQCN和TIMELY有死锁发生，证明了ACC在快速收敛和死锁预防上的优势。

大规模模拟

在大规模模拟中，评估了ACC机制的FCT性能，发现它在处理小型和中型流量时能显著降低延迟，特别是在Web Search工作负载下，相比DCQCN和TIMELY，ACC的平均FCT和P99FCT更佳，主要是因为ACC能快速根据ACK调整发送速率。与HPCC相比，ACC在小型流的FCT上实现了29%至40%的降低，这得益于其源停止策略。此外，ACC还减少了PFC PAUSE帧的生成，有效避免了HoL阻塞。与ACC w/o halt相比，ACC在小型流上的性能更优，证实了源停止策略的重要性。