DCB是IEEE 提出的数据中心桥接技术，主要包含：
IEEE 802.1Qbb Priority-based Flow Control（PFC）：用于满足两种流量在以太网中共存时，存储流量无丢包，且对其它的流量无影响的要求。
IEEE 802.1Qaz Enhanced Transmission Selection（ETS）：用于避免一种流量类型的大规模流量猝发影响其它流量类型，为不同的流量类型提供最小带宽保证。一种流量类型只有在其它流量类型带宽不占用的情况下，才能使用分配带宽之外的额外带宽。这使多种流量类型可在同一网络中和谐共存。

DCBX = 扩展协议：自动协商

Data Center Bridging eXchange（DCBX）：它是基于LLDP（Link Layer Discovery Protocol）的扩展协议，用于在设备间自动协商并配置PFC、ETS及CN等。

QCN

IEEE 802.1Qau Congestion Notification：用于降低引起拥塞的端点站的报文发送速率，从根源上避免拥塞，以保持网络的畅通，解决因拥塞引发报文重传或流量控制，导致报文时延增加的问题。
DCB使得以太网可以承载两种不同类型的数据流。同时由于ETS可以为某种流量提供最小带宽保证，因而除了将普通数据流和存储数据流融合到一起之外，采用了DCB技术的网络还可以用来承载计算业务（用ETS在网络中为计算业务分配相应的带宽即可保证计算业务所需的时延保证）。

一、PFC

1.概述

PFC是DCB的一部分，它适用于DCB网络中的全双工的点到点链路（物理链路？）。PFC是对IEEE 802.3定义的流控机制的增强，用于在一个链路（物理链路？）上消除由于拥塞而导致的丢包。它的增强在于它是基于优先级的。传统的流控机制中，当某条链路出现拥塞时流控会阻止该链路上的所有流量。而PFC允许在一条以太网链路（物理链路？）上创建8个虚拟通道，并为每条虚拟通道指定一个IEEE 802.1P优先等级（cos），允许单独暂停和重启其中任意一条虚拟通道，同时不影响其它虚拟通道的流量。比如下图

该图中虚拟通道六的流量将被暂停，而其它通道的服务不会受到影响。
PFC使得网络管理员可以将其中一些优先级（最多8个）用于对丢包敏感的上层协议（比如FC），而另一些优先级用于常规的以太网服务。

2.报文格式

PFC的报文就是一个以太网报文，其格式如下：

DA：目的 MAC地址，为固定的组播 MAC地址 01-80-c2-00-00-01。
SA：源 MAC地址。
Type：报文类型，为 0x8808。
Data：数据，为 PFCPDU。
FCS：帧检验序列。
其中PFCPDU不包括pad部分的格式如下：

Control opcode：MAC控制操作码，2字节。PFC PAUSE帧仅是MAC控制帧的一种，对于PFC PAUSE帧，其在MAC控制帧中的操作码为01-01；
priority_enable_vector：2字节，高字节置0，低字节的每个位代表相应的time[n]是否有效。priority_enable_vector[n]代表优先级n，当priority_enable_vector[n]为1时，表示time[n]有效；当priority_enable_vector[n]为0，表示time[n]无效。
time：包含time[0] 至time[7]的8个数组单元，每个数组单元为2字节。当priority_enable_vector[n]为0时，time[n]没有意义。当priority_enable_vector[n]为1时，time[n]代表接收站点应该停止优先级为n的报文的发送的时间，时间的单位为物理层芯片发送512位数据所需要的时间。所以发送一次PFC PAUSE帧，要求对端设备暂停发送的时间长度最长为：65535 ×物理层芯片发送512位数据所需要的时间。

3.工作机制

3.1 支持PCF的设备的要求

如果一个设备支持PCF，则它要：
支持在一个或多个端口上至少在一个优先级上使能PFC
只能在受DCBX管理的域上使能PFC
提供PFC aware的系统排队功能（即排队系统需要了解PFC信息并且根据PFC的状态做出是否发送的决策）
遵守PFC的延迟限制

3.2 典型的工作过程

以图中拓扑为例，假设向红色链路转发的数据量超过了该链路的最大速率，则最终会导致Bridge 4上向该链路转发的数据无法被转发，此时即出现了拥塞。根据网桥的工作原理，这最终会反映在某些输入端口的输入队列变满上，在此图中由于Bridge 4的port 1，2，3都用于向红色链路转发数据，因而它们的输入队列都会逐渐变满。此时port 1，2，3都会通过各自的链路向上游发送拥塞指示，上游收到拥塞指示后，就会停止往该链路发送数据。以Bridge 1为例（client发的数据太快，终端反馈到Bridge 1），它就会停止从port 2发送数据，这又进一步会导致Bridge 1的port 1的输入队列逐渐被填满，此时Bridge 1又会向其上游发送拥塞指示，该过程一直持续直到到达数据的源头，对于例子中的拓扑，最终结果就是Client 1，2，3都会收到拥塞指示（更确切的说不一定所有的都会收到，一个链路的上游是否会收到拥塞指示关键取决于该链路的下游的输入队列是否逐渐变满）。

3.3 工作机制

PFC是用于数据中心的一种技术，它是对IEEE 802.3定义的流控机制的增强，它使得一个链路不会由于出现拥塞而丢包。但是PFC也有缺点，它可能会导致拥塞信息被一直向上游传递，如果使用PFC的同时也使能了CN，则会降低PFC被使用的频率。

在实际的网络中PFC经常结合ETS功能一起使用，做法是使用ETS为某种流分配一定的带宽，同时给该类流分配一个优先级并启用PFC，这样就既能保证该类流不丢包又能保证其带宽。
PFC被设计仅用于点到点的全双工链路，一个典型的使用PFC的点到点链路如下图所示：

与传统的（802.3定义的）流控相比，PFC可以基于优先级工作。这就使得它可以单独禁止与某（些）个优先级相关联的流的发送而不影响其它优先级的流，传统的流控则无法做到这一点。
标准建议对于默认优先级不要使能PFC功能。

3.3.1 发送拥塞通知：

在点到点的全双工链路中：
如果一端发现其在某个优先级上出现了拥塞，并且该优先级上启用了PFC，就向另一端发送PFC帧来通知另一端在一段时间内不要再（在某个优先级上）发送数据
如果发现其在某个优先级上的拥塞解除了，并且该优先级上启用了PFC，就向另一端发送PFC帧来通知另一端可以重新（在某个优先级上）发送数据
简单的说就是在点到点的全双工链路中，如果一端发现其在某个优先级上的拥塞状态发生了变化，并且在该优先级上启用了PFC功能，就向另一端发送PFC帧来通告这个变化。

3.3.2 接收拥塞通告

在点到点的全双工链路中如果一端收到了一个PFC帧，则它首先解析8个优先级对应的信息：
如果本端在某个优先级上没有启用PFC，则忽略该优先级的信息，否则
如果priority_enable_vector向量中对应该优先级的比特为1，且time[该优先级]不为0，则如果该优先级的发送没有停止就停止它，同时根据时间值启动一个定时器，在该定时器到期之前，该优先级的发送会被停止
如果priority_enable_vector向量中对应该优先级的比特为1，且time[该优先级]为0，则如果该优先级的发送是被停止的，就启动它，并停止相应的定时器
如果priority_enable_vector向量中对应该优先级的比特为0，则如果该优先级的发送是被停止的，就启动它，并停止相应的定时器

3.3.3 延迟限制

PFC的目地是消除链路由于拥塞而出现的丢包，因而PFC帧的发送必须满足一定的时间要求。如果发送端在自己的接收队列满之后再发送拥塞通告，则在PFC帧从发送端到接收端传输过程中，另一端发送的数据就会因为没有接收缓存而被丢弃；如果发送端过早的发送了PFC帧，虽然不会丢包但是却会导致网络利用率下降。最合适的发送拥塞通告的时机是接收缓存还有存储空间可以存储一段时间内另一端能发送的所有数据，所谓的一段时间是指发送PFC帧的一端从判断是否要发送PFC帧到对端接收到PFC帧并决定停止新的数据发送之间的时间。具体如图所示：

如图可以看出所谓的一段时间由四部分组成：
发送端产生PFC请求以及PFC帧的排队时间
PFC帧被发送到另一端的时间
PFC帧在接收端排队时间
PFC帧被接收端处理并最终停止发送新数据的时间
对比广域网中的拥塞处理，比如TCP的拥塞检测、避免算法，其中很关键的一部分是计算RTT，但是在DCB好像没有计算RTT的部分，这正是局域网与广域网的不同之处，在广域网中，你无法知道你的数据需要经过多少条物理链路，以及这些物理链路具有什么样的特性（比如速率，带宽等等），因而RTT必须经过探测才能知道（为了尽可能准确还要取平均数，进行平滑计算等等），但是在DCB中，PFC是在一条具体的物理链路上生效的，而这个物理链路的速率，带宽，队列深度都是可知的，因而无需通过收发报文来探测RTT，完全可以通过估算来获取比较准确的RTT。

从网络基础理论上来说，数据在分组交换网路中传输需要经历四种时延：处理时延，排队时延，传输时延和传播时延，对于一个接口芯片来说，处理时延、排队时延、传输时延必须保证接口能够达到它所声明的带宽（如果接口芯片的时延不能保证这一段，则无论如何接口也无法达到它所声明的速率），因此如果我们知道了接口的速率就可以知道这三种时延的最大值，而传播时延取决于物理线路的材质，只要材质确定，线路长度可知，这个时延也是可知的，因此说在一条具体的物理线路上我们是可以知道这几个时延的，也就无需计算RTT。简单的说，局域网中的拥塞探测方法之所以和广域网不同（没那么复杂）是因为具体的物理线路上的时延是可估算的，而且对于芯片来说处理逻辑越简单越好，因为这样可以简单芯片的设计复杂度。

表12-26 报文优先级和接口队列的映射表

报文类型	优先级	队列
单播	0	0
	1	1
	2	2
	3	3
	4	4
	5	5
	6	6
	7	7
非已知单播说明： CX320优先级和队列为一一对应关系。	0	0
	1、2、3	1
	4、5	2
	6、7	6

“反压信号”实际上是一个以太帧，其具体报文格式如图12-165所示。

图12-165 PFC帧格式

表12-27 PFC帧的定义

项目	描述
Destination address	目的MAC地址，取值固定为01-80-c2-00-00-01。
Source address	源MAC地址。
Ethertype	以太网帧类型，取值为88-08。
Control opcode	控制码，取值为01-01。
Priority enable vector	反压使能向量。其中E(n)和优先级队列n对应，表示优先级队列n是否需要反压。当E(n)=1时，表示优先级队列n需要反压，反压时间为Time(n)；当E(n)=0时，则表示该优先级队列不需要反压。
Time(0)～Time(7)	反压定时器。当Time(n)=0时表示取消反压。
Pad(transmit as zero)	预留。传输时为0。
CRC	循环冗余校验。

由此可见，流量暂停只针对某一个或几个优先级队列，不针对整个接口进行中断。每个队列都能单独进行暂停或重启，而不影响其他队列上的流量，真正实现多种流量共享链路。而对非PFC控制的优先级队列，系统则不进行反压处理，即在发生拥塞时将直接丢弃报文。

在FCoE环境下，管理员可指定FCoE流量对应的队列使能PFC保证不丢包。

二、ETS

（1）增强传输选择（ETS）：用于避免一种流量类型的大规模流量猝发影响其它流量类型，为不同的流量类型提供最小带宽保证。一种流量类型只有在其它流量类型带宽不占用的情况下，才能使用分配带宽之外的额外带宽。这使多种流量类型可在同一网络中和谐共存。

产生原因

多个网络流量共享同一条物理链路，带来了一个新的需求：在网络繁忙的情况下，如何保证各个网络能够运行正常的最小带宽。为此IEEE引入ETS（Enhanced Transmission Selection，增强传输选择）协议，来对不同网络流量进行带宽分配，保证各个网络正常运行所需的最小带宽。

（深度分析数据中心之ETS（Enhanced Transmission Selection）技术 - https://www.cnblogs.com/dabbei/p/3167367.html）

基本原理

ETS提供两级调度，分别基于优先级组PG（Priority Group）和优先级队列，如图12-166所示。接口首先对优先级组进行第一级调度，然后对优先级组的优先级队列进行第二级调度。

图12-166 ETS的处理流程

相比普通QoS，ETS的优势在于提供了基于优先级组的调度，将同一类型的流量归入同一优先级组，使得同一类流量能够获得相同的服务等级。

优先级组的调度

优先级组即一组拥有相同调度方式的优先级队列，用户可通过设置将不同的优先级队列加入到优先级组中。基于优先级组的调度被称为第一级调度。

缺省情况下，在ETS中定义了3个优先级组PG0、PG1和PG15，分别代表是LAN流量、SAN流量和IPC流量。

缺省情况下，优先级组的属性如下表所示。表12-28 优先级组的调度

优先级组号	优先级队列	调度方式	带宽占用率
PG0	0、1、2、4、5	DRR	50%
PG1	3	DRR	50%
PG15	6、7	PQ	-

协议规定，PG0、PG1的调度方式是DRR，PG15的调度方式为是PQ。其中由于PG15承载IPC流量，对延时要求很高，因此调度方式为是PQ（Priority Queue）；PG0和PG1的调度方式为赤字轮循队列调度DRR（Deficit Round Robin）。另外，用户也可根据实际情况对优先级组划分带宽。

各优先级组的调度方式无法更改。

假设在出接口队列中，优先级为3的队列承载的是FCoE流量，则将优先级队列3划入SAN组（即PG1）；优先级0、1、2、4、5的队列承载普通LAN流量，则划入LAN组（即PG0）；优先级6、7的队列承载IPC流量，则划入IPC组（即PG15）。接口总带宽是10Gbit/s，PG15占用的带宽是2Gbit/s，PG1和PG0各分配50%的带宽限制，即4Gbit/s。

图12-167 基于优先级组的拥塞管理

如图12-167所示，在t1和t2时刻，接口总流量不超过接口带宽时，所有流量都能转发；在t3总流量超过接口带宽，且LAN流量超过给定的带宽，按照ETS的参数进行调度，LAN业务流量被丢弃1Gbit/s。

另外，ETS还提供基于优先级组的流量整形。优先级组的流量整形基于优先级组限制流量的突发，使该优先级组内的流量以比较均匀的速率向外发送。具体原理请参见《CX320 交换模块配置指南》中的QoS配置-流量整形。

优先级的调度

除了基于优先级组的调度外，对于同一优先级组内的队列，ETS提供基于优先级的调度管理，称为第二级调度。

另外，ETS还提供基于优先级的队列拥塞管理、队列整形、队列拥塞避免。具体原理请参见《CX320 交换模块配置指南》中的QoS配置。

三、DCBX

产生原因

在数据中心网络融合场景下，为实现无丢包以太网，链路两端的PFC和ETS的参数配置需要保持一致。如果依靠管理员手工配置，不仅工作量庞大而且容易出错。数据中心桥接交换协议DCBX（Data Center Bridging Exchange Protocol）作为一种链路发现协议，能够使链路两端的设备发现并交换DCB配置信息，大大减轻了管理员的工作量。

基本原理

DCBX的具体功能包括：

发现对端设备的DCB配置信息。
发现对端设备的DCB配置错误。
配置对端设备的DCB参数。

DCBX能够交换的DCB配置信息如下：

ETS的优先级组信息
PFC

DCBX协议将需要交互的DCB配置信息封装入链路层发现协议LLDP（Link Layer Discovery Protocol）中的TLV中，由LLDP来进行链路两端设备的DCB配置交换。LLDP的具体内容请参见《CX320 交换模块配置指南-网络管理配置》中的LLDP配置。

结合图12-168，以DCB中的PFC为例，介绍LLDP承载DCBX的实现过程。

图12-168 LLDP承载DCBX的实现原理图

如图12-168所示，在全局以及PortA和PortB上分别使能LLDP功能，并且PortA上配置了允许发送DCBX TLV的前提下，实现过程如下：

PortA和PortB上分别配置PFC参数，并使能DCBX功能。DCBX模块通知PortA和PortB可以将各自配置的PFC参数封装到LLDP报文中发送给对端。
PortA的LLDP模块根据自己的报文发送周期定期向PortB发送携带了DCBX TLV的LLDP报文。
PortB接收到LLDP报文后解析出DCBX TLV，将PortA的PFC参数通知给DCBX模块。DCBX模块将PortA的PFC参数和本端配置的PFC参数进行比较，协商一致之后生成配置文件，保证两端配置一致。

DCBX TLV介绍

如图12-169所示，DCB的信息被封装在特定的TLV中。其中，Type字段固定为127，OUI字段根据协议类型不同有两种取值，IEEE DCBX的OUI为0x0080c2，INTEL DCBX的OUI为0x001b21。

图12-169 DCBX的TLV结构

IEEE DCBX TLV包括：ETS Configuration TLV、ETS Recommendation TLV、PFC Configuration TLV和App TLV。具体内容如表12-29所示。

表12-29 IEEE DCBX TLV内容

TLV名称	subtype	Length	描述
ETS Configuration TLV	09	25	ETS的本地配置。内容包括：优先级组的配置：优先级组ID和优先级组的带宽占用率优先级队列的配置：优先级队列ID和所属优先级组ID
ETS Recommendation TLV	0A	25	ETS的建议配置，通常用于协商ETS两端的配置，使其保持一致。内容包括：优先级组的配置：优先级组ID和优先级组的带宽占用率优先级队列的配置：优先级队列ID和所属优先级组ID
PFC Configuration TLV	0B	6	PFC的本地配置。内容包括：优先级队列ID 队列是否PFC
App TLV	0C	不固定	PFC设置为自动协商状态时携带此App TLV，其它状态报文中均不携带，用于各产品以及网卡对接。

INTEL DCBX TLV包括：DCBX Control Sub-TLV、Priority Group Sub-TLV、Priority Flow Control Sub-TLV和App Sub-TLV。具体内容如表12-30和表12-31所示。

表12-30 INTEL DCBX v1.00 TLV内容

TLV名称	subtype	Length	描述
DCBX Control Sub-TLV	01	10	DCBX报文信息。
Priority Group Sub-TLV	02	28	ETS的建议配置，通常用于协商ETS两端的配置，使其保持一致。内容包括：优先级组的带宽占用率优先级组的ID
Priority Flow Control Sub-TLV	03	5	PFC的本地配置。内容包括：优先级队列ID 队列是否PFC
App Sub-TLV	05	不固定	PFC设置为自动协商状态时携带此App Sub-TLV，其它状态报文中均不携带，用于各产品以及网卡对接。

表12-31 INTEL DCBX v1.01 TLV内容

TLV名称	subtype	Length	描述
DCBX Control Sub-TLV	01	10	DCBX报文信息。
Priority Group Sub-TLV	02	17	ETS的建议配置，通常用于协商ETS两端的配置，使其保持一致。内容包括：优先级组的配置：优先级组ID和优先级组的带宽占用率优先级队列的配置：优先级队列ID和所属优先级组ID
Priority Flow Control Sub-TLV	03	6	PFC的本地配置。内容包括：优先级队列ID 队列是否PFC
App Sub-TLV	04	不固定	PFC设置为自动协商状态时携带此App Sub-TLV，其它状态报文中均不携带，用于各产品以及网卡对接。

参考：

《DCB学习之一（PFC）》

DCB学习之一（PFC）_浩海拾贝-CSDN博客_pfc报文

DCB工作机制解析一（PFC）_jun_renascence的博客-CSDN博客_pfc报文格式

DCB原理描述 - CX320 交换模块 V100R001 配置指南 10 - 华为

图：

Introduction to 802.1Qbb (Priority-based Flow Control — PFC) « ipSpace.net blog

五、PFC 拥塞研究（文档收集）

《Analyzing InfiniBand Packets》

https://www.openfabrics.org/images/eventpresos/workshops2015/UGWorkshop/Thursday/thursday_09.pdf

《基于ibdump的InfiniBand网络拥塞控制观测方法研究》http://www.jsjkx.com/CN/article/openArticlePDF.jsp?id=6159

https://wenku.baidu.com/view/0b0f7854bed5b9f3f90f1c6c.html?re=view

PFC 测试对比 https://www.researchgate.net/publication/319050299_RoCE_Rocks_without_PFC_Detailed_Evaluation

中国移动：《统一的以太网无损网络测试技术白皮书》http://www.doc88.com/p-25829298673562.html

开放数据中心委员会：《无损网络测试规范》：http://www.opendatacenter.cn/download/p-1169553273830920194.html

开放数据中心委员会（ODCC），其前身为天蝎联盟（2011成立），是由中国互联网企业和科研机构自主发起的标准推进组织。开放数据中心委员会（2014成立）的正式成员包括百度、阿里巴巴、腾讯、中国电信、中国移动、工信部电信研究院，英特尔担任技术顾问。委员会旨在通过制定统一的技术规范，推动我国数据中心向标准化、产业化发展。

https://baike.baidu.com/item/%E5%BC%80%E6%94%BE%E6%95%B0%E6%8D%AE%E4%B8%AD%E5%BF%83%E5%A7%94%E5%91%98%E4%BC%9A/18743217?fr=aladdin

开放数据中心成果发布页面：http://www.opendatacenter.cn/download/22

六、DC-QCN算法（ECN算法）

Data Center Quantized Congestion Notification

DC-QCN算法是一种基于速率的端到端拥塞控制协议，它依赖于交换机的ECN标记功能来实现拥塞反馈。

6.1 ECN工作流程

在讲述DC-QCN算法之前，先了解一下ECN的工作流程：

当网络出现拥塞时，交换机会对经过的数据包进行ECN标记，接收端检测到这些标记后，会向发送端发送拥塞通知（CNP报文），从而触发发送端调整发送速率，实现拥塞控制。

ECN工作流程

发送方叫Reaction Point，简称RP；

接收方叫Notification Point，简称NP；

中间交换机叫 Congestion Point，简称CP。

发送方（RP）以最高速开始发送，沿途过程中如果有拥塞，会被标记ECN显示拥塞，当这个被标记的报文转发到接收方（NP）的时候，接收方（NP）会回应一个CNP报文，通知发送方（RP）。

收到CNP报文的发送方（RP），就会开始降速。当发送方没有收到CNP报文时，就开始又提速了。

交换机（Congestion Point, CP）：当交换机的出口队列长度超过设定的阈值时，会对经过的数据包进行ECN标记。这一过程通常通过交换机的RED（Random Early Detection，随机早期检测）或WRED（Weighted Random Early Detection，加权随机早期检测）功能实现。
接收端（Notification Point, NP）：接收端检测到携带ECN标记的数据包后，会向发送端发送CNP报文，通知发送端网络出现拥塞。
发送端（Reaction Point, RP）：发送端收到CNP报文后，会根据预定义的算法调整发送速率，以降低网络拥塞。

参考：[RoCE]拥塞控制机制(ECN, QC-QCN) :https://cloud.tencent.com/developer/article/1078916

总结起来就是：维护这个算法的节点是服务器，也就是流量的两端，中间的交换机作为传输节点，通告是否拥塞。

补充:

QCN 是二层（数据链路层） 的协议，工作在交换机和网卡硬件层面，反应非常快。
它是为无损以太网（配合 PFC 等技术）设计的，常用于高性能计算或存储网络（如 RoCE 场景）。
和 TCP 的拥塞控制不同，QCN 是由网络设备（如交换机）主动反馈给发送端，而不是靠丢包来判断拥塞。

6.2 什么是QCN

量化拥塞通知(Quantized Congestion Notification,QCN)，IEEE 802.1Qau（即 QCN）是一种用于以太网的拥塞控制机制，特别适用于带宽有限、存在传输延迟的网络环境，能有效管理那些长时间持续传输的数据流，避免网络因拥堵而性能下降。

802.1Qau和ETS,PFC,和DCBX一样都是IEEE数据中心桥接(DCB)协议套件中的一部分。QCN在二层以太网络上制定，并且是针对硬件实现的。QCN适用所有的以太网传输，并且主机端和交换机端的行为也在标准中详细规定。QCN的配置和信息可以用mlnx_qcn命令查询。

┌───────────────────────────────────────────────┐
│        IEEE 802.1 Data Center Bridging (DCB)   │
│                协议套件                        │
└─────────────────────┬─────────────────────────┘
                      │
    ┌─────────────────┼───────────────────────────────┐
    │                 │                               │
┌─────────────┐ ┌─────────────┐ ┌───────────────────────┐
│ 802.1Qbb    │ │ 802.1Qaz    │ │ 802.1Qau              │
│ PFC         │ │ ETS         │ │ QCN                   │
│ 基于优先级的 │ │ 增强传输选择 │ │ 量化拥塞通知          │
│ 流量控制     │ │ （带宽分配） │ │ （拥塞控制）          │
└─────────────┘ └─────────────┘ └───────────────────────┘
    │                 │                               │
    └─────────┬───────┴───────────────┬───────────────┘
              │                       │
        ┌─────────────────┐   ┌───────────────────────┐
        │ 802.1AB + LLDP  │   │ 主机与交换机协同工作   │
        │ (链路层发现协议) │   │ • 交换机检测拥塞       │
        └─────────────────┘   │ • 主机调整发送速率     │
                              └───────────────────────┘
                                      ▲
                                      │
                            ┌───────────────────────┐
                            │ DCBX (DCB Exchange)   │
                            │ 自动协商 PFC/ETS/QCN 等│
                            │ 配置参数               │
                            └───────────────────────┘

组件	标准编号	功能简述
PFC	IEEE 802.1Qbb	在以太网上实现无损传输：按优先级暂停流量（如暂停存储流量但不影响普通IP流量），避免丢包。
ETS	IEEE 802.1Qaz	将带宽按优先级分配给不同流量类别（如30%给存储，50%给计算，20%给管理），保障关键业务。
QCN	IEEE 802.1Qau	主动拥塞控制：交换机检测到队列积压时，向源主机发送 CNM（拥塞通知消息），主机自动降速。
DCBX	基于 IEEE 802.1AB (LLDP)	主机与交换机通过 LLDP 自动协商 DCB 参数（如哪些优先级启用 PFC、ETS 带宽比例等），确保配置一致。

6.3 DC-QCN算法

DC-QCN（Data Center Quantized Congestion Notification）是一种专为大规模 RDMA（远程直接内存访问）网络设计的拥塞控制算法，由微软研究院（Microsoft Research）在 SIGCOMM 2015 年发表的论文《Congestion Control for Large-Scale RDMA Deployments》中首次提出。

该算法融合了 数据中心 TCP（DCTCP）的 ECN（显式拥塞通知）反馈机制 与 IEEE 802.1Qau（QCN）的快速硬件响应特性，为 RoCEv2 等无损以太网流量提供高效、可扩展的拥塞控制。

DC-QCN 依赖于交换机对数据包的 ECN 标记。在支持 ECN 的网络中，IP 包头的“DS字段”中的最后两个比特用于 ECN：当交换机检测到队列拥塞时，会将这两个比特置为 “11”（即 CE，Congestion Experienced）。接收端收到此类数据包后，会向发送端返回拥塞信号，触发发送速率调整。

拥塞标记（即 ECN 标记）的概率由交换机输出队列的当前长度决定，通常采用一种线性概率标记机制，其行为由两个阈值控制：

当队列长度低于低阈值时，不会对任何数据包打上 ECN 标记；
当队列长度超过高阈值时，所有从此队列发出的数据包都会被标记 ECN；
当队列长度介于低阈值和高阈值之间时，数据包被标记 ECN 的概率随队列长度线性增长——队列越长，标记概率越高。

当接收端的 RoCE 网卡收到带有 ECN-CE（Congestion Experienced）标记的数据包时，会主动构造一个拥塞通知包（CNP, Congestion Notification Packet），并将其发送回该数据包的原始发送方。
CNP 中包含了被标记数据流对应的 Queue Pair（QP）编号和其他必要信息，用于唯一标识需要调整速率的发送队列。
发送方网卡在收到 CNP 后，会根据 DC-QCN 拥塞控制算法，立即降低对应 QP 的发送速率，从而缓解网络拥塞。

Term	Description
RP(injector)	Reaction Point - the end node that performs rate limitation to prevent congestion
NP	Notification Point - the end node that receives the packets from the injector and sends back notifications to the injector for indications regarding the congestion situation
CP	Congestion Point -the switch queue in which congestion happens
CNP	The RoCEv2 Congestion Notification Packet - The notification message an NP sends to the RP when it receives CE marked packets.

术语	描述
RP（Injector）	反应点（注入器） - 执行速率限制的终端节点，以防止网络拥塞
NP	通知点 - 接收来自注入器的数据包，并向注入器发送关于拥塞情况的通知
CP	拥塞点 - 发生拥塞的交换机队列
CNP	RoCEv2拥塞通知数据包 - 当通知点接收到CE标记的数据包时，向反应点发送的通知消息

DC-QCN 的速率控制机制如图所示（参考图），其核心思想是：在没有拥塞信号时逐步提升发送速率以探测可用带宽，而在检测到拥塞时迅速降低速率以缓解压力。

具体来说，每个 Queue Pair（QP）维护一个发送速率状态。在未收到拥塞通知期间，算法基于内部定时器和已发送字节数，以加性方式（Additive Increase）缓慢增加速率。

一旦接收到来自对端的 CNP（Congestion Notification Packet），发送方会立即对对应的 QP 执行乘性减速（Multiplicative Decrease）。减速的幅度由一个称为 α（alpha） 的动态参数决定——α 反映了近期网络拥塞的严重程度：每次收到 CNP 时 α 会被更新，随后随时间指数衰减。这样既能快速响应突发拥塞，又能避免过度保守导致带宽利用率下降。

DC-QCN 算法通过三个并行运行的逻辑模块协同工作，实现对每个 Queue Pair（QP）发送速率的动态调节：

α 参数更新：持续评估网络拥塞程度；
降速机制：在收到拥塞通知时快速降低速率；
提速机制：在无拥塞时逐步探测可用带宽。

以下分别详述各模块。

7.1 α 参数更新（拥塞度估计）

算法将时间划分为固定长度的拥塞评估窗口（congestion window，可配置）。每个窗口结束时，系统检查该窗口内是否收到至少一个 CNP（Congestion Notification Packet）——无论收到多少个 CNP，只要 ≥1，即视为一次拥塞事件。

α 是一个指数加权移动平均值（EWMA），用于反映近期拥塞的严重程度。其更新公式为：

α_new=g⋅α_old+(1-g)*I

其中：

g∈(0,1)g∈(0,1) 是衰减因子（典型值如 0.995），控制历史信息的保留程度；
I是一个布尔指示变量：若上一窗口内收到 CNP，则 I=1 ，否则 I=0 。

该设计使 α 能快速响应新拥塞，同时平滑历史波动。

7.2 降速机制

降速使用独立的速率控制窗口（通常比 α 更新窗口更短）。若在当前窗口内收到至少一个 CNP，则触发降速：

rate_new=rate_old*(1-α/2)

说明：α 越大（表示拥塞越严重），降速幅度越大，但最大不超过 50%（因 α ≤ 1）。

同时，所有与提速相关的状态和计数器（如当前阶段、提速事件数等）会被重置，并返回到“快速恢复”阶段。

此外，降速前的当前速率会被保存为 target_rate，作为后续快速恢复的目标参考值。

7.3 提速机制

提速逻辑借鉴自 QCN，分为三个顺序阶段，旨在平衡恢复速度与避免二次拥塞：

快速恢复（Fast Recovery）
- 目标：尽快回到拥塞发生前的速率（即 target_rate）。
- 策略：每次提速事件触发时，速率按如下方式更新：

rate=(rate+target_rate)/2

 即以**对数方式逼近** `target_rate` —— 初期增速快，接近目标时增速放缓。

积极增加（Active Increase）
超积极增加（Hyper Increase）

后两个阶段均采用线性增窗：每次提速事件使速率增加一个固定步长（如 10 Gbps/s），以高效利用新释放的带宽。

阶段切换规则：

每个阶段维护一个提速事件计数器；
当计数超过预设阈值时，进入下一阶段；
一旦发生降速事件，立即重置所有计数器，并返回“快速恢复”阶段。

提速事件触发条件：

在最近一次提速之后，若经过预设的时间间隔或发送了预设字节数，且期间未收到任何 CNP，则触发一次“提速事件”。

6.4 总结

这次记录了RoCEv2网络中对于拥塞控制的检测，预防和应对方法。ECN检测和标记是现代数据中心商用交换机普遍具有的功能，它保存在IP头部的查分服务代码点中的两个比特位中。启用ECN功能后，在网络上出现拥塞后，交换机会对ECN域打上CE值，由接收方产生CNP来通知发送方网络拥塞事件。发送方收到CNP指示的事件通知后，根据DC-QCN算法中对当前速度处于快速恢复，积极增加和超积极增加三个阶段中对应的动作来对注入速率进行控制，从而解决网络中的拥塞情况。

本文梳理了 RoCEv2 网络中拥塞的检测、响应与控制机制。现代交换机普遍支持 ECN（Explicit Congestion Notification） 功能。启用 ECN 后，当交换机输出队列出现拥塞（如队列长度超过设定阈值），会将 IP 包头中 区分服务字段（DS Field）的 ECN 位（最后两位）标记为 CE（Congestion Experienced）。

接收端的 RoCE 网卡在收到带 CE 标记的数据包后，会主动构造并回传一个 CNP（Congestion Notification Packet），通知原始发送方发生了网络拥塞。

发送方在收到 CNP 后，依据 DC-QCN 拥塞控制算法，对其对应的 Queue Pair（QP）执行降速操作。该算法将提速过程划分为三个阶段——快速恢复（Fast Recovery）——并结合动态参数 α 调节降速幅度，从而在缓解拥塞的同时高效利用可用带宽，最终实现低延迟、高吞吐、无丢包的数据中心 RDMA 通信。

目的

主要是为了参数设置、排障和容量评估。

机制
ECN 标记 -> 接收端发 CNP -> 发送端降速 -> 再缓慢加速（DCQCN 的闭环）。
参数在哪一层
交换机侧（ECN 阈值/标记策略/队列缓冲）和 NIC 侧（降速/加速相关参数）要配套。
和 PFC 的关系
目标是“先 ECN，后 PFC”；PFC 只做兜底，不应成为常态。
看哪些指标判断好坏
ECN mark、CNP、PFC pause、队列深度、吞吐和尾延迟（P99）。
调优方法
固定流量模型（如 allreduce/incast），一次只改一类参数，逐步逼近，不要同时改交换机和主机多项参数。

所以结论是：
了解 DCQCN 是为了“能正确设参 + 能解释现象 + 能稳定运维”。

重点看这两侧参数：

交换机侧（RoCE）

QoS映射：trust dscp/pcp、DSCP<->TC、TC<->Queue、RoCE数据优先级、CNP优先级。
PFC：按优先级开关、xoff/xon 阈值、headroom、PFC watchdog。
ECN/WRED：每队列 min-threshold、max-threshold、mark-probability（或 mark-all-above-threshold）。
Buffer：lossless 队列保留缓冲、shared buffer、dynamic threshold(alpha)。
调度：ETS 带宽比例、是否给 CNP 队列高优先级。
基础项：MTU 一致、ECMP 哈希策略（对称性）。

NIC侧（常见于 ConnectX）

DCB/PFC：网卡上各优先级的 PFC、ETS、trust 模式。
NP/CNP：cnp_dscp、cnp_802p_prio、CNP 生成开关/频率。
RP/DCQCN：enable、initial/min/max rate、ai_rate、hai_rate、gd、min_dec_fac、rpg_time_reset、rpg_byte_reset、rpg_threshold、rate_to_set_on_first_cnp、clamp_tgt_rate、initial_alpha、dce_tcp_g、dce_tcp_rtt。
RoCE基础：GID index、traffic class/DSCP、每端口配置一致性。

实操原则：先ECN后PFC（PFC兜底，不做常态），一次只改一组参数。