?【更多詳細(xì)內(nèi)容，請?jiān)L問星融元官網(wǎng)https://asterfusion.com/】
在上一篇中，我們對RoCE、IB的協(xié)議棧層級進(jìn)行了詳細(xì)的對比分析，二者本質(zhì)沒有不同，但基于實(shí)際應(yīng)用的考量，RoCE在開放性、成本方面更勝一籌。本文我們將繼續(xù)分析RoCE和IB在擁塞控制、QoS、ECMP三個(gè)關(guān)鍵功能中的性能表現(xiàn)。

擁塞控制

擁塞控制即用來減少丟包或者擁塞傳播，是傳輸層的主要功能，但需要借助鏈路層和網(wǎng)絡(luò)層的幫助。

RoCEv2 的擁塞控制機(jī)制

RoCEv2通過鏈路層PFC、網(wǎng)絡(luò)層ECN、傳輸層DCQCN三者協(xié)同配合，實(shí)現(xiàn)更高效的擁塞管理，可見，RoCEv2雖然使用了IB的傳輸層協(xié)議，但在擁塞控制方面有所不同。

基于優(yōu)先級的流量控制（PFC）

PFC在RoCEv2中被用于創(chuàng)建無損的以太網(wǎng)環(huán)境，確保RDMA流量不因鏈路層擁塞而丟失。核心原理是下游控制上游某個(gè)通道開啟和停止發(fā)送數(shù)據(jù)包，控制方式是發(fā)送PFC Pause和Resume幀，觸發(fā)時(shí)機(jī)是根據(jù)下游SW的ingress的隊(duì)列數(shù)量是否達(dá)到某個(gè)閾值。

而PFC允許在一條以太網(wǎng)鏈路上創(chuàng)建8個(gè)虛擬通道，并為每條虛擬通道指定一個(gè)優(yōu)先等級，允許單獨(dú)暫停和重啟其中任意一條虛擬通道，同時(shí)允許其它虛擬通道的流量無中斷通過。這一方法使網(wǎng)絡(luò)能夠?yàn)閱蝹€(gè)虛擬鏈路創(chuàng)建無丟包類別的服務(wù)，使其能夠與同一接口上的其它流量類型共存。

圖1 PFC工作機(jī)制

如圖1所示，DeviceA發(fā)送接口分成了8個(gè)優(yōu)先級隊(duì)列，DeviceB接收接口有8個(gè)接收緩存（buffer），兩者一一對應(yīng)（報(bào)文優(yōu)先級和接口隊(duì)列存在著一一對應(yīng)的映射關(guān)系），形成了網(wǎng)絡(luò)中 8 個(gè)虛擬化通道，緩存大小不同使得各隊(duì)列有不同的數(shù)據(jù)緩存能力。

當(dāng)DeviceB的接口上某個(gè)接收緩存產(chǎn)生擁塞時(shí)，超過一定閾值（可設(shè)定為端口隊(duì)列緩存的 1/2、3/4 等比例），DeviceB即向數(shù)據(jù)進(jìn)入的方向（上游設(shè)備DeviceA）發(fā)送反壓信號“STOP”，如圖中第7個(gè)隊(duì)列。

DeviceA接收到反壓信號，會根據(jù)反壓信號指示停止發(fā)送對應(yīng)優(yōu)先級隊(duì)列的報(bào)文，并將[數(shù)據(jù)存儲]在本地接口緩存。如果DeviceA本地接口緩存消耗超過閾值，則繼續(xù)向上游反壓，如此一級級反壓，直到網(wǎng)絡(luò)終端設(shè)備，從而消除網(wǎng)絡(luò)節(jié)點(diǎn)因擁塞造成的丟包。

顯式擁塞通知（ECN）

ECN（Explicit Congestion Notification）是一種IP頭部用于的擁塞控制的標(biāo)記位，允許網(wǎng)絡(luò)設(shè)備在發(fā)生擁塞時(shí)標(biāo)記數(shù)據(jù)包，而不是丟棄它們。

圖2 IP頭部前4幀示意圖

RoCEv2利用ECN位來標(biāo)記發(fā)生擁塞的數(shù)據(jù)包，接收方在檢測到ECN標(biāo)記后，發(fā)送CNP（Congestion Notification Packet）給發(fā)送方，后者通過擁塞控制算法（如DCQCN）調(diào)整發(fā)送速率。

數(shù)據(jù)中心量化擁塞通知（DCQCN）

DCQCN（Data Center Quantized Congestion Notification）是一種適用于RoCEv2的擁塞控制算法，是數(shù)據(jù)中心TCP(DCTCP)和量化通知算法的結(jié)合，最初在SIGCOMM'15論文"Congestion control for large scale RDMA deployments"中提出。DC-QCN算法依賴于交換機(jī)端的ECN標(biāo)記。結(jié)合了ECN和速率限制機(jī)制，工作在傳輸層。當(dāng)接收方檢測到ECN標(biāo)記時(shí)，觸發(fā)CNP發(fā)送給發(fā)送方，發(fā)送方根據(jù)反饋調(diào)整發(fā)送速率，從而緩解擁塞。

綜上，PFC、ECN、DCQCN分別工作在鏈路層、網(wǎng)絡(luò)層和傳輸層。在RoCEv2中，它們被組合使用，以實(shí)現(xiàn)更高效的擁塞管理。

• PFC ：防止數(shù)據(jù)包在鏈路層被丟棄，提供無損傳輸，解決一段鏈路的問題。
• ECN/DCQCN ：發(fā)送方根據(jù)擁塞標(biāo)記主動調(diào)整發(fā)送速率，減輕網(wǎng)絡(luò)負(fù)載。解決端到端網(wǎng)絡(luò)的問題。

InfiniBand 的擁塞控制機(jī)制

InfiniBand 的擁塞控制機(jī)制可分為三個(gè)主要部分：

基于信用的流量控制

IB在鏈路層實(shí)現(xiàn)基于信用的流量控制（Credit-based Flow Control），該機(jī)制實(shí)現(xiàn)了無損傳輸，是 InfiniBand 高性能的基礎(chǔ)。發(fā)送方根據(jù)接收方提供的信用（表示可用緩沖區(qū)空間）來控制數(shù)據(jù)包的發(fā)送，接收方在處理完數(shù)據(jù)包后發(fā)送信用給發(fā)送方，以允許繼續(xù)發(fā)送新的數(shù)據(jù)包，從而避免網(wǎng)絡(luò)擁塞和數(shù)據(jù)包丟失。

如下圖所示，發(fā)送方當(dāng)前可用信用值2，通過流水線傳輸（pipelined transfer）連續(xù)向接收方發(fā)送數(shù)據(jù)包，但此時(shí)接收方緩沖區(qū)已滿，發(fā)送方會暫停發(fā)送新的數(shù)據(jù)包，直到接收方發(fā)送新的信用。

圖3 基于信用的流量控制示意圖

ECN機(jī)制

當(dāng)網(wǎng)絡(luò)中的交換機(jī)或其他設(shè)備檢測到擁塞時(shí)，會在數(shù)據(jù)包的 IP 頭中標(biāo)記 ECN（Explicit Congestion Notification）。接收方的 CA（Channel Adapter）接收到帶有 ECN 標(biāo)記的數(shù)據(jù)包后，會生成擁塞通知包（CNP），并將其反饋給發(fā)送方，通知其網(wǎng)絡(luò)出現(xiàn)擁塞需要降低傳輸速率。

端到端擁塞控制

發(fā)送方的 CA 在收到 CNP 后，根據(jù) InfiniBand 擁塞控制算法調(diào)整發(fā)送速率。發(fā)送方首先降低數(shù)據(jù)發(fā)送速率以緩解擁塞，之后逐步恢復(fù)發(fā)送速率，直到再次檢測到擁塞信號。這個(gè)動態(tài)調(diào)整過程幫助維持網(wǎng)絡(luò)的穩(wěn)定性和高效性。IBA沒有具體定義特定的擁塞控制算法，通常由廠商定制實(shí)現(xiàn)。（HCA，Host Channel Adapters，or IB NIC）

圖4 端到端擁塞控制示意圖

RoCEv2與IB擁塞控制機(jī)制比較

兩者的擁塞控制機(jī)制比較如下：

可見，RoCE與IB的擁塞控制機(jī)制基本相同，區(qū)別在于IB的擁塞控制機(jī)制集成度較高，通常由單個(gè)廠家提供從網(wǎng)卡到交換機(jī)的全套產(chǎn)品，由于廠商鎖定，價(jià)格高昂。而RoCE的擁塞控制機(jī)制基于開放協(xié)議，可以由不同廠家的網(wǎng)卡和交換機(jī)來配合完成。

隨著大規(guī)模AI訓(xùn)練和推理集群的擴(kuò)展，集合通信流量導(dǎo)致了日益嚴(yán)重的擁塞控制問題，由此出現(xiàn)了一些新的擁塞控制技術(shù)，如基于In-band Network Telemetry (INT)的HPCC（High Precision Congestion Control），即通過精確的網(wǎng)絡(luò)遙測來控制流量，以及基于Clear-to-Send (CTS)的Receiver-driven traffic admission，即通過接收方的流量準(zhǔn)入控制來管理網(wǎng)絡(luò)擁塞等。這些新技術(shù)在開放的以太網(wǎng)/IP網(wǎng)絡(luò)上更容易實(shí)現(xiàn)。

圖5 HPCC流控示意圖

圖6 CTS流控示意圖

QoS

在RDMA網(wǎng)絡(luò)中，不光RDMA流量要獲得優(yōu)先保證。一些控制報(bào)文，如CNP、INT、CTS，也需要特別對待，以便將這些控制信號無損、優(yōu)先的傳輸。

• RoCEv2的QoS

在鏈路層，RoCEv2采用ETS機(jī)制，為不同的流量分配不同的優(yōu)先級，為每個(gè)優(yōu)先級提供帶寬保證。

在網(wǎng)絡(luò)層，RoCEv2則使用DSCP，結(jié)合PQ、WFQ等隊(duì)列機(jī)制，為不同的流量分配不同的優(yōu)先級和帶寬，實(shí)現(xiàn)更精細(xì)的QoS。

圖7 DSCP示意圖

• InfiniBand的QoS

在鏈路層，IB采用SL、VL及它們之間的映射機(jī)制，將高優(yōu)先級的流量分配到專門的VL，優(yōu)先傳輸。雖然VL仲裁表 (VL Arbitration Table)能夠通過分配不同的權(quán)重來影響和控制帶寬的分配，但這種方式不能保證每個(gè)VL的帶寬。

在網(wǎng)絡(luò)層，IB的GRH支持8個(gè)bit的Traffic Class字段，用于在跨子網(wǎng)的時(shí)候提供不同的優(yōu)先級，但同樣無法保證帶寬。

由此可見，RoCE能夠?yàn)椴煌牧髁款愋吞峁└?xì)的QoS 保證和帶寬控制，而 InfiniBand 只能提供優(yōu)先級調(diào)度，而非帶寬的明確保障。

ECMP

RoCE的ECMP

數(shù)據(jù)中心IP網(wǎng)絡(luò)為了高可靠和可擴(kuò)展性，通常采用Spine-Leaf等網(wǎng)絡(luò)架構(gòu)。它們通常在一對RoCE網(wǎng)卡之間提供了多條等價(jià)路徑，為了實(shí)現(xiàn)負(fù)載平衡和提高網(wǎng)絡(luò)拓?fù)涞睦寐剩捎肊CMP（Equal Cost Multiple Paths） 技術(shù)。對于給定的數(shù)據(jù)包，RoCE交換機(jī)使用某些數(shù)據(jù)包字段上的哈希（Hash）值在可能的多條等價(jià)路徑中進(jìn)行選擇。由于可靠傳輸?shù)囊螅粋€(gè)RDMA操作應(yīng)當(dāng)保持在同一個(gè)路徑中，以避免由于不同路徑造成的亂序問題。

在IP網(wǎng)絡(luò)中，BGP/OSPF等協(xié)議均可以在任意拓?fù)渖嫌?jì)算出等價(jià)路徑，然后由交換機(jī)數(shù)據(jù)平面基于IP/ UDP /TCP等頭部字段（如五元組）計(jì)算哈希值并輪流轉(zhuǎn)發(fā)到不同路徑上。在RoCE網(wǎng)絡(luò)中，為了進(jìn)一步細(xì)分RDMA操作，可以進(jìn)一步識別BTH頭部中的目的QP信息，從而實(shí)施更細(xì)粒度的ECMP。

InfiniBand的ECMP

在控制平面，IB的路由基于子網(wǎng)管理器，在拓?fù)浒l(fā)現(xiàn)的基礎(chǔ)上實(shí)現(xiàn)ECMP，但由于集中式的子網(wǎng)管理器與網(wǎng)絡(luò)設(shè)備分離，可能無法及時(shí)感知網(wǎng)絡(luò)拓?fù)涞淖兓M(jìn)而實(shí)現(xiàn)動態(tài)的[負(fù)載均衡] 。

在數(shù)據(jù)平面，IB的ECMP同樣基于哈希計(jì)算和輪轉(zhuǎn)機(jī)制。

總結(jié)

• 在擁塞控制方面，RoCE結(jié)合了PFC, ECN和DCQCN提供了一套開放的方案，IB則擁有基于Credit的一套高度集成的方案，但在應(yīng)對大規(guī)模集合通信流量時(shí)均有所不足。
• 在QoS方面，RoCE可以實(shí)現(xiàn)每個(gè)優(yōu)先級的帶寬保證，而IB僅能實(shí)現(xiàn)高等級的優(yōu)先轉(zhuǎn)發(fā)。
• 在ECMP方面，兩者均實(shí)現(xiàn)了基于Hash的負(fù)載分擔(dān)。

總結(jié)來看，IB具備已驗(yàn)證的高性能和低延時(shí)優(yōu)勢，RoCEv2則在互操作性、開放性、成本效益方面更勝一籌，且從市場占比及認(rèn)可度來看，RoCEv2逐漸比肩IB；但不得不承認(rèn)的是，RoCE和IB在應(yīng)對大規(guī)模AI訓(xùn)練和推理中高帶寬、突發(fā)式和廣播型的集合通信流量時(shí)，均有所不足，而RoCE基于其廣泛的以太網(wǎng)生態(tài)系統(tǒng)，能夠更快速地?fù)肀录夹g(shù)新協(xié)議，其潛力和可塑性更勝一籌，未來有望在網(wǎng)絡(luò)格局中扮演更重要的角色。

參考文檔：

https://zhuanlan.zhihu.com/p/643007675

https://blog.csdn.net/essencelite/article/details/135492115

https://support.huawei.com/enterprise/zh/doc/EDOC1100075566/d1e17776

https://www.researchgate.net/publication/4195833_Congestion_Control_in_InfiniBand_Networks

審核編輯 黃宇