【网络】PFC背景和原理 、文档(DCB=PFC + ETS,DCBX=DCB扩展)
目录
作者:bandaoyu 地址:https://blog.csdn.net/bandaoyu/article/details/117436019
零、背景
在数据中心网络当中,典型的存在着以下两种流量:
存储数据流:要求无丢包;
普通数据流:允许一定的丢包和时延。
很显然两种数据流对服务的要求是不同的,因而传统的数据中心也往往会部署两个网络来满足对数据中心的这些需求。这种网络在一定意义上来说是冗余的,会造成资源的浪费,当数据中心规模扩大时,这种方案就变的不可接受了。因此急需一种可以将两种网络统一起来的网络技术。
当不考虑上层承载业务,并且考虑以当今最普遍的以太网为基础进行网络融合时,需要考虑的最主要就是不能丢包。为此IEEE定义了DCB(Data Center Bridging)。
DCB = PFC(流控) + ETS(带宽分配)
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-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
产生原因
数据中心网络融合后,在网络中存在三种流量:LAN流量、SAN流量和IPC流量。而融合网络中对QoS的要求很高,例如SAN流量对丢包很敏感、且要求报文在传输过程中是保序的;IPC流量用于服务器之间的通信,流量要求低时延;LAN流量则只需要设备提供尽力而为的服务,丢包和乱序都可以由两端的主机来处理,不需要网络节点做过多的干预。传统的QoS已经无法满足融合网络的需求,而增强传输选择ETS(Enhanced Transmission Selection)通过灵活的层次化的调度实现网络融合后的QoS。
基本原理
ETS提供两级调度,分别基于优先级组PG(Priority Group)和优先级队列,如图12-166所示。接口首先对优先级组进行第一级调度,然后对优先级组的优先级队列进行第二级调度。
相比普通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所示,在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所示,在全局以及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。
IEEE DCBX TLV包括:ETS Configuration TLV、ETS Recommendation TLV、PFC Configuration TLV和App TLV。具体内容如表12-29所示。
TLV名称 | subtype | Length | 描述 |
---|---|---|---|
ETS Configuration TLV | 09 | 25 | ETS的本地配置。内容包括:
|
ETS Recommendation TLV | 0A | 25 | ETS的建议配置,通常用于协商ETS两端的配置,使其保持一致。内容包括:
|
PFC Configuration TLV | 0B | 6 | 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所示。
TLV名称 | subtype | Length | 描述 |
---|---|---|---|
DCBX Control Sub-TLV | 01 | 10 | DCBX报文信息。 |
Priority Group Sub-TLV | 02 | 28 | ETS的建议配置,通常用于协商ETS两端的配置,使其保持一致。内容包括:
|
Priority Flow Control Sub-TLV | 03 | 5 | PFC的本地配置。内容包括:
|
App Sub-TLV | 05 | 不固定 | PFC设置为自动协商状态时携带此App Sub-TLV,其它状态报文中均不携带,用于各产品以及网卡对接。 |
TLV名称 | subtype | Length | 描述 |
---|---|---|---|
DCBX Control Sub-TLV | 01 | 10 | DCBX报文信息。 |
Priority Group Sub-TLV | 02 | 17 | ETS的建议配置,通常用于协商ETS两端的配置,使其保持一致。内容包括:
|
Priority Flow Control Sub-TLV | 03 | 6 | 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算法 (网络工程师必会)
Data Center Quantized Congestion Notification
原文链接:https://blog.csdn.net/zxpoiu/article/details/111034771
网络拥塞控制是一个很复杂的课题,这里只讲一些基本的设计思路。
RoCE使用的拥塞控制算法是DCQCN,*《Congestion Control for Large-Scale RDMA Deployments》*这篇论文很详细地描述了该算法。
这里先简单的描述下这个算法:维护这个算法的节点是服务器,也就是流量的两端,中间的交换机作为传输节点,通告是否拥塞。
发送方叫Reaction Point,简称RP;
接收方叫Notification Point,简称NP;
中间交换机叫 Congestion Point,简称CP。
发送方(RP)以最高速开始发送,沿途过程中如果有拥塞,会被标记ECN显示拥塞,当这个被标记的报文转发到接收方(NP)的时候,接收方(NP)会回应一个CNP报文,通知发送方(RP)。
收到CNP报文的发送方(RP),就会开始降速。当发送方没有收到CNP报文时,就开始又提速了。
摘抄自:[RoCE]拥塞控制机制(ECN, QC-QCN) :https://cloud.tencent.com/developer/article/1078916
6.量化拥塞通知(Quantized Congestion Notification,QCN)
量化拥塞通知IEEE标准(802.Qau)以有限带宽时延的以太网网络为长期保活的网络流提供了拥塞控制。这是IEEE数据中心桥接(DCB)协议套件中的一部分,还包括ETS,PFC,和DCBX。QCN在二层以太网络上制定,并且是针对硬件实现的。QCN适用所有的以太网帧和所有的传输,并且主机端和交换机端的行为也在标准中详细规定。QCN的配置和信息提取可以适用mlnx_qcn命令。
7.DC-QCN算法
DC-QCN算法是基于数据中心TCP(DCTCP)和量化通知算法的结合,并且和微软研究院协同开发的。最初的算法在SIGCOMM'15论文"Congestion control for large scale RDMA deployments"中提出。DC-QCN算法依赖于交换机端的ECN标记。ECN是商用数据中心交换机的普遍特点。在数据包IP头部中的查分服务域中的两个比特位用来提示拥塞。一旦交换机端出现了拥塞,这两个比特位就被置为"11"(CE)。
标记拥塞是队列长度的概率函数,如下图所示。队列长度的两个门限值定义了标记概率。当队列长度低于门限值下限时,ECN位不会被标记。当队列长度超过门限值上限时,所有从该队列传输的网络包都会被进行ECN标记。当队列长度处于两个门限值之间时,数据包会以与队列长度线性增长的概率被进行ECN标记。
带有ECN标记的数据包被传播到接收方的网卡上。接收方网卡创建一个CNP并把它发送给ECN所标记的数据包的发送方。CNP数据包包括被标记的QP的信息。当CNP被发送方网卡收到时,它会基于下面描述的算法来降低指定QP的传输速率。
DC-QCN降速算法通过下面的图表来描述。简而言之,如果QP基于内部定时器和发送字节计数器,算法会持续的增加发送速率,一旦收到CNP包,就会对指定QP进行降速。除此之外,它还维持一个叫做α的参数,它反映了网络中的拥塞度,用于降速计算。
该算法通过三个并行的流程来定义:
- α更新(测量拥塞度)
- 降速
- 提速
7.1 α更新
时间被切分为可配置的时间间隙。每个时间间隙指示是否有CNP在该时间间隙内到达。α参数是一个不断变化的平均值,它是CNP到达的时间间隙的比例(如果同一个时间间隙内不止一个CNP到达,与只有一个CNP到达效果一样)。每个时间间隙结束时,α通过后面的式子更新:new_α = g * old_α + (1 - g) * CNP_arrived, 这里g是一个介于0和1的常量参数,CNP_arrived是一个比特位的域,用来指示在上个时间间隙内是否有CNP到达。
7.2 降速
时间被切分为可配置的时间间隙(不同于α更新的间隙)。如果CNP在上个时间间隙到达(在同一个时间间隙内不止一个CNP到达时,后面的CNP不会产生指示),QP的速率通过后面的式子来减少:new_rate = old_rate * (1 - α / 2),同时将用于提速的几个参数重置。
7.3 提速
提速逻辑和QCN定义的非常相似。该逻辑划分为三个顺序的阶段:快速恢复,积极增加(保持探测),超积极增加(保持探测)。
从一个阶段移向下一个阶段是通过在该阶段中统计到的提速事件数量参数定义的。在一个阶段中提速事件的数量超过预定义的门限值后,逻辑移向下一个阶段。降速事件会重置所有和提速相关的计数器,并且返回到快速恢复阶段。除此之外,一旦提速后,在降速之前,当前的速度会被保存在一个叫target_rate的参数中。
自从上次提速后,在经过预定义的时间间隙或者预定义的发送字节数过程后,如果没有出现降速事件,就会出现提速事件。
处于快速恢复阶段时,面对每个提速事件,速度按照到target_rate的距离的一半来增加(也就是对数接近,current_rate = (current_rate + target_rate) / 2)。这允许在快速恢复阶段的开始能快速恢复到拥塞出现的速度,然后在速度接近拥塞发生的速度时,更谨慎的增加速度。
在后面两个阶段中,一旦出现提速事件,速度都是按照一个常量值来增加。这可以在带宽释放的时候获得吞吐量。
8.总结
这次记录了RoCEv2网络中对于拥塞控制的检测,预防和应对方法。ECN检测和标记是现代数据中心商用交换机普遍具有的功能,它保存在IP头部的查分服务代码点中的两个比特位中。启用ECN功能后,在网络上出现拥塞后,交换机会对ECN域打上CE值,由接收方产生CNP来通知发送方网络拥塞事件。发送方收到CNP指示的事件通知后,根据DC-QCN算法中对当前速度处于快速恢复,积极增加和超积极增加三个阶段中对应的动作来对注入速率进行控制,从而解决网络中的拥塞情况。