它在端口#xff08;或端口加优先级#xff09;级别上运行#xff0c;并且不区分流。

PAUSE机制是基于每个端口#xff08;和优先级#xff09;的#xff0c;而不是基于每个流…

本文主要解决的问题是在RoCEv2体系中基于优先级的拥塞控制PFC是一种粗粒度的机制。

它在端口或端口加优先级级别上运行并且不区分流。

PAUSE机制是基于每个端口和优先级的而不是基于每个流的。

flow等问题。

为了解决这个问题作者提出了DCQCN机制DCQCN提供快速收敛以达到公平性实现高链路利用率确保低队列建立和低队列振荡。

现实计算机网络中的通信场景中主要是以发送小消息为主因此处理延迟是提升性能的关键。

TCP/IP

网络通信数据需要通过用户空间发送到远程机器的用户空间在这个过程中需要经历若干次内存拷贝

RDMA

为了消除传统网络通信带给计算任务的瓶颈我们希望更快和更轻量级的网络通信由此提出了RDMA技术。

RDMA利用

Kernel

Copy技术提供了低延迟的特性同时减少了CPU占用减少了内存带宽瓶颈提供了很高的带宽利用率。

RDMA提供了给基于

的通道这种通道允许一个应用程序通过RDMA设备对远程的虚拟内存进行直接的读写。

RDMA

Offload无需CPU干预应用程序可以访问远程主机内存而不消耗远程主机中的任何CPU。

远程主机内存能够被读取而不需要远程主机上的进程或CPU)参与。

远程主机的CPU的缓存(cache)不会被访问的内存内容所填充

Kernel

interface。

应用程序可以直接在用户态执行数据传输不需要在内核态与用户态之间做上下文切换

Zero

Copy每个应用程序都能直接访问集群中的设备的虚拟内存这意味着应用程序能够直接执行数据传输在不涉及到网络软件栈的情况下数据能够被直接发送到缓冲区或者能够直接从缓冲区里接收而不需要被复制到网络层。

RoCE协议存在RoCEv1

RRoCE两个版本主要区别RoCEv1是基于以太网链路层L2实现的RDMA协议(交换机需要支持PFC等流控技术在物理层保证可靠传输)而RoCEv2是以太网TCP/IP协议中UDP层(L3)实现。

Queues

RDMA一共支持三种队列发送队列(SQ)和接收队列(RQ)完成队列(CQ)。

其中SQ和RQ通常成对创建被称为Queue

工作队列包括发送队列(SQ)和接收队列(RQ)。

工作队列的每一个元素叫做WQE,

也就是WC。

具有RDMA引擎的硬件(hardware)就是一个队列元素处理器。

RDMA硬件不断地从工作队列(WQ)中去取工作请求(WR)来执行执行完了就给完成队列(CQ)中放置工作完成(WC)。

Motivation

TCP堆栈不能以低CPU开销和超低延迟提供高带宽而RoCEv2上的RDMA可以提供。

接下来我们证明PFC会损害RoCEv2的性能现有的解决PFC问题的解决方案不适合当前的需求。

Conventional

现在比较RoCEv2和传统TCP堆栈的吞吐量CPU开销和延迟。

Throughput

为了测量TCP吞吐量我们使用为我们的环境定制的发包测试工具。

具体来说启用LSO、RSS和zero-copy操作并使用16个线程。

RDMA:

READ操作来传输数据的自定义工具。

使用RDMA单个线程使链路饱和。

例如消息大小为4MB以驱动全部吞吐量TCP在所有内核上平均消耗20以上的CPU周期。

在较小的消息大小下由于CPU成为瓶颈TCP无法使连接传输饱和。

Linux的TCP性能同样差使用的用户级堆栈也会消耗20以上的CPU周期。

相反即使对于较小的消息大小RDMA客户端的CPU利用率也低于3。

Latency

现在我们比较使用TCP和RDMA传输2K消息的平均用户级别延迟。

使用高分辨率计时器≤1

**在网络交换机中当入口流量大于出口流量的带宽时会发生网络拥塞。

**典型的例子是多个发送方同时向同一个目的地发送网络数据。

交换机的缓存可以处理暂时的拥塞但是当拥塞太久时交换机的缓存就会过载。

当交换机缓存过载时下一个收到的新的数据包就会被丢弃。

丢包会降低应用性能因为重传和传输协议的复杂性会带来延迟。

在网络交换机中当入口流量大于出口流量的带宽时会发生网络拥塞。

典型的例子是多个发送方同时向同一个目的地发送网络数据。

交换机的缓存可以处理暂时的拥塞但是当拥塞太久时交换机的缓存就会过载。

当交换机缓存过载时下一个收到的新的数据包就会被丢弃。

丢包会降低应用性能因为重传和传输协议的复杂性会带来延迟。

无损网络实现了流控制机制它可以在缓存溢出前暂停入口流量阻止了丢包现象。

然而流控制本身会造成拥塞传播的问题。

为了理解拥塞传播问题考虑下面的图示。

假设交换机1上的端口A到E都在向端口G发送网络数据包以至于端口G以100%的能力来接收数据并且转发。

假设毗邻的交换机2端口F也在向交换机1的端口G发送数据速率是整个链路带宽的20%。

因为端口G的出口已经满载了端口F将会重传数据包直到被流控制机制暂停。

此时端口G将会出现拥塞然而此时没有负效应因为所有的端口都会被端口G尽快的服务。

现在考虑交换机2上的一个端口X以链路带宽的20%速度向交换机1上的端口Y发送数据。

端口G这个拥塞源并不处于端口X到端口Y的路径上。

这种情况下你也许会认为端口F只使用了交换机间链路的20%带宽剩余的80%带宽对于端口X是可用的。

然而并非如此因为来自端口F的流量最终触发流控制机制使得交换机间的链路处于暂停发送并且将来自端口X的流量降为20%而不是潜在可用的80%带宽。

拥塞控制

拥塞控制用来减少有损网络中的丢包现象或者无损网络中的拥塞传播现象。

它也减少交换机缓存的占用进而减少了延迟和改善突发流量的容忍度。

**使用的方法是限制导致拥塞根本原因的端口(A-F)的网络流注入速率因此其他端口(X)发来的网络流就不会被影响。

**通过限制端口A-F的注入速率为端口G可以处理的速率端口A-F不应该观察到明显的性能下降(毕竟它们的数据包无论如何也要等待)然而从端口X到端口Y发送的数据包应该能够正常的转发因为流控制机制不会发送暂停帧(拥塞控制目的是保持交换机的缓存占用率低因此流控制机制就不会被触发)。

Congestion

Control)流控的机制当接收者没有能力处理接收到的报文时为了防止报文被丢弃接收者需要通知报文的发送者暂时停止发送报文。

如下图所示端口G0/1和G0/2以1Gbps速率转发报文时端口F0/1将发生拥塞。

为避免报文丢失开启端口G0/1和G0/2的Flow

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

G0/1接收到PAUSE帧后暂时停止向G0/2发送报文。

暂停时间长短信息由PAUSE帧所携带。

交换机A会在这个超时范围内等待或者直到收到一个Timeout值为0的控制帧后再继续发送。

FCIEEE

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

PFC

Control基于优先级的流量控制**是目前应用最广泛的能够有效避免丢包的流量控制技术是智能无损网络的基础。

使能了PFC功能的队列我们称之为无损队列。

当下游设备的无损队列发生拥塞时下游设备会通知上游设备会停止发送该队列的流量从而实现零丢包传输。

最基本的流量控制技术是以太Pause机制当网络中的下游设备发现其流量接收能力小于上游设备的发送能力时会主动发Pause帧给上游设备要求上游设备暂停流量发送等待一段时间后再继续发送。

但是以太Pause机制是将链路上所有的流量都暂停即流量暂停是针对整个接口。

而对实际业务而言链路共享至关重要链路共享要求

一种类型的突发流量不能影响其他类型流量的转发。

一种类型的流量即使大量积压在队列中也不能抢占其他类型流量的队列资源。

PFC是一种基于优先级的流量控制技术PFC在基础流控FC基础上进行扩展允许在一条以太网链路上创建8个虚拟通道并为每条虚拟通道指定相应优先级允许单独暂停和重启其中任意一条虚拟通道同时允许其它虚拟通道的流量无中断通过。

如图所示DeviceA发送接口被分成了8个优先级队列DeviceB接收接口则存在8个接收缓存二者一一对应。

DeviceB接收接口上某个接收缓存发生拥塞时会发送一个反压信号“STOP”到DeviceADeviceA则停止发送对应优先级队列的流量。

所以PFC解决了现有以太Pause机制和链路共享之间的冲突流量控制只针对某一个或几个优先级队列而不是整个接口的流量全部中断。

每个队列都能单独暂停或重启流量发送而不影响其他队列真正实现多种流量共享链路。

RoCE拥塞控制

3168文档为TCP/IP协议所定义它通过在IP头部嵌入一个拥塞指示器和在TCP头部嵌入一个拥塞确认实现。

兼容ECN的交换机和路由器会在检测到拥塞时对网络数据包打标记。

IP头部的拥塞指示也可以用于RoCEv2的拥塞控制。

下面是IP头部的前四个帧的格式

RoCEv2

RoCEv2标准定义了RoCEv2拥塞管理(RCM)。

RCM提供了避免拥塞热点和优化链路吞吐量的能力。

启用了RCM后链路上早期的拥塞会被汇报给网络流的源然后网络流的源会降低它们的注入速率因此防止了链路上的缓存饱和与增加排队延迟带来的负面效果。

拥塞管理与共存的TCP/UDP/IP流量也是相关的。

然而假设对RoCEv2和其他流量使用了不同优先级每个优先级都有一个带宽分配拥塞和拥塞反映(指网络源针对拥塞采取的动作)效果不应该互相影响。

3168中定义的ECN机制。

一旦RoCEv2流量出现了拥塞网络设备在数据包的IP头部对ECN域进行标记。

这个拥塞指示器被目的终端节点按照BTH(Base

Transport

Header存在于IB数据段中)中的FECN拥塞指示标识来解释意义。

换句话说当被ECN标记过的数据包到达它们原本要到达的目的地时拥塞通知就会被反馈给源节点源节点再通过对有问题的QP进行网络数据包的速率限制来回应拥塞通知。

RCM是一个可选的规范行为。

实现了RCM的RoCEv2主机通道适配器应该按照下面的规则来运行

当收到一个有效的RoCEv2数据包时它的IP.ECN域的值如果是’11’(二进制)那么这个主机通道适配器应该产生一个RoCEv2的CNP送回给所收到的包的源节点(格式规定如下)。

这个主机通道适配器应该对多个被ECN标记为同一个QP的的数据包发送一个单个CNP即可。

当收到一个RoCEv2的CNP时主机通道适配器应该对RoCEv2

CNP中标记的QP实施减缓注入速率。

这个速率变化总量由一个可配置的速率减缓参数来决定。

当被ECN标记的QP自从最近收到的RoCEv2

CNP包开始经过了一个可配置的暂停时长或者超过一个已经发送的可配置的字节数之后主机通道支配器应该增加该QP的网络注入速率。

Unfairness

1。

b图队列达到了PFC的阈值交换机暂停了Ingress1和Ingress2的发送。

c图收到了恢复帧并且开始重新发送包。

此时f2和f3构成竞争关系而f1独占Ingress

由于pause导致的数据报文堆积在resume了之后由于交换机的调度机制会导致瞬时的不均衡

Victim

1发生了拥塞而本来应该正常传输的流f2由于暂停帧的原因也被迫停止了。

此时流f2被称作Victim

Existing

PFC问题的根本解决方案是使用流量级别flow-level的拥塞控制。

如果对每个流应用适当的拥塞控制则很少触发PFC因此可以避免本节前面所述的问题。

它的值取决于瞬时队列大小和所需均衡队列大小之间的差异以及其他因素。

然后交换机可能概率取决于拥塞的严重程度将拥塞度量的量化值作为反馈发送到到达数据包的源。

由于在没有拥塞的情况下不会发送任何反馈因此发送方使用内部计时器和计数器来提高其发送速率。

**由于在没有拥塞的情况下不会发送任何反馈因此发送方使用内部计时器和计数器来提高其发送速率。

在IP路由网络中当数据包通过网络传输时原始的以太网报头不会保留。

考虑将QCN协议扩展到IP路由网络。

需要使用IP五元组作为流标识符并在拥塞通知数据包中添加IP和UDP标头以使其能够到达正确的目的地。

由于QCN功能已深入集成到ASIC中ASIC供应商实施验证和发布新的交换ASIC通常需要数月甚至数年的时间。

THE

此外我们还希望DCQCN为公平的带宽分配提供快速收敛避免在稳定点附近发生振荡保持较短的队列长度并确保较高的链路利用率。

DC-QCN算法依赖于交换机端的ECN标记。

ECN是商用数据中心交换机的普遍特点。

在数据包IP头部中的查分服务域中的两个比特位用来提示拥塞。

一旦交换机端出现了拥塞这两个比特位就被置为11(CE)。

标记拥塞是队列长度的概率函数如下图所示。

队列长度的两个门限值定义了标记概率。

当队列长度低于门限值下限时ECN位不会被标记。

当队列长度超过门限值上限时所有从该队列传输的网络包都会被进行ECN标记。

当队列长度处于两个门限值之间时数据包会以与队列长度线性增长的概率被进行ECN标记。

带有ECN标记的数据包被传播到接收方的网卡上。

接收方网卡创建一个CNP并把它发送给ECN所标记的数据包的发送方。

CNP数据包包括被标记的QP的信息。

当CNP被发送方网卡收到时它会基于下面描述的算法来降低指定QP的传输速率。

DCQCN算法由发送方反应点RP交换机拥塞点CP和接收方通知点NP组成。

Congestion

当队列长度超过ECN标记阈值时数据包在ECN位上标记其概率与队列长度成比例。

优先流控制PFC

当队列长度超过PFC阈值时PFC数据包将发送到上游端口以阻止它们发送。

Notification

如果一个接收端接收到带有ECN标记的分组则它向流的发送端发送拥塞通知分组a

congestion

CNP并且在下一个固定的时间段内例如50微秒它将不再针对相同的流发送CNP。

Reaction

DC-QCN降速算法通过下面的图表来描述。

简而言之如果QP基于内部定时器和发送字节计数器算法会持续的增加发送速率一旦收到CNP包就会对指定QP进行降速。

除此之外它还维持一个叫做α的参数它反映了网络中的拥塞度用于降速计算。

α更新(测量拥塞度)降速提速

时间被切分为可配置的时间间隙。

每个时间间隙指示是否有CNP在该时间间隙内到达。

α参数是一个不断变化的平均值它是CNP到达的时间间隙的比例(如果同一个时间间隙内不止一个CNP到达与只有一个CNP到达效果一样)。

每个时间间隙结束时α通过后面的式子更新new_α

old_α

这里g是一个介于0和1的常量参数CNP_arrived是一个比特位的域用来指示在上个时间间隙内是否有CNP到达。

时间被切分为可配置的时间间隙(不同于α更新的间隙)。

如果CNP在上个时间间隙到达(在同一个时间间隙内不止一个CNP到达时后面的CNP不会产生指示)QP的速率通过后面的式子来减少new_rate

old_rate

提速逻辑和QCN定义的非常相似。

该逻辑划分为三个顺序的阶段快速恢复积极增加(保持探测)超积极增加(保持探测)。

从一个阶段移向下一个阶段是通过在该阶段中统计到的提速事件数量参数定义的。

在一个阶段中提速事件的数量超过预定义的门限值后逻辑移向下一个阶段。

降速事件会重置所有和提速相关的计数器并且返回到快速恢复阶段。

除此之外一旦提速后在降速之前当前的速度会被保存在一个叫target_rate的参数中。

自从上次提速后在经过预定义的时间间隙或者预定义的发送字节数过程后如果没有出现降速事件就会出现提速事件。

处于快速恢复阶段时面对每个提速事件速度按照到target_rate的距离的一半来增加(也就是对数接近current_rate

(current_rate

2)。

这允许在快速恢复阶段的开始能快速恢复到拥塞出现的速度然后在速度接近拥塞发生的速度时更谨慎的增加速度。

在后面两个阶段中一旦出现提速事件速度都是按照一个常量值来增加。

这可以在带宽释放的时候获得吞吐量。

实验结果

图8显示DCQCN解决了图3中描述的不公平问题。

所有四种流都获得相同的瓶颈带宽份额几乎没有差异。

图9显示DCQCN解决了图4中描述的受害者流问题。

对于DCQCN在T3下增加发送者时VSVR流的吞吐量不会发生变化

大规模RDMA部署的一个重要场景是云存储服务的后端网络。

在这样的网络中流量由用户请求以及由相对罕见的事件(如磁盘恢复)产生的流量组成。

为了模拟用户请求流量我们使用从数据中心的单个集群收集的跟踪。

在480台机器的集群上收集了一天的数据包括超过1000万个流量的流量。

提取了跟踪数据的显著特征如流量大小分布并生成合成流量来匹配这些特征。

将磁盘恢复流量建模为入播incast.

为了模拟用户流量每台主机与一个或多个随机选择的主机通信并使用从跟踪得到的分布传输数据。

流量还包括单个磁盘重建事件磁盘重建的入度从2改变到10

性能指标是吞吐量的中位数和尾部(第10个百分位数)。

中位数的提高意味着网络利用率的提高而尾性能的提高导致应用程序性能更可预测进而导致更好的用户体验。

a)和b)

在没有DCQCN的情况下用户流量吞吐量随着cast程度的增加而迅速下降。

这是由于pfc造成的随着度的增加会产生更多的PAUSE消息。

当这些网络级联时它们会对用户流量造成严重破坏。

磁盘重构流量也受益于DCQCN因为DCQCN有助于在竞争流之间公平分配带宽。

度为10时没有DCQCN的第10百分位吞吐量小于1.12Gbps而有DCQCN的第10百分位吞吐量为3.43Gbps。

DCQCN的中位数吞吐量更低。

图16中我们看到DCQCN即使在incast程度上升的情况下也继续为用户流量提供良好的性能。

现在我们将度保持在10并通过将同时通信对的数量从5改变为80来改变使用流量。

在图17(a)中我们看到不使用DCQCN时5个通信对的用户流量性能与使用80个通信对的用户流量性能相匹配。

换句话说使用DCQCN我们可以处理16倍以上的用户流量而不会降低性能。

图17(b)显示使用DCQCN时即使是磁盘重构流量的性能也比不使用DCQCN时更加均匀和公平。

其他算法和应用

TIMELY和Swift算法Google数据中心中使用的拥塞控制算法交换机不需要做额外的支持发送者在主机网卡上对端到端往返延迟RTT进行测量基于RTT的变化进行梯度计算进而根据梯度实现了基于速率rate-based的调速方法。

目前主要是在Google内部使用依赖于Google的自研网卡。

算法思想参考TIMELY:

RTT-based

2020HPCC算法阿里网络研究团队研发出的拥塞控制算法使用INT携带网络拥塞情况发送者在主机网卡侧实现了一种基于窗口window-based的调速方法。

受限于INT的精度、网卡实现的复杂性和对可编程交换机的依赖HPCC目前应该只是停留在论文阶段未有大规模部署。

算法思想参考HPCC:

High

RDMA网卡上拥塞控制算法采取了类似于DCTCP算法的变种算法具体可以参考Data

Center

为了让上层业务更好的使用RDMA带来的高性能业务需要在通讯中间件上做出一定程度的适配。

下面是RDMA在机器学习训练和高性能存储两个领域的通讯中间件情况

RDMA服务于机器学习训练业务主要体现在各种集合通讯库上以NVIDIA的NCCL通讯库最具有代表性当然Facebook也搞出了一个Gloo通讯库。

各家大厂也搞出了一些变种以满足自己AI训练框架的特殊需求

RDMA应用于存储领域也需要通讯中间件可以参考阿里的X-RDMA

参考资料

RDMA_dcqcn论文_MasterT-J的博客-CSDN博客

全面工业级大规模RDMA技术杂谈

论文阅读笔记_dcqcn论文_Scabbard_的博客-CSDN博客