還有在機(jī)器學(xué)習(xí)和AI的技術(shù)趨勢(shì)下，對(duì)計(jì)算能力的需求是呈幾何級(jí)數(shù)上升的，為了滿足日益復(fù)雜的神經(jīng)網(wǎng)絡(luò)和深度學(xué)習(xí)模型，數(shù)據(jù)中心會(huì)存在大量的分布式計(jì)算集群，但大量并行程序的通訊延遲，則會(huì)極大影響整個(gè)計(jì)算過(guò)程的效率。

另外為了解決數(shù)據(jù)中心內(nèi)爆炸式增長(zhǎng)的數(shù)據(jù)存儲(chǔ)和讀取效率問(wèn)題，利用以太網(wǎng)融合組網(wǎng)的分布式存儲(chǔ)越來(lái)越受到歡迎。但因?yàn)榇鎯?chǔ)網(wǎng)絡(luò)中數(shù)據(jù)流以大象流為主，所以一旦因擁塞造成丟包，將會(huì)引發(fā)大象流重傳，不僅降低效率，還會(huì)加重?fù)砣?/p>

所以從前端用戶的體驗(yàn)和后端應(yīng)用的效率來(lái)看，眼下對(duì)于數(shù)據(jù)中心網(wǎng)絡(luò)的要求是：延遲越低越好，效率越高越好。

為了降低數(shù)據(jù)中心內(nèi)部網(wǎng)絡(luò)延遲，提高處理效率，RDMA技術(shù)應(yīng)運(yùn)而生，通過(guò)允許用戶態(tài)的應(yīng)用程序直接讀取和寫入遠(yuǎn)程內(nèi)存，而無(wú)需CPU介入多次拷貝內(nèi)存，并可繞過(guò)內(nèi)核直接向網(wǎng)卡寫數(shù)據(jù)，實(shí)現(xiàn)了高吞吐量、超低時(shí)延和低CPU開(kāi)銷的效果。

當(dāng)前RDMA在以太網(wǎng)上的傳輸協(xié)議是RoCEv2，RoCEv2是基于無(wú)連接協(xié)議的UDP協(xié)議，相比面向連接的TCP協(xié)議，UDP協(xié)議更加快速、占用CPU資源更少，但其不像TCP協(xié)議那樣有滑動(dòng)窗口、確認(rèn)應(yīng)答等機(jī)制來(lái)實(shí)現(xiàn)可靠傳輸，一旦出現(xiàn)丟包，依靠上層應(yīng)用檢查到了再做重傳，會(huì)大大降低RDMA的傳輸效率。

所以要想發(fā)揮出RDMA真正的性能，突破數(shù)據(jù)中心大規(guī)模分布式系統(tǒng)的網(wǎng)絡(luò)性能瓶頸，勢(shì)必要為RDMA搭建一套不丟包的無(wú)損網(wǎng)絡(luò)環(huán)境，而實(shí)現(xiàn)不丟包的關(guān)鍵就是解決網(wǎng)絡(luò)擁塞。

為什么會(huì)產(chǎn)生擁塞

產(chǎn)生擁塞的原因有很多，下面列舉了在數(shù)據(jù)中心場(chǎng)景里比較關(guān)鍵也是比較常見(jiàn)的三點(diǎn)原因：

收斂比

進(jìn)行數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)設(shè)計(jì)時(shí)，從成本和收益兩方面來(lái)考慮，多數(shù)會(huì)采取非對(duì)稱帶寬設(shè)計(jì)，即上下行鏈路帶寬不一致，交換機(jī)的收斂比簡(jiǎn)單說(shuō)就是總的輸入帶寬除以總的輸出帶寬。以銳捷萬(wàn)兆交換機(jī)RG-S6220-48XS6QXS-H為例，下行可供服務(wù)器輸入的帶寬是48*10G=480G，上行輸出的帶寬是6*40G=240G，整機(jī)收斂比為2:1。而25G交換機(jī)RG-S6510-48VS8CQ，下行可供服務(wù)器輸入的帶寬是48*25G=1200G，上行輸出的帶寬是8*100G=800G，整機(jī)收斂比是1.5:1。

也就是說(shuō)，當(dāng)下聯(lián)的服務(wù)器上行發(fā)包總速率超過(guò)上行鏈路總帶寬時(shí)，就會(huì)在上行口出現(xiàn)擁塞。

說(shuō)PFC之前，我們可以先看一下IEEE 802.3X（Flow Control）流控的機(jī)制：當(dāng)接收者沒(méi)有能力處理接收到的報(bào)文時(shí)，為了防止報(bào)文被丟棄，接收者需要通知報(bào)文的發(fā)送者暫時(shí)停止發(fā)送報(bào)文。

如下圖所示，端口G0/1和G0/2以1Gbps速率轉(zhuǎn)發(fā)報(bào)文時(shí)，端口F0/1將發(fā)生擁塞。為避免報(bào)文丟失，開(kāi)啟端口G0/1和G0/2的Flow Control功能。

▲端口產(chǎn)生擁塞的打流模型

當(dāng)F0/1在轉(zhuǎn)發(fā)報(bào)文出現(xiàn)擁塞時(shí)，交換機(jī)B會(huì)在端口緩沖區(qū)中排隊(duì)報(bào)文，當(dāng)擁塞超過(guò)一定閾值時(shí)，端口G0/2向G0/1發(fā)PAUSE幀，通知G0/1暫時(shí)停止發(fā)送報(bào)文。

G0/1接收到PAUSE幀后暫時(shí)停止向G0/2發(fā)送報(bào)文。暫停時(shí)間長(zhǎng)短信息由PAUSE幀所攜帶。交換機(jī)A會(huì)在這個(gè)超時(shí)范圍內(nèi)等待，或者直到收到一個(gè)Timeout值為0的控制幀后再繼續(xù)發(fā)送。

IEEE 802.3X協(xié)議存在一個(gè)缺點(diǎn)：一旦鏈路被暫停，發(fā)送方就不能再發(fā)送任何數(shù)據(jù)包，如果是因?yàn)槟承﹥?yōu)先級(jí)較低的數(shù)據(jù)流引發(fā)的暫停，結(jié)果卻讓該鏈路上其他更高優(yōu)先級(jí)的數(shù)據(jù)流也一起被暫停了，其實(shí)是得不償失的。

如下圖中報(bào)文解析所示，PFC在基礎(chǔ)流控IEEE 802.3X基礎(chǔ)上進(jìn)行擴(kuò)展，允許在一條以太網(wǎng)鏈路上創(chuàng)建8個(gè)虛擬通道，并為每條虛擬通道指定相應(yīng)優(yōu)先級(jí)，允許單獨(dú)暫停和重啟其中任意一條虛擬通道，同時(shí)允許其它虛擬通道的流量無(wú)中斷通過(guò)。

▲PFC協(xié)議報(bào)文結(jié)構(gòu)解析

PFC將流控的粒度從物理端口細(xì)化到8個(gè)虛擬通道，分別對(duì)應(yīng)Smart NIC硬件上的8個(gè)硬件發(fā)送隊(duì)列（這些隊(duì)列命名為Traffic Class，分別為TC0,TC1,...,TC7），在RDMA不同的封裝協(xié)議下，也有不同的映射方式。

RoCEv1

這個(gè)協(xié)議是將RDMA數(shù)據(jù)段封裝到以太網(wǎng)數(shù)據(jù)段內(nèi)，再加上以太網(wǎng)的頭部，因此屬于二層數(shù)據(jù)包。為了對(duì)它進(jìn)行分類，只能使用VLAN（IEEE 802.1q）頭部中的PCP(Priority Code Point)域3 Bits來(lái)設(shè)置優(yōu)先級(jí)值。

簡(jiǎn)單來(lái)說(shuō)，在二層網(wǎng)絡(luò)的情況下，PFC使用VLAN中的PCP位來(lái)對(duì)數(shù)據(jù)流進(jìn)行區(qū)分，在三層網(wǎng)絡(luò)的情況下，PFC既可以使用PCP、也可以使用DSCP，使得不同數(shù)據(jù)流可以享受到獨(dú)立的流控制。當(dāng)下數(shù)據(jù)中心因多采用三層網(wǎng)絡(luò)，因此使用DSCP比PCP更具有優(yōu)勢(shì)。

PFC死鎖

雖然PFC能夠通過(guò)給不同隊(duì)列映射不同優(yōu)先級(jí)來(lái)實(shí)現(xiàn)基于隊(duì)列的流控，但同時(shí)也引入了新的問(wèn)題，例如PFC死鎖的問(wèn)題。

PFC死鎖，是指當(dāng)多個(gè)交換機(jī)之間因微環(huán)路等原因同時(shí)出現(xiàn)擁塞,各自端口緩存消耗超過(guò)閾值，而又相互等待對(duì)方釋放資源，從而導(dǎo)致所有交換機(jī)上的數(shù)據(jù)流都永久阻塞的一種網(wǎng)絡(luò)狀態(tài)。

正常情況下，當(dāng)一臺(tái)交換機(jī)的端口出現(xiàn)擁塞并觸發(fā)XOFF水線時(shí)，數(shù)據(jù)進(jìn)入的方向（即下游設(shè)備）將發(fā)送PAUSE幀反壓，上游設(shè)備接收到PAUSE幀后停止發(fā)送數(shù)據(jù)，如果其本地端口緩存消耗超過(guò)閾值，則繼續(xù)向上游反壓。如此一級(jí)級(jí)反壓，直到網(wǎng)絡(luò)終端服務(wù)器在PAUSE幀中指定Pause Time內(nèi)暫停發(fā)送數(shù)據(jù)，從而消除網(wǎng)絡(luò)節(jié)點(diǎn)因擁塞造成的丟包。

但在特殊情況下，例如發(fā)生鏈路故障或設(shè)備故障時(shí)，BGP路由重新收斂期間可能會(huì)出現(xiàn)短暫環(huán)路，會(huì)導(dǎo)致出現(xiàn)一個(gè)循環(huán)的緩沖區(qū)依賴。如下圖所示，當(dāng)4臺(tái)交換機(jī)都達(dá)到XOFF水線，都同時(shí)向?qū)Χ税l(fā)送PAUSE幀，這個(gè)時(shí)候該拓?fù)渲兴薪粨Q機(jī)都處于停流狀態(tài)，由于PFC的反壓效應(yīng)，整個(gè)網(wǎng)絡(luò)或部分網(wǎng)絡(luò)的吞吐量將變?yōu)榱恪?br /> 

利用ECN實(shí)現(xiàn)端到端的擁塞控制

當(dāng)前的RoCE擁塞控制依賴ECN(Explicit Congestion Notification，顯式擁塞通知)來(lái)運(yùn)行。ECN最初在RFC 3168中定義，網(wǎng)絡(luò)設(shè)備會(huì)在檢測(cè)到擁塞時(shí)，通過(guò)在IP頭部嵌入一個(gè)擁塞指示器和在TCP頭部嵌入一個(gè)擁塞確認(rèn)實(shí)現(xiàn)。

RoCEv2標(biāo)準(zhǔn)定義了RoCEv2擁塞管理(RCM)。啟用了ECN之后，網(wǎng)絡(luò)設(shè)備一旦檢測(cè)到RoCEv2流量出現(xiàn)了擁塞，會(huì)在數(shù)據(jù)包的IP頭部ECN域進(jìn)行標(biāo)記。

▲IP報(bào)文頭ECN字段結(jié)構(gòu)

這個(gè)擁塞指示器被目的終端節(jié)點(diǎn)按照BTH(Base Transport Header，存在于IB數(shù)據(jù)段中)中的FECN擁塞指示標(biāo)識(shí)來(lái)解釋意義。換句話說(shuō)，當(dāng)被ECN標(biāo)記過(guò)的數(shù)據(jù)包到達(dá)它們?cè)疽竭_(dá)的目的地時(shí)，擁塞通知就會(huì)被反饋給源節(jié)點(diǎn)，源節(jié)點(diǎn)再通過(guò)對(duì)有問(wèn)題的Queue Pairs（QP）進(jìn)行網(wǎng)絡(luò)數(shù)據(jù)包的速率限制來(lái)回應(yīng)擁塞通知。

ECN交互過(guò)程

▲ECN交互過(guò)程示意圖

• 發(fā)送端發(fā)送的IP報(bào)文標(biāo)記支持ECN（10）；

• 交換機(jī)在隊(duì)列擁塞情況下收到該報(bào)文，將ECN字段修改為11并發(fā)出，網(wǎng)絡(luò)中其他交換機(jī)將透?jìng)鳎?/p>

• 接收端收到ECN為11的報(bào)文發(fā)現(xiàn)擁塞，正常處理該報(bào)文；

• 接收端產(chǎn)生擁塞通告，每ms級(jí)發(fā)送一個(gè)CNP（Congestion Notification Packets）報(bào)文，ECN字段為01，要求報(bào)文不能被網(wǎng)絡(luò)丟棄。接收端對(duì)多個(gè)被ECN標(biāo)記為同一個(gè)QP的數(shù)據(jù)包發(fā)送一個(gè)單個(gè)CNP即可（格式規(guī)定見(jiàn)下圖）；

• 交換機(jī)收到CNP報(bào)文后正常轉(zhuǎn)發(fā)該報(bào)文；

• 發(fā)送端收到ECN標(biāo)記為01的CNP報(bào)文解析后對(duì)相應(yīng)的流（對(duì)應(yīng)啟用ECN的QP）應(yīng)用速率限制算法。

RoCEv2的CNP包格式如下：

▲CNP報(bào)文結(jié)構(gòu)

值得注意的是，CNP作為擁塞控制報(bào)文，也會(huì)存在延遲和丟包，從發(fā)送端到接收端經(jīng)過(guò)的每一跳設(shè)備、每一條鏈路都會(huì)有一定的延遲，會(huì)最終加大發(fā)送端接收到CNP的時(shí)間，而與此同時(shí)交換機(jī)端口下的擁塞也會(huì)逐步增多，若發(fā)送端不能及時(shí)降速，仍然可能造成丟包。建議擁塞通告域的規(guī)模不要過(guò)大，從而避免因?yàn)镋CN控制報(bào)文交互回路的跳數(shù)過(guò)多，而影響發(fā)送端無(wú)法及時(shí)降速，造成擁塞。

總結(jié)

RDMA網(wǎng)絡(luò)正是通過(guò)在網(wǎng)絡(luò)中部署PFC和ECN功能來(lái)實(shí)現(xiàn)無(wú)損保障。PFC技術(shù)讓我們可以對(duì)鏈路上RDMA專屬隊(duì)列的流量進(jìn)行控制，并在交換機(jī)入口（Ingress port）出現(xiàn)擁塞時(shí)對(duì)上游設(shè)備流量進(jìn)行反壓。利用ECN技術(shù)我們可以實(shí)現(xiàn)端到端的擁塞控制，在交換機(jī)出口（Egress port）擁塞時(shí)，對(duì)數(shù)據(jù)包做ECN標(biāo)記，并讓流量發(fā)送端降低發(fā)送速率。

從充分發(fā)揮網(wǎng)絡(luò)高性能轉(zhuǎn)發(fā)的角度，我們一般建議通過(guò)調(diào)整ECN和PFC的buffer水線，讓ECN快于PFC觸發(fā)，即網(wǎng)絡(luò)還是持續(xù)全速進(jìn)行數(shù)據(jù)轉(zhuǎn)發(fā)，讓服務(wù)器主動(dòng)降低發(fā)包速率。如果還不能解決問(wèn)題，再通過(guò)PFC讓上游交換機(jī)暫停報(bào)文發(fā)送，雖然整網(wǎng)吞吐性能降低，但是不會(huì)產(chǎn)生丟包。

在數(shù)據(jù)中心網(wǎng)絡(luò)中應(yīng)用RDMA，不僅要解決轉(zhuǎn)發(fā)面的無(wú)損網(wǎng)絡(luò)需求，還要關(guān)注精細(xì)化運(yùn)維，才能應(yīng)對(duì)延遲和丟包敏感的網(wǎng)絡(luò)環(huán)境。有關(guān)MMU的精細(xì)化管理技術(shù)以及基于INT的網(wǎng)絡(luò)可視化技術(shù)可參考往期文章。