HPCC
HPCC: High Precision Congestion Control 论文阅读
摘要部分和简介
- CC(拥塞控制, 以下都用CC表示)的目标:低延迟,高带宽,网络稳定。但是现有的CC算法在大规模高速RDMA网络上实现这些目标具有潜在限制。
- 提出HPCC,利用网络内遥测(INT, in-Network teletry)来获得 (1) 精确的链路负载信息 (2) 精确控制交通
- 针对面临延迟INT信息以及对INT过度反应的挑战,HPCC可以快速收敛以利用限制带宽,维护很短的网络队列。并且容易在硬件上进行部署。
- 相较于DCQCN和TIMELY, HPCC大幅缩短了流完成时间。
简介
-
三个目标:低时延,高带宽,网络稳定。
-
基于RoCE2协议部署的RDMA网络仍然无法达到上述三个目标,主要是因为会遇到以下困难:
- PFC(优先流控制风暴)。
- incast 事件:分布式系统或数据中心网络中,多个发送者同时向一个接收者发送大量数据的情况。这种通信模式被称为many-to-one(多对一),在云计算应用中非常常见,尤其是在分布式存储和计算应用中,例如Hadoop、MapReduce和HDFS等。
- PFC暂停帧:Priority Flow Control (PFC) 是一种基于优先级的流量控制机制,它允许网络设备在拥塞时只暂停特定优先级的流量。PFC的工作原理是将网络流量分为不同的优先级,每个优先级都有自己的队列。当某个优先级的队列长度超过预设的阈值时,下游设备会向上游设备发送一个 PFC Pause 帧,要求上游设备暂停发送该优先级的流量。这样,只有拥塞优先级的流量被暂停,而其他优先级的流量可以继续传输,从而避免了整个链路的流量被暂停,提高了网络的效率。
- 在大流量的网络中,incast事件会导致长期的pfc风暴。因此我们需要调整拥塞算法来减少风险(限制和避免pfc暂停)。但是这样会导致链路利用率过低。
- 长时间延迟。由于一个云端存储系统导致的入网队列过长,影响到了不对带宽有很大要求的应用,导致时延过长。
- PFC(优先流控制风暴)。
-
需要一个好的拥塞算法以避免pfc和包重传以增加稳定性和减少损失。现有的DCQCN和TIMELY都具有以下三个问题:
- 过低的收敛速度。
- 无法避免的包队列导致时延增加。
- 复杂的参数调整。
-
提出了新的拥塞控制机制HPCC,利用INT中存在的链路负载信息来计算精确的流速率更新。
-
相较于其他的算法,大部分情况下HPCC只需要更新一次。可以为高利用率快速调高速率或为了避免拥塞而快速降低速率。
-
调整流速率来使得输入流量稍微小于链路容量防止链路队伍增加以及保持高链路利用率。
-
参数很少,只有三个参数用于调整公平性和效率。
-
防止盲从INT消息导致过度反应,选择性地结合每个ACK反应和RTT反应选择性地进行响应。
实验和动机
- 说明在大型,高速RDMA网络中的CC算法的限制和困难。
- 给出了下一代控制算法的要求和方向。
RDMA部署
- 数据中心:Clos 拓扑,三层结构: TOR, AGG, 核心交换机。PoD(point of delivery), 拥有10个Tor交换机,相互与Agg交换机相连。每个服务器有两个上行链路,链接两个Tor。
- 采用RoCEv2:DCQCN拥塞控制算法,集成在RDMA NIC供应商网卡中。
- 恢复算法:go back N,回退重传。
目标
- RDMA对资源具有高要求。
- PFC有潜在的巨大且破坏性影响。
- PFC具有抑制大量无辜发送端的情况。
当前RDMA CC算法权衡
- DCQCN
- 利用ECN来发现拥塞风险和快速反应。
- 允许主机在边缘速率快速传输并且在瞬态拥塞后快速提升速率。
- 平衡吞吐和稳定性。
- 平衡带宽和延迟。
下一代高速网络拥塞控制算法目标
- 快速收敛。
- 近0队列。
- 少量参数。
- 流量公平。
- 部署建议。
设计
- 依赖于交换机提供精确的负载信息,例如队列大小,累计传输接收流量等。
- 直接控制流动字节的数量来避免反馈信号延迟而导致的利用率下降。
- 结合RTT和ACK反应来实现快速反应和减少拥塞过度反应。
主要框架
- 发送端驱动的控制拥塞网络框架。
- 在包发送过程中,每一个交换机都会在包后增加INT信息(时间戳,队列长度,传输字节,链路容量等信息。)
- 接收端收到信息后,将这些数据记录在ACK信息中发送回发送端。发送端从ACK中决定如何调整流量。
基于传输数据量控制
- 基于窗的CC算法,控制传输中的人数据流字节数。在没有拥塞的情况下为
. - 发送端通过发送窗口限制传输数据。初始传输
. - 使用数据包节流避免爆发性流量。节流速率R=W/T。W:窗口大小。T:基础RTT。
基于传输数据量的拥塞信号和控制方法
-
与链路利用率直接相关。
-
假设链路带宽B, 第i条经过的流有窗口大小
,那么传输数据量即为 . -
Case I:
。 流的throughput则为 。所有流的总throughput小于链路带宽。 -
Case II:
,存在拥塞,形成了队列。可能是这条链路发生了拥塞,也有可能是在其他的地方出现(存在多个bottleneck) -
目标就是控制I满足情况一,并且仅可能地使得I最大。这样没有拥塞和没有队列。
-
链路流量估计:
-
输出速率计算:
。输出字节差与时间戳之差的比值。 -
假设了相同的RTT,在数据中心中是合理的。
-
存在瓶颈j时,
为下界。 -
发送端要保证满足情况一。因此有
, 。这样对于链路j,可以以 来减小窗口大小, 时标准化的传输流量:
(2)
- 发送端应该对最为拥堵的链路做出反应,
用于保持公平性。
(3)
- 分离了链路利用率控制和公平性控制,可以快速抓取自由带宽或避免拥塞。
- 多瓶颈:多轮迭代解决拥塞问题。单瓶颈:一轮迭代解决问题。
快速反应且避免过度反应
从(2) 和 (3) HPCC的发送端可以对每一个ACK包做出反应,可以实现快速拥塞避免,但是会对描述相同包的ack重复反应。
上图中,P1看到了qLen=4,假设通过方程得到W1=W0/2, 那么对于P2,看到了qLen=4又看到了qLen=4,因此W2=W1/2=W0/4.导致过度反应。
-
当出队的包看见一组全新的包时才进行更新。上例中,P7在发送端收到P1的ACK后才发出,这样其后面的队列与P1完全不同。因此仅在收到上一次窗口调整后立即发出的包的ACK后才进行窗口调整。缺点是每次RTT才调整一次窗口可能对于处理紧急情况(错误,incast)事件来讲太慢。
-
结合ACK与RTT方法一起进行调整。当ACK包收到时,我们更新
,用当前的窗口长度更新参考的窗口长度。然后通过递归的方式更新当前窗口长度:
这样在上图的情况下,收到P2的ACK时,参考窗口长度不会发生变化。因此我们不会进行更新,所以
算法框架如下:
三个参数
95%初始值,减少带宽损失。 :平衡获得自由带宽的速度以及带宽的稳定性。 控制最大并发流在一个链路上的数量,可以维持近0队列以及收敛到公平的速度。
HPCC 性质
- 参数少。
- 采用txRate,更好地衡量传输中的数据量,rxRate则没有具体的物理意义,并且与qlen具有重叠。所以XCP和RCP将会合并基于Qlen和rxRate的项来对参数进行微调。txRate可以反应rxRate在队列中一个RTT后的结果。
- txRate收敛稳定,无震荡。
部署
INT在交换机上的填充
UDP报文后进行填充。
- nhop: 跳跃个数。
- pathID: 所有的路由器的ID的异或值,判断路径变化。
- 第一跳数据端:B:出口端口速率。TS:包离开出口端口时间戳,txBytes:累计流量。qLen:出口端口队列长度。
- 硬件优化:除法优化。查找表的方式进行。
- 支持许多并行流量。时钟引擎限制了并行流的数量,采用RR方式。采用了多个独立的引擎来调度多个独立的流量。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 全程不用写代码,我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· DeepSeek 开源周回顾「GitHub 热点速览」
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了