📚 课程目录第3章拥塞控制基础

3. 拥塞控制基础：TCP与RoCE拥塞控制差异、PFC与ECN原理

3.1 为什么传统TCP拥塞控制不适用于RoCE

RoCE（RDMA over Converged Ethernet）将RDMA能力承载在以太网上，但其传输层语义继承自InfiniBand，与TCP有本质区别。TCP拥塞控制的核心是端到端滑动窗口 + 丢包反馈，而RoCE v2依赖的是无损网络 + 链路层流控 + 显式拥塞通知。理解两者差异，是定位RoCE拥塞丢包的前提。

对比维度	TCP	RoCE v2
传输语义	可靠字节流，ACK/NACK确认	可靠报文（RC），Go-Back-N重传
拥塞反馈	丢包或显式拥塞（ECN）	ECN标记（需DCQCN等配合）
流控机制	端到端窗口调整	链路层PFC逐跳反压
丢包后果	窗口减半，重传恢复	重传开销极大，性能断崖
队列管理	允许适度缓冲	要求无损，队列不能溢出

TCP的拥塞控制基于丢包即拥塞的假设，通过慢启动、拥塞避免、快速重传等机制逐步探测带宽。但RoCE流量对延迟极度敏感，一次丢包可能触发大量重传，导致GPU通信或存储集群的尾延迟飙升。更关键的是，RoCE硬件卸载的传输引擎并不像TCP协议栈那样具备精细的窗口调整能力，它依赖网络本身提供无损通道。

核心认知：RoCE网络设计的第一原则是“不让报文丢失”，而不是“丢包后快速恢复”。因此，拥塞控制的重心从端侧算法转移到网络设备的队列调度与流控机制上。

3.2 PFC（优先级流控）原理与隐患

PFC（Priority Flow Control，IEEE 802.1Qbb）是RoCE无损网络的基础。它将物理链路划分为8个优先级队列，每个队列独立进行流控。当接收端某优先级队列的缓存占用超过阈值时，接收端向发送端发送PFC暂停帧（Pause帧），要求发送端暂停该优先级队列的发送。

// PFC暂停帧关键字段（简化）
EtherType: 0x8808
Opcode: 0x0101 (PFC)
Priority Enable Vector: 0x0003  // 启用优先级0和1
Time[0]: 0xFFFF                // 优先级0暂停时间（单位：quanta）
Time[1]: 0x0000                // 优先级1不暂停

PFC的运作机制可以概括为逐跳反压：当交换机A的出口队列拥塞时，它向上一跳设备（交换机B或服务器网卡）发送PFC帧，上一跳设备暂停发送；如果上一跳设备的队列也持续堆积，它会继续向上游反压，最终可能传导到发送端服务器网卡。

PFC虽然保证了单条链路的无损，但存在三个典型隐患：

队头阻塞（HOL Blocking）：一个优先级的反压会阻塞同一物理链路上其他优先级的正常流量，因为PFC暂停的是整个优先级队列，而非单个流。
死锁风险：当多个交换机形成环形拓扑，且每个交换机都因PFC暂停了向下一跳的发送时，可能形成循环等待，导致网络瘫痪。
拥塞扩散：PFC反压会从拥塞点向上游逐跳传导，最终可能波及到本不该受影响的服务器网卡，造成“无辜流”被限速。

3.3 ECN（显式拥塞通知）原理与标记机制

ECN（Explicit Congestion Notification，RFC 3168）是一种端到端拥塞反馈机制，它让网络设备在队列深度超过阈值时，不再丢弃报文，而是在IP头中打上拥塞标记（CE，Congestion Experienced），接收端收到CE标记后，在回传的ACK中携带ECN-Echo，发送端据此降低发送速率。

RoCE v2使用ECN的流程如下：

发送端网卡发出IP头中ECT（ECN-Capable Transport）位为10的RoCE报文。
交换机检测到出口队列深度超过ECN阈值（如缓存深度的60%），将IP头中的CE位（原ECT位改为11）置位。
接收端网卡收到CE标记的报文后，在CNP（Congestion Notification Packet）报文中反馈拥塞信息。
发送端收到CNP后，按照DCQCN算法将当前速率减半，并进入恢复阶段逐步提升速率。

// RoCE v2报文IP头ECN字段示意
IP Header:
  Version: 4
  DSCP: 46 (CS6, 无损队列)
  ECN: 10 (ECT)  →  11 (CE)  // 交换机标记拥塞
  Source IP: 192.168.1.10
  Dest IP: 192.168.1.20

  关键区别：PFC是链路层逐跳机制，作用于物理链路；ECN是网络层端到端机制，作用于IP报文。PFC防止丢包，ECN通知拥塞。两者必须配合使用：ECN负责“告诉发送端慢下来”，PFC负责“在发送端慢下来之前不让报文丢失”。

3.4 典型场景：PFC与ECN配合不当引发的丢包

某数据中心部署RoCE v2承载分布式存储业务，拓扑为Spine-Leaf架构。业务高峰期出现如下现象：存储节点监控显示大量重传，但交换机端口统计中丢包计数为零。进一步排查发现，问题出在PFC与ECN的阈值配置不匹配上。

具体配置如下：

// 交换机A（Leaf层）关键配置
interface Ethernet1/1
  priority-flow-control mode on
  priority-flow-control priority 3 no-drop
  // PFC阈值：当队列占用超过 300KB 时发送PFC暂停帧

// 交换机B（Spine层）关键配置
interface Ethernet1/1
  priority-flow-control mode on
  priority-flow-control priority 3 no-drop
  // ECN阈值：当队列占用超过 200KB 时标记CE
  ecn threshold 200KB

由于Leaf交换机A的PFC触发阈值（300KB）高于Spine交换机B的ECN标记阈值（200KB），当Spine交换机B的队列深度达到200KB时，它开始标记ECN，但此时Leaf交换机A尚未触发PFC，仍然以全速向Spine发送。Spine交换机B的队列继续增长，直到超过其物理缓冲上限，最终发生尾丢弃。

虽然端口统计中PFC帧计数不为零，但实际丢包发生在Spine交换机B的出口队列溢出瞬间。由于RoCE网卡对丢包极其敏感，一次丢弃就可能导致整个RC连接的Go-Back-N重传，吞吐量瞬间下降。

配置误区：PFC阈值必须低于ECN阈值，且ECN阈值必须低于交换机物理缓冲上限。正确顺序应为：ECN标记（提前通知）→ PFC反压（兜底保护）→ 物理丢包（最后防线）。如果PFC阈值设置过高，ECN还没来得及生效，队列已经溢出。

3.5 误区复盘：PFC帧计数与真实拥塞的错位

在排障过程中，工程师容易陷入一个误区：看到PFC帧计数增长就认为PFC是罪魁祸首。实际上，PFC帧是网络在“自救”的表现，真正的问题往往出在ECN反馈链路不通或速率调整不及时。

一个典型的错误排查路径如下：

错误判断：交换机上PFC帧计数高 → 认为PFC配置错误 → 直接关闭PFC → 导致丢包率飙升。
正确思路：PFC帧计数高说明拥塞已经发生 → 检查ECN标记是否生效 → 检查CNP报文是否被丢弃 → 检查DCQCN参数（如α、g、timer）是否合理。

另一个常见误区是忽略ECN阈值与PFC阈值的配合关系。如果ECN阈值设置过低，发送端会被频繁降速，导致带宽利用率下降；如果ECN阈值设置过高，PFC会频繁介入，造成反压扩散。推荐的经验值是：ECN阈值设为交换机缓冲深度的30%~50%，PFC阈值设为50%~70%，留出足够缓冲吸收瞬态突发。

此外，还需注意CNP报文的优先级。CNP报文通常使用优先级0（或单独的高优先级队列），如果CNP报文本身被PFC反压阻塞，发送端就无法及时收到拥塞反馈，导致拥塞持续恶化。因此，必须确保CNP报文的调度优先级高于普通RoCE数据流量。

总结而言，RoCE拥塞控制是一个分层协作的系统：ECN负责快速反馈，PFC负责兜底无损，DCQCN负责速率调整。任何一层的配置失误或阈值错配，都可能表现为“无丢包但性能差”或“有丢包但PFC计数正常”的复杂现象。定位问题时，应同时观察ECN标记计数、PFC帧计数、队列深度曲线和CNP报文统计，交叉验证才能准确找到拥塞根源。