当前位置：首页 > 流量控制 > 正文

Infiniband和RoCEv2中的队头阻塞/头阻问题分析

流量控制
2022-10-05
2123
更新：2022-10-05 15:01:55

> 本文分析了Infiniband和RoCEv2中的队头阻塞/头阻问题，两种协议头阻问题的根本原因都在于暂停机制（信用或者PFC）是按端口（和优先级）运行的，而不是按流量运行的。

## Infiniband队头拥塞分析
为了理解拥塞扩散问题，以及拥塞根因与拥塞受害者之间的关系，考虑下图的网络拥塞情况。假设交换机1上的端口A到E都在向端口G发送数据包，因此端口G正在以100%的发送能力接收数据。
![](https://ngdcn.com/zb_users/upload/2022/10/202210051441128616064.png)
还假设相邻交换机2上的端口F也在以总链路带宽的20%向交换机1上的端口G传输数据。因此端口F将传输数据包，直到两个交换机之间的交换机间链路上没有剩余的信用为止。

此时，G端口将拥堵，但不会产生有害的副作用，因为所有端口（A~F）都将以G端口能够达到的速度提供服务。

现在考虑交换机2上的端口X，它在20%的路径带宽上将分组发送到交换机1上的Y端口。端口G，其拥塞的根因不是从端口X到端口Y的路径中的任何地方（貌似互不相干）。在这种情况下，人们可能会认为，由于端口F只使用了交换机间链路带宽的20%，其余80%的链路带宽将可用于端口X，远远超过端口X的要求。然而，情况并非如此，因为端口F最终将消耗干净交换机2的所有链路信用，而端口X将不得不等待可用信用。

**拥塞控制进一步定义了端口可能遇到的两种拥塞。它可能是拥堵的“根本”原因，也可能是“受害者”。**

**如果一个端口有大量等待传输的数据包队列，并且该端口有可用的信用来发送数据包，那么其就是根本原因；然而，如果端口没有发送数据包的信用，那么它就是拥塞扩散的“受害者”。**

在本例中，交换机1中的端口G将是拥塞的“根因”。它有可用的信用，但是队列正在增长，因为它接收数据包的速度比转发数据包的速度快。

交换机1中的拥塞已经扩散，因此交换机2上的端口H现在处于拥塞状态。端口H将没有流量控制信用，导致它限制数据，因此是拥塞扩散的“受害者”。来自端口X的流量正遭受队头阻塞（head-of-line blocking），并导致网络结构的总吞吐量降低。

拥塞控制的目标是尽可能避免，如果已经发生，则消除这种拥塞扩散。这里的方法是限制造成拥塞的根本原因（端口A-F）端口的流量注入速率，以便其他端口不受影响（端口X）。

通过将端口A-F的注入速率限制在端口G可以处理的范围内，端口A-F不应该出现显著的性能下降（毕竟，它们的数据包无论如何都会等待），但是从端口X发送到端口Y的数据包应该能够正常流动，因为信用可用。

## RoCEv2队头阻塞分析

RoCEv2需要PFC来启用无丢包以太网结构。PFC可防止以太网交换机和NIC上的缓冲区溢出。交换机和NIC跟踪入口队列。当队列超过某个阈值时，将向上游实体发送暂停消息。然后，上行链路实体停止在该链路上发送数据，直到收到恢复消息。PFC最多指定八个优先级类别。暂停/恢复消息指定其应用的优先级级别。
问题在于暂停机制是按端口（和优先级）运行的，而不是按流量运行的。这可能导致头阻问题；导致单个流的性能不佳。现在，我们使用代表现代数据中心网络的三层测试床拓扑（下图）来说明这些问题。

![](https://ngdcn.com/zb_users/upload/2022/10/202210051459018632553.png)

**受害流**：因为暂停帧可能具有级联效应（cascading effect），所以流可能会受到甚至不在其路径上的拥塞的影响。请考虑上图。四个发送端（H11-H14）向R发送数据。此外，我们还有一个“受害者流”——VS发送数据到VR。

***当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上使用这些上行链路的流量同样受到这些暂停的影响，而不管它们的目的地是什么——这被称为线路阻塞问题。

*声明：本文素材来源于网络，如有侵权，请联系网站删除。*

流量控制