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

【NSDI 2020】来自清华的大手笔！PCN试图重构无损以太网中的拥塞管理

NSDI
2022-10-18
1817
更新：2023-01-04 21:42:07

# **摘要**

无损以太网在数据中心和集群系统中有着广泛的应用前景，但其存在的各种性能问题，如不公平性、头阻(head-of-line blocking)和拥塞扩散等，阻碍了其在生产系统中的大规模部署。通过细粒度的实验观察，作者检视了流量控制和拥塞控制之间的相互作用，并意识到性能问题的根本原因是无损以太网拥塞管理体系结构中的无效因素，包括拥塞检测机制的不合理和速率调整规律的不完善。

受这些在实验研究中获得的见解和发现的启发，作者修改了拥塞管理体系结构，并提出了PCN(Photonic Congestion Notification)方案，该方案由两个基本组件组成：（i）一种新的拥塞检测和识别机制，用于识别哪些流是造成拥塞的真正原因; (ii）接收端驱动的速率调整方法，以在短至1个RTT的时间内缓解拥塞。作者使用DPDK NIC实现PCN，并使用试验台实验和仿真进行评估。结果表明，PCN在并发突发负载下显著提高了性能，在实际负载下显著降低了PFC暂停消息，缩短了流完成时间。

# **引言**

近年来，在数据中心和集群计算系统中，无损网络已经成为一种有吸引力的趋势。一般来说，由数据包丢失引起的重传很容易导致吞吐量减少、完成时间增加，甚至错过应用程序截止日期。此外，通过数据中心扩展传输协议（如远程直接内存访问（RDMA）和光纤通道（FC））需要可靠传输，而不会因网络拥塞而导致数据包丢失。

无损InfiniBand（IB）在HPC（High performance Computing，高性能计算）集群系统中非常流行，但是现代的数据中心已经用IP/以太网技术建立起来，这些技术在传统互联网中也占主导地位。数据中心运营商和云建设者可能会使用一些IB，但远没有以太网那么普遍。此外，他们不愿意在同一个数据中心内同时部署和管理两个独立的网络。IEEE DCB（数据中心桥接）作为以太网的增强功能自然具有吸引力，它使以太网成为一种统一的交换结构（switching fabric），可以取代传统的分离结构用于特殊目的，例如用于存储的FC、用于HPC的IPC（进程间通信）和用于LAN通信的以太网。与维护单独的交换结构相比，**聚合以太网**具有显著的性能、成本和管理优势。为了实现统一以太网的无损语义，在链路层开发了逐跳流量控制PFC（基于优先级的流量控制）和端到端拥塞控制QCN（量化拥塞通知），以增强传统以太网。可扩展的无损以太网交换结构无疑是构建未来数据中心的潜在候选者之一，以适应有前景的应用，如聚合以太网上的RDMA（RoCE）、结构上的NVMe（NVMe Over Fabrics）和资源分解（resource disaggregation）等。

在过去的十年中，各种在线数据密集型（OLDI，Online Data-Intensive）应用和虚拟化服务的兴起产生了越来越多样化的流量模式和特定特征，例如，incast、burst和大小流混合（mixed of mice/elephant flow）等。由于目前还不清楚无损以太网能否在具有如此复杂流量的大规模数据中心中有效工作，因此作者进行了实证和实验研究，以深入了解无损以太网中的拥塞管理（CM）体系结构。详细的观察和联合分析揭示了一些性能问题的根本原因，如拥塞扩散和易受突发流量的影响。基于这些见解，作者重新构建了无损以太网中的CM。主要结论和主要贡献总结如下。

<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: 微软雅黑;">揭示了现有无损以太网CM体系结构中的不足之处，包括：a）拥塞检测机制无法准确识别拥塞或未拥塞的流（当它们在同一队列中时），因此不太可能通知不同的源进行区分性速率调整。b）基于缓慢演化的端到端拥塞控制速率调整与逐跳流量控制的快速操作不匹配。
</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: 微软雅黑;">开发了一种新的CM方案，称为PCN，其中包括：a）一种微妙的拥塞检测和识别机制，该机制能够区分真实的拥塞流，以便对拥塞流或未拥塞流进行适当的速率调整，即使它们在同一累积队列中。b）提出了一种接收端驱动的速率调整规则，该规则能加快速率调整的收敛速度，对突发业务具有较强的鲁棒性和对链路容量的适应性。
</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: 微软雅黑;">使用DPDK NIC实施PCN，并使用试验台实验和ns-3仿真进行评估。在大规模网络中的大量仿真结果表明，PCN对PFC暂停的抑制率分别比QCN、DCQCN和TIMELY分别提高了12%、47%和90%，延迟降低了10倍、11.3倍和13.2倍。
</span>

# **背景**

## **数据中心的流量特性**

数据中心中的各种应用程序生成具有广泛流量模式和分布的流。例如，web搜索服务通常会生成短流和突发流。另一方面，日志文件处理引入了少量但寿命较长的流来传输大量数据。对许多运营数据中心的流量进行的调查显示了有分布广泛的各种流量模式。流的大小可能从0.05KB到超过100MB，分布非常分散。在所有的流量中，老鼠流（小流）在接收到任何ACK之前就完成了所有数据包的发送，不能通过端到端拥塞控制方案进行调整。此外，许多测量表明，老鼠流的发生不仅频繁，而且具有突发性。老鼠流（小流）的高度动态地进入/离开将极大地影响交换机中的队列长度，进而影响端到端延迟。这些流虽然不响应拥塞控制方案，但严重干扰了数据中心或集群系统交换结构拥塞管理的正常工作。

## **无损以太网中的拥塞管理**

在这种不同的业务模式下，为了保证网络的无损性和提供满意的任务完成时间，拥塞管理成为无损以太网的关键和挑战。IEEE DCB提出了一个由端到端拥塞控制和逐跳流量控制两个基本功能组成的CM框架。

端到端拥塞控制根据测量变量（如交换机队列长度或RTT）所反映的拥塞信息，主动调节数据远端的发送速率。代表性的解决方案包括IEEE 802.1 Qau开发的QCN、三层方案DCQCN和基于RTT的方案TIMELY。虽然这些协议可以限制交换队列的长度，从而降低丢包率，但并不能保证零丢包。实际上，在信源意识到网络拥塞之前，不可控突发可能已经导致丢包，特别是当拥塞控制环路时延较大或突发的并发度较大时。更糟糕的是，大量的拥塞控制机制以线速率启动流以加速小流的完成，加剧了丢包问题。

为了避免由于不可控突发而导致的数据包丢失，IEEE 802.1 Qbb定义了基于优先级的流量控制（PFC）来保证无损性。使用PFC，当入口队列长度超过某个阈值时，交换机向其上游设备（交换机或NIC）发送暂停帧以停止传输。当队列耗尽到另一个阈值以下时，发送恢复帧。虽然PFC可以保证由于网络拥塞造成的零丢包，但它会导致一些性能问题，如头阻(head-of-line blocking，HLB)、不公平甚至死锁。当PFC不断触发时，局部拥塞会扩散回拥塞源和非拥塞源，严重影响网络吞吐量和流完成时间。这些性能问题的根本解决方案是通过端到端的拥塞控制方案消除持久的拥塞，这样PFC就不会不断触发。

总的来说，端到端拥塞控制需要PFC来防止不可控突发的瞬时拥塞造成的丢包，PFC还需要端到端拥塞控制来消除持久拥塞。也就是说，在无损以太网中，端到端拥塞控制和逐跳无损流量控制是相辅相成的。

# **实验观察和见解**

## **观察结果**

虽然端到端拥塞控制和逐跳流量控制在不同的业务模式下都能独立地实现各自的目标，但它们之间的相互作用会引起意想不到的问题。(1)当突发短流进入网络时，网络中的现有流仍然会受到PFC相关的副作用，即拥塞扩散和不公平；(2)突发离开网络后，拥塞控制不能及时有效地重新分配可用带宽。

现有的大部分工作主要关注无损以太网CM中的单个元素（如拥塞控制）或特殊症状（如HLB，死锁），但在不自觉的情况下忽略了拥塞控制和流量控制在不同流量模式下的相互作用，因此，可能会屏蔽上述性能问题的根本原因。随后，我们首先进行细致、精细粒度、多变量的观察，进而推断出特殊症状和问题的根源。

具体来说，我们定义了一个紧凑而典型的网络场景，它不能太复杂从而妨碍我们掌握无损以太网CM中关键元素和核心机制的基本原理。同时，它应具有足够的共同特征，以确保所得到的结论和见解不失一般性。如图1所示，我们选择了数据中心典型网络拓扑的一个基本单元，如CLOS和Fat Tree]，其中16个发送方和2个接收方通过两个交换机连接。所有链路均为40Gbps，传播延迟为5us。流量是长流（long-lived flow）和并发突发流的混合。具体而言，H0和H1分别启动到R0和R1的长流。假设F0和F1在模拟开始时实现了从交换机S0到S1的40Gbps瓶颈链路的公平带宽分配。在时间0，H2~H15的每个发送者以线速率（即40Gbps）同时向R1生成16个短流，每个流的大小为64KB。因为每个短流的流量只有12.8秒us（<1个RTT），它不受端到端拥塞控制机制的控制。这些不可控制的burst流总共持续了3毫秒左右。我们使用ns-3进行了仿真，研究了各种CM方案，包括PFC、PFC+QCN、PFC+DCQCN和PFC+QCN。所有参数均设置为相关标准和文献推荐的默认值。结果如图2所示。

<center>Figure 2: Interactions between PFC and existing congestion controls. 
</center>

当单独使用PFC时，输入端口P1/S1暂停其上游端口P0/S0以避免丢包，并且端口P2/S1被并发突发流阻塞。随后，“暂停”操作随着长流向上游蔓延，H0和H1最终都暂停。我们测量暂停速率（即发送暂停消息的速率）和瞬时吞吐量。如图2（a）所示，拥塞树从S1开始，蔓延到H0和H1，出现并持续3.1ms（>100RTT），直到burst的小流结束。在这个过程中，拥塞流F1和未拥塞流F0都面临巨大的吞吐量损失，如图2（b）所示，无论它们是否是P2/S1端口真正拥塞的原因。

当QCN、DCQCN或TIMELY与PFC联合工作时，拥塞树仍然出现，如图2（a）所示。但其持续时间缩短为0.5ms(约17RTT），1.8ms(约57RTT）和1.4ms(约47RTT）。令人惊讶的是，当并发突发流和拥塞树消失后，两个长流F0和F1可能无法快速恢复到其初始吞吐量。如图2（b）所示，即使并发突发流仅持续3ms，QCN、DCQCN和TIMELY的吞吐量损失意外地分别持续12.5ms、25ms和60ms。总的来说，在这种情况下，PFC+QCN、PFC+DCQCN和PFC+TIMELY的性能比PFC差。

## 交互问题

为了理解拥塞树的长持续时间和意外的大吞吐量损失，我们详细分析了流的动态行为，揭示了逐跳流控制和端到端拥塞控制之间的相互作用问题。我们相信，通过对交互行为的仔细分析和严格推理，我们可以从现有工作中发现各种性能问题的根源。

1）**PFC混淆了拥塞检测**。在上述实验中，理想的端到端拥塞控制方案应该只将F1限制在2.5Gbps，并将S0到S1的瓶颈链路剩余带宽（37.5Gbps）分配给F0。然而，即使采用现有的拥塞控制（QCN、DCQCN和TIMELY），也无法实现这种理想的带宽分配。为了探索这种现象的原因，我们记录了端到端拥塞控制所调节的发送速率以及未阻塞流F0和阻塞流F1的实际发送速率。结果如图3（a）所示。当拥塞树存在时，端口P0/S0处的队列长度和RTT都会增加。由于发送方根据反馈信息（即队列长度或RTT）推断拥塞，F0也被认为是拥塞的。因此，F0的发送速率被QCN、DCQCN和TIMELY降低，即使它对P2/S1处的实际拥塞点没有贡献。因此，在拥塞树消失后（如图3（a）中的虚线所示），F0的发送速率非常低，尽管它没有受到PFC的附带损害。

总之，拥塞控制需要一些时间来消除拥塞树。在这个过渡过程中，PFC引起的拥塞扩散导致的较大的队列长度和RTT将误导拥塞控制去降低受害流的发送速率（本例中为F0）。

2）基于缓慢演化的端到端拥塞控制的速率调整与PFC的快速逐跳操作不匹配。图3还揭示了为什么拥塞树仍然被创建并持续几十个RTT，其中包括QCN、DCQCN和TIMELY。虽然当并发突发老鼠流（小流）进入时，F0和F1立即被限制（*throttled*），但QCN、DCQCN和TIMELY需要很长时间才能降低发送速率（图3中标记了不同拥塞控制的调节时间）。然而，PFC是逐跳工作的，因此拥塞传播非常快。在F0和F1的速率下降过程中，PFC不断触发。因此F0和F1的实际发送速率主要由PFC决定，而不是端到端拥塞控制，因此导致F0和F1的吞吐量都很小。这就是为什么即使采用了端到端的拥塞控制，拥塞树仍然会蔓延扩展。

这是由于端到端拥塞控制中基于缓慢进化的速率调整与逐跳流控制的快速操作之间的不匹配造成的。更具体地说，当可用带宽由于并发突发老鼠流（小流）而突然减少时，端到端拥塞控制方案不知道目标速率，因此只在当前发送速率的基础上一步一步地降低速率，每个更新周期最多50%。此外，QCN更新周期约为20us（传输100包的时间），DCQCN需要50us和TIMELY至少12.5us（发送64KB段的时间）。另外，当F0和F1的吞吐量很小时，DCQCN可能在一个更新周期内接收不到一个数据包，导致发送速率会自动增加。其结果是，可能需要数十个更新周期来降低F1的速率以接近剩余的可用带宽，如图3所示。

3）速率的提高不适应动态网络条件。当并发突发流消失，拥塞树消失后，F0和F1的发送速率都受到限制，需要逐步提高。QCN和DCQCN以二进制搜索（binary-search）的方式将发送速率提高到以先前存储的速率降低时的目标速率，并周期性地以预先配置的值线性地提高目标速率。TIMELY在每个更新周期中添加固定值的发送速率。简而言之，所有的增速方法都是线性的。因此，当受到并发突发流干扰后，它们不能立即充分利用可用带宽。这就是为什么流F0和F1需要更长的时间才能恢复到图2（b）所示的最大吞吐量。此外，每个更新周期的速率增长步长需要根据网络带宽进行自适应配置。例如，针对40Gbps链路的QCN、DCQCN和TIMELY调整的参数对于100Gbps链路可能过于保守，但是对于1Gbps链路可能过于激进。参数的调整在实践中会变得困难。

# **设计原则**

上述性能问题的根本原因是现有的端到端拥塞控制方案不能很好地与逐跳流控制相结合。为了解决这些问题，我们重新讨论了CM的体系结构。我们首先讨论了现有拥塞管理中的哪些元素引入了这些性能问题，然后提出了通过重新设计无损以太网的CM来克服这些不一致性的方法。简而言之，设计原则有三个方面。

1、由于现有的拥塞管理无法识别真正的拥塞流，因此未阻塞流成为受害者。PFC的运行会对拥塞产生反压，污染当前的拥塞信号（即队列长度和RTT）。我们需要找到一种新的机制来正确区分哪些流量是造成拥堵的真正原因。

2、 拥塞扩散是由基于进化的慢速降速机制引起的，因此快速准确的降速方案是必不可少的。

3、 当突发业务消失时，长流主要依靠线性速率增长来共享释放的带宽，导致收敛缓慢和带宽浪费。因此，应建立一个快速的加速机制。

## **拥塞检测和识别**

传统的端到端拥塞控制是基于交换机队列长度和RTT等测量来检测网络拥塞的。然而，这种拥塞检测机制在无损以太网中被PFC所混淆。我们需要修改拥塞检测和识别机制来避免这种混淆，然后正确地识别哪些流是真正拥塞的。

**检测拥塞**

为了帮助检测拥塞，我们将交换机的出端口分为以下三种状态。

<center> Figure 4: Different states of egress port.
</center>

**真正拥塞**：真正拥塞中的端口充分利用了出口链路，多余的进入数据包在缓冲区中积累，如图4（a）所示。例如，在先前的模拟中，当并发突发老鼠流（小流）开始时，端口P2/S1处于实际拥塞状态。

**无拥塞**：如图4（b）所示，没有数据包在出口端口的缓冲区中累积，因此，进入的数据包被立即发送。也就是说，出口链路正常工作，利用率低于100%。上述模拟中的P3/S1端口始终处于非拥塞状态。

**准拥塞**：准拥塞中的端口也保持一定的队列长度，但由于暂停和恢复，相关的出口链路没有得到充分利用，如图4（c）所示。因此，数据包的传入速率是否超过链路容量是未知的。例如，在前面的模拟中，面对PFC触发器，端口P0/S0变成了准拥塞。然而，由于通过该端口的流将遭受较大的队列长度和延迟，现有拥塞控制（如QCN、DCQCN和TIMELY）中的拥塞检测机制会武断地判断这些流经历了拥塞。

因此，为了区分出口端口的不同状态，特别是准拥塞状态，在检测拥塞时应考虑PFC的影响。

**识别拥塞流量**

由于PFC的影响，拥塞流和非拥塞流中的数据包都可能由于出端口被其下游入端口暂停而积压在出端口的相同队列中。因此，根据出端口的队列长度来预测潜在的拥塞可能是正确的，但是像QCN和DCQCN那样做出拥塞判断并向所有流源提供不加选择的信息是不明智的。仅仅通过测量RTT及其变化，TIMELY也很难区分流量是否真正穿越了真正的拥挤端口。

为了避免现有CM体系结构中拥塞信息的混乱，干扰流量控制和拥塞控制之间的正常交互，甚至导致相互破坏，我们在重构无损以太网CM体系结构时提倡解耦拥塞检测和拥塞识别功能。交换机负责检测拥塞，并通过监控相关网络状态提供拥塞信号。终端系统综合相关信息判断拥塞，并判断其流是否真的拥塞。

## 接收端驱动的减速

理想的拥塞控制方案应该直接将拥塞的流量控制在一个合适的速率上。为了达到这个目标，我们首先需要获得这个合适的速率。在无损以太网中，合适的速率不应触发PFC，但仍能保持较高的吞吐量。为了找到这个速率，我们应该回答以下两个子问题：1）拥塞流不损失吞吐量的最小速率是多少？2）拥塞流量不触发PFC的最大速率是多少？

第一个答案是直观的。它应该是接收端的到达率。我们把它定义为接收速率。一方面，拥塞流的路径中必须至少有一个真正的拥塞端口，因此所有流的接收速率之和正好达到瓶颈链路的容量。另一方面，如果拥塞流将速率降低到小于其接收速率，则瓶颈链路上必须存在空闲带宽，这意味着该流实际上可以发送更多数据。因此，接收速率是拥塞流不损失吞吐量的最小速率。在最近的设计中，如Fast TCP、NDP和Homa，也引入了接收速率的能力。在检测到拥塞时，它们都利用接收速率来实现快速收敛。

幸运的是，接收率也是第二个子问题的答案。也就是说，当发送速率不超过接收速率时，拥塞流的分组（报文，数据包）不会在拥塞交换机的入口端口累积，继而PFC不会被触发。而且，无论同一交换机的出口是否拥塞，都会出现这种现象。

<center>Figure 5: Relationship of PAUSE and receiving rate.
</center>

为了生动地说明这一现象，我们在前面的“观察结果”环节中给出的网络场景中重复进行了一些实验. 我们开始时让H2~H4以线路速率模拟不可控的burst。拥塞无关流F0和拥塞相关流F1都由速率限制器控制。F0的发送速率固定在其公平分配（即20Gbps）的速率上，F1的发送速率从20Gbps逐步变化到0。当仿真运行时，两个流都被它们的固定速率限制器和PFC限制。在速率限制器中设置的发送速率和这两个长流在接收端的接收速率，以及入口端口P1/S1上暂停帧的生成速率，如图5所示。显然，当拥塞相关流F1的发送速率超过9.5Gbps时，其接收速率仅为9.5Gbps。同时，入口端口P1/S1产生持续的PFC暂停，并且拥塞无关流F0被附带地损害。相反，当F1的发送速率不超过9.5Gbps时，P1/S1端口不产生暂停帧，拥塞无关流F0可以达到预期的吞吐量。该实验表明，将拥塞流限制在其接收速率上，可以防止相关出口上出现更多PFC触发器，从而抑制拥塞树分支中的拥塞扩散。

因此，我们得到了一个有价值的观点，那就是将拥塞流的速率直接降低到它们的接收速率。它启发我们设计一个接收端驱动的速率降低算法，以便在无损以太网中与PFC协调工作，这将在下面详细阐述。

## 从温和到激进的增速

速率的提高应该能加速非拥塞流的速率，以快速共享可用带宽，同时保持稳定的充分利用率。非阻塞流的速率增长规律在两种情况下确实需要。

1） 流刚刚从阻塞状态转为不阻塞状态。根据我们的接收端驱动速率降低原理，流量已经降低到其接收速率，这意味着没有PFC触发和吞吐量损失。因此，流量增加的空间很小。因此，应缓慢增加流速。

2） 流在几个连续的更新周期内一直保持在非阻塞状态。在这种情况下，流可以更积极地增加以占用可用带宽。由于我们的接收端驱动的速率降低规则可以大幅减少过载流量（overflowed traffic），因此可以更积极地设计速率增加机制来快速填满网络带宽。

因此，我们得到一个建议，即先缓慢地增加非阻塞流的速率，然后再积极地增加非阻塞流的速率。它指导我们设计一种从温和到激进的速率增长算法，既能保证稳定性又能快速收敛。

# **PCN设计框架**

基于上节提到的设计原则，在本节将重新构建无损以太网的拥塞管理机制，提出了PCN（Photonic Congestion Notification）方案。PCN是一种基于速率的端到端拥塞控制机制，可以与PFC协同工作。如图6所示，PCN由三部分组成：反应点（RP，也就是发送端）、拥塞点（CP，也就是中间交换机）和通知点（NP，也就是接收端）。通常，CP总是指拥塞的交换机，它使用非暂停ECN（NP-ECN）方法来标记通过的分组，以检测出口端口是否处于实际拥塞状态。注意，标记为NP-ECN的数据包并不一定意味着遇到拥塞，它需要NP做出最终决定。NP，即接收方，识别拥塞流，计算其接收速率，并周期性地向RP发送拥塞通知包（CNP）。RP始终是发送方的NIC，它根据CNP中的信息调整每个流的发送速率。下面会详细介绍了PCN的各个部分。

## CP算法

我们设计了NP-ECN方法来检测拥塞并产生拥塞信号。CP算法遵循图7中的状态机。假设当交换机的一个出口从其下游节点接收到恢复帧时，相关的等待队列中有N个数据包。NP-ECN将设置其计数器PN=N。然后端口重新启动以传输数据包。每次发送一个数据包时，计数器将递减一，直到所有N个暂停的数据包都已发送。对于这N个数据包，它们不会被标记。对于以后没有暂停的包，相应的PN=0，交换机会按照传统的方法用ECN标记，阈值为零。

这样，真正拥塞的出端口**中的所有数据包都将被标记为ECN。相反，在**非拥塞端口**中，数据包从不被标记为ECN。对于**准拥塞端口**，已经被暂停过的数据包不使用ECN标记。同时，当入端口队列不为空时，到达和离开处于恢复状态的端口的数据包被标记为ECN，即**准****拥塞*****\*端口中的数据包被部分标记为\**\**ECN\****。在PCN中，CP只用于在包上标记拥塞信号，并让NP节点最终确定流是否拥塞。

值得注意的是，NP-ECN机制可以在同时具备ECN和暂停功能的商用交换机上轻松实现。与传统的商品交换中的ECN方法相比，PCN的NP-ECN方法要求每个端口增加一个计数器和多条逻辑线。修正的空间和计算复杂度均为O(1)。

## NP算法

NP的功能包括识别拥塞流、估计接收速率和定期发送拥塞通知包（CNP）。T表示CNP生成周期。

**识别拥塞流**：NP基于NP-ECN机制标记的ECN信号识别拥塞流。如果在CNP生成周期T中接收到的95%的包被标记为ECN，则认为该流是拥塞流。通过经验设置95%的值来滤除实际中的一些微小干扰，如队列振荡和优先级调度，使得真正拥塞流中的一个或多个数据包不太可能被ECN标记。

**估计接收速率**：直接用T去除以到达的数据包的总大小来计算接收速率。值得注意的是，流的接收速率可能非常小，以至于在几个CNP生成周期中只有一个分组到达。为了解决这种特殊情况，PCN还记录了数据包在NP的到达时间间隔。当到达间隔时间大于T时，NP通过用到达间隔时间代替T来估计接收速率。

**生成CNP**：NP按周期T发送CNP来通知发送端接收速率，T被设置为50us，类似于DCQCN。此外，当流量需要降低或增加时，PCN显式地生成CNP，这与DCQCN只生成CNP来通知速率降低不同。并且当在周期T中没有接收到其分组时，不生成CNP。具体来说，CNP包的格式与RoCEv2中的CNP包兼容，如图9所示。CNP封装的主要信息包括IPv4/IPv6报头中的1位ECN和保留段中的32位RecRate，其承载归一化为1Mbps（粒度）的接收速率。图8总结了NP算法的状态机。

## RP算法

算法1描述了RP如何根据CNP中的信息调整发送速率的伪码（伪流程）。一开始，流量以线速开始，以改善短流的流完成时间（FCT）。

**速率降低**：当RP接收到带有ECN标记的CNP时，它会按照第6行中的规则进行减速，而不是直接将发送速率重置为接收速率，如前面“接收端驱动的减速”中所述，对接收速率设置了一点小折扣 ，这样可以排出交换机中的累积队列。相应的，在排空累计队列期间，接收速率可能大于发送速率，按照第6行的规则该发送速率应不增加。

**速率增加**：当RP接收到一个没有ECN标记的CNP时，它会按照第10行和第11行的规则进行速率调整。具体来说，RP通过计算其当前值和线速的加权平均值来增加发送速率。这个速率增加规则在多个方面都是有效的。

（1） 由于始终保持在当前发送速率和线路速率之间，因此可以达到理想的发送速率。

（2） 由于所有流的 值都是相同的，因此慢流比快流增加得更大，这有利于公平性。

（3） 权重w自动从最小值 变为最大值 ，这样PCN可以实现如”从温和到激进的增速”节中所讨论的从温和到积极的速率增加方式. 例如，当 、 和无ECN标记的CNP被相继接收时， 和从0到线路速率的发送速率的演变如图10所示。在前5个CNP中，发送速率增长不超过线路速率的10%，但在仅15个CNP之后，发送速率增长到线路速率的95%。

<center>Figure 10: Evolution of w and rate when a sender receives continuous CNP notifying rate increase.
</center>

（4） 为了适应从1Gbps到400Gbps的链路容量升级，不需要任何参数配置。

## **讨论**

如前文中所述，当前无损以太网性能问题的主要根源是PFC和端到端拥塞控制方案之间的不恰当交互。我们证明了PCN以最小的实现成本解决了无损以太网的核心问题。

**实现要求**：为了实现PCN，需要对交换机进行一些修改。与传统的商品交换机ECN方法相比，PCN的NP-ECN方法（见图7）只需要每个端口多出一个计数器，多出几行逻辑。修正的空间和计算复杂度均为O(1)。

**优点**：为了展示PCN的优势，我们使能了PCN并重复像前面章节中描述的那样的模拟实验，其结果也分别插入图2和图3。从图2(a)的结果可以看出，S0->H0和S0->H1链路中的暂停都被完全避免了，S1->S0链路中只短暂出现了少量的暂停，但拥塞扩散被迅速抑制，没有生成拥塞树。

图3的结果证实了PCN可以帮助未阻塞的流快速地获取空闲带宽，并正确及时地将阻塞流调节到合适的速率。PCN增加F0的速率以在并发突发期间充分利用网络带宽。在并发突发消失之后，F0和F1公平地共享带宽，而不浪费网络资源或触发PFC暂停，如图2（b）所示。

# **结论**

本文重新构建了无损以太网的拥塞管理，通过两个巧妙的设计，提出了适用于无损以太网的PCN框架：(i) 一种新的拥塞检测和识别机制，用于识别哪些流是造成拥塞的真正原因; (ii)接收端驱动的速率调整方案，以尽可能快地在一个环路控制轮（即一个RTT）中缓解拥塞。PCN只需稍加修改，就可以很容易地在商用交换机上实现。大量的实验和仿真结果表明，PCN极大地提高了性能，显著地减少了PFC暂停消息，减少了实际工作负载下的流完成时间。

**参考文献**：Cheng, Wenxue, et al. “Re-Architecting Congestion Management in Lossless Ethernet.” 17th {USENIX} Symposium on Networked Systems Design and Implementation ({NSDI} 20), 2020, pp. 19–36.

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

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