还有在机器学习和AI的技术趋势下，对计算能力的需求是呈几何级数上升的，为了满足日益复杂的神经网络和深度学习模型，数据中心会存在大量的分布式计算集群，但大量并行程序的通讯延迟，则会极大影响整个计算过程的效率。

另外为了解决数据中心内爆炸式增长的数据存储和读取效率问题，利用以太网融合组网的分布式存储越来越受到欢迎。但因为存储网络中数据流以大象流为主，所以一旦因拥塞造成丢包，将会引发大象流重传，不仅降低效率，还会加重拥塞。

所以从前端用户的体验和后端应用的效率来看，眼下对于数据中心网络的要求是：延迟越低越好，效率越高越好。

为了降低数据中心内部网络延迟，提高处理效率，RDMA技术应运而生，通过允许用户态的应用程序直接读取和写入远程内存，而无需CPU介入多次拷贝内存，并可绕过内核直接向网卡写数据，实现了高吞吐量、超低时延和低CPU开销的效果。

当前RDMA在以太网上的传输协议是RoCEv2，RoCEv2是基于无连接协议的UDP协议，相比面向连接的TCP协议，UDP协议更加快速、占用CPU资源更少，但其不像TCP协议那样有滑动窗口、确认应答等机制来实现可靠传输，一旦出现丢包，依靠上层应用检查到了再做重传，会大大降低RDMA的传输效率。

所以要想发挥出RDMA真正的性能，突破数据中心大规模分布式系统的网络性能瓶颈，势必要为RDMA搭建一套不丢包的无损网络环境，而实现不丢包的关键就是解决网络拥塞。

为什么会产生拥塞

产生拥塞的原因有很多，下面列举了在数据中心场景里比较关键也是比较常见的三点原因：

收敛比

进行数据中心网络架构设计时，从成本和收益两方面来考虑，多数会采取非对称带宽设计，即上下行链路带宽不一致，交换机的收敛比简单说就是总的输入带宽除以总的输出带宽。以锐捷万兆交换机RG-S6220-48XS6QXS-H为例，下行可供服务器输入的带宽是48*10G=480G，上行输出的带宽是6*40G=240G，整机收敛比为2:1。而25G交换机RG-S6510-48VS8CQ，下行可供服务器输入的带宽是48*25G=1200G，上行输出的带宽是8*100G=800G，整机收敛比是1.5:1。

也就是说，当下联的服务器上行发包总速率超过上行链路总带宽时，就会在上行口出现拥塞。

说PFC之前，我们可以先看一下IEEE 802.3X（Flow Control）流控的机制：当接收者没有能力处理接收到的报文时，为了防止报文被丢弃，接收者需要通知报文的发送者暂时停止发送报文。

如下图所示，端口G0/1和G0/2以1Gbps速率转发报文时，端口F0/1将发生拥塞。为避免报文丢失，开启端口G0/1和G0/2的Flow Control功能。

▲端口产生拥塞的打流模型

当F0/1在转发报文出现拥塞时，交换机B会在端口缓冲区中排队报文，当拥塞超过一定阈值时，端口G0/2向G0/1发PAUSE帧，通知G0/1暂时停止发送报文。

G0/1接收到PAUSE帧后暂时停止向G0/2发送报文。暂停时间长短信息由PAUSE帧所携带。交换机A会在这个超时范围内等待，或者直到收到一个Timeout值为0的控制帧后再继续发送。

IEEE 802.3X协议存在一个缺点：一旦链路被暂停，发送方就不能再发送任何数据包，如果是因为某些优先级较低的数据流引发的暂停，结果却让该链路上其他更高优先级的数据流也一起被暂停了，其实是得不偿失的。

如下图中报文解析所示，PFC在基础流控IEEE 802.3X基础上进行扩展，允许在一条以太网链路上创建8个虚拟通道，并为每条虚拟通道指定相应优先级，允许单独暂停和重启其中任意一条虚拟通道，同时允许其它虚拟通道的流量无中断通过。

▲PFC协议报文结构解析

PFC将流控的粒度从物理端口细化到8个虚拟通道，分别对应Smart NIC硬件上的8个硬件发送队列（这些队列命名为Traffic Class，分别为TC0,TC1,...,TC7），在RDMA不同的封装协议下，也有不同的映射方式。

RoCEv1

这个协议是将RDMA数据段封装到以太网数据段内，再加上以太网的头部，因此属于二层数据包。为了对它进行分类，只能使用VLAN（IEEE 802.1q）头部中的PCP(Priority Code Point)域3 Bits来设置优先级值。

简单来说，在二层网络的情况下，PFC使用VLAN中的PCP位来对数据流进行区分，在三层网络的情况下，PFC既可以使用PCP、也可以使用DSCP，使得不同数据流可以享受到独立的流控制。当下数据中心因多采用三层网络，因此使用DSCP比PCP更具有优势。

PFC死锁

虽然PFC能够通过给不同队列映射不同优先级来实现基于队列的流控，但同时也引入了新的问题，例如PFC死锁的问题。

PFC死锁，是指当多个交换机之间因微环路等原因同时出现拥塞,各自端口缓存消耗超过阈值，而又相互等待对方释放资源，从而导致所有交换机上的数据流都永久阻塞的一种网络状态。

正常情况下，当一台交换机的端口出现拥塞并触发XOFF水线时，数据进入的方向（即下游设备）将发送PAUSE帧反压，上游设备接收到PAUSE帧后停止发送数据，如果其本地端口缓存消耗超过阈值，则继续向上游反压。如此一级级反压，直到网络终端服务器在PAUSE帧中指定Pause Time内暂停发送数据，从而消除网络节点因拥塞造成的丢包。

但在特殊情况下，例如发生链路故障或设备故障时，BGP路由重新收敛期间可能会出现短暂环路，会导致出现一个循环的缓冲区依赖。如下图所示，当4台交换机都达到XOFF水线，都同时向对端发送PAUSE帧，这个时候该拓扑中所有交换机都处于停流状态，由于PFC的反压效应，整个网络或部分网络的吞吐量将变为零。
 

利用ECN实现端到端的拥塞控制

当前的RoCE拥塞控制依赖ECN(Explicit Congestion Notification，显式拥塞通知)来运行。ECN最初在RFC 3168中定义，网络设备会在检测到拥塞时，通过在IP头部嵌入一个拥塞指示器和在TCP头部嵌入一个拥塞确认实现。

RoCEv2标准定义了RoCEv2拥塞管理(RCM)。启用了ECN之后，网络设备一旦检测到RoCEv2流量出现了拥塞，会在数据包的IP头部ECN域进行标记。

▲IP报文头ECN字段结构

这个拥塞指示器被目的终端节点按照BTH(Base Transport Header，存在于IB数据段中)中的FECN拥塞指示标识来解释意义。换句话说，当被ECN标记过的数据包到达它们原本要到达的目的地时，拥塞通知就会被反馈给源节点，源节点再通过对有问题的Queue Pairs（QP）进行网络数据包的速率限制来回应拥塞通知。

ECN交互过程

▲ECN交互过程示意图

• 发送端发送的IP报文标记支持ECN（10）；

• 交换机在队列拥塞情况下收到该报文，将ECN字段修改为11并发出，网络中其他交换机将透传；

• 接收端收到ECN为11的报文发现拥塞，正常处理该报文；

• 接收端产生拥塞通告，每ms级发送一个CNP（Congestion Notification Packets）报文，ECN字段为01，要求报文不能被网络丢弃。接收端对多个被ECN标记为同一个QP的数据包发送一个单个CNP即可（格式规定见下图）；

• 交换机收到CNP报文后正常转发该报文；

• 发送端收到ECN标记为01的CNP报文解析后对相应的流（对应启用ECN的QP）应用速率限制算法。

RoCEv2的CNP包格式如下：

▲CNP报文结构

值得注意的是，CNP作为拥塞控制报文，也会存在延迟和丢包，从发送端到接收端经过的每一跳设备、每一条链路都会有一定的延迟，会最终加大发送端接收到CNP的时间，而与此同时交换机端口下的拥塞也会逐步增多，若发送端不能及时降速，仍然可能造成丢包。建议拥塞通告域的规模不要过大，从而避免因为ECN控制报文交互回路的跳数过多，而影响发送端无法及时降速，造成拥塞。

总结

RDMA网络正是通过在网络中部署PFC和ECN功能来实现无损保障。PFC技术让我们可以对链路上RDMA专属队列的流量进行控制，并在交换机入口（Ingress port）出现拥塞时对上游设备流量进行反压。利用ECN技术我们可以实现端到端的拥塞控制，在交换机出口（Egress port）拥塞时，对数据包做ECN标记，并让流量发送端降低发送速率。

从充分发挥网络高性能转发的角度，我们一般建议通过调整ECN和PFC的buffer水线，让ECN快于PFC触发，即网络还是持续全速进行数据转发，让服务器主动降低发包速率。如果还不能解决问题，再通过PFC让上游交换机暂停报文发送，虽然整网吞吐性能降低，但是不会产生丢包。

在数据中心网络中应用RDMA，不仅要解决转发面的无损网络需求，还要关注精细化运维，才能应对延迟和丢包敏感的网络环境。有关MMU的精细化管理技术以及基于INT的网络可视化技术可参考往期文章。