摘要

我們觀察到新興的人工智能、高性能計(jì)算和存儲工作負(fù)載對大規(guī)模數(shù)據(jù)中心網(wǎng)絡(luò)提出了新的挑戰(zhàn)。基于融合以太網(wǎng)的RDMA協(xié)議（RoCE，RDMA over Converged Ethernet） 是將現(xiàn)代的遠(yuǎn)程直接內(nèi)存訪問（RDMA，Remote Direct Memory Access）功能引入現(xiàn)有以太網(wǎng)的一種嘗試。十年過去了，我們重新審視了RoCE的設(shè)計(jì)要點(diǎn)，并得出結(jié)論認(rèn)為必須解決其幾個缺點(diǎn)，以滿足超大規(guī)模數(shù)據(jù)中心的需求。我們預(yù)測，數(shù)據(jù)中心和高性能計(jì)算市場將會融合，并在未來十年內(nèi)采用現(xiàn)代化以太網(wǎng)為基礎(chǔ)的高性能網(wǎng)絡(luò)解決方案，取代TCP和RoCE。

數(shù)據(jù)中心以太網(wǎng)的新環(huán)境

以太網(wǎng)在有線局域網(wǎng)（LAN）領(lǐng)域占據(jù)主導(dǎo)地位已經(jīng)幾十年了，從私人住宅的部署到最大的數(shù)據(jù)中心。在過去的十年里，數(shù)據(jù)中心經(jīng)歷了巨大的增長，連接的機(jī)器數(shù)量超過了目前最大的超級計(jì)算機(jī)規(guī)模。雖然仍然存在一些差異，但這類超大規(guī)模的超級計(jì)算機(jī)和數(shù)據(jù)中心的網(wǎng)絡(luò)需求非常相似[1]。然而，超級計(jì)算機(jī)通常使用專用的互連方式進(jìn)行連接，而數(shù)據(jù)中心則建立在以太網(wǎng)之上。由于相似的需求和規(guī)模經(jīng)濟(jì)效益，隨著每一代新技術(shù)的出現(xiàn)，二者繼續(xù)趨近于融合。我們認(rèn)為現(xiàn)在是重新思考融合互連的基本假設(shè)和架構(gòu)的合適時機(jī)。

多種技術(shù)趨勢加速了高性能互連的融合。主要的是，不斷增加的網(wǎng)絡(luò)性能要求推動了更高效的主機(jī)堆棧的發(fā)展，以支持新興的數(shù)據(jù)密集型應(yīng)用，如人工智能（AI），所需的Tb帶寬、每秒數(shù)億次的事務(wù)和個位數(shù)微秒級的延遲[2]。這些極端需求要求所有的協(xié)議和硬件盡可能高效，排除了許多傳統(tǒng)驅(qū)動數(shù)據(jù)中心網(wǎng)絡(luò)的類似TCP/IP的堆棧。遠(yuǎn)程直接內(nèi)存訪問（RDMA）是近30年來為高性能計(jì)算（HPC）工作負(fù)載開發(fā)的，并且后來擴(kuò)展到目標(biāo)存儲與InfiniBand（IB）Verbs RDMA。RDMA使CPU可以通過網(wǎng)絡(luò)進(jìn)行硬件加速的直接內(nèi)存訪問。在過去的10年里，RDMA成為低開銷和高速網(wǎng)絡(luò)的事實(shí)標(biāo)準(zhǔn)。幾乎所有的超級計(jì)算機(jī)架構(gòu)以及領(lǐng)先的數(shù)據(jù)中心供應(yīng)商都在生產(chǎn)環(huán)境中使用RDMA。

幾十年前確定的負(fù)載平衡、擁塞控制和錯誤處理方面的簡單假設(shè)，對于今天的網(wǎng)絡(luò)來說已經(jīng)不適用，現(xiàn)在的網(wǎng)絡(luò)帶寬高出100倍以上，消息速率高出10倍以上。此外，簡單的RDMA網(wǎng)絡(luò)接口卡（NIC）通常會增加額外的功能。由此產(chǎn)生的“智能NIC”通常會卸載重要服務(wù)并實(shí)現(xiàn)專門的網(wǎng)絡(luò)協(xié)議?，F(xiàn)代網(wǎng)絡(luò)交換機(jī)還具備改進(jìn)的能力，包括先進(jìn)的網(wǎng)絡(luò)遙測、網(wǎng)絡(luò)計(jì)算能力以及網(wǎng)絡(luò)負(fù)載均衡或擁塞控制[3]。我們認(rèn)為當(dāng)前現(xiàn)有的標(biāo)準(zhǔn)和部署基礎(chǔ)設(shè)施存在根本性的差距，必須在不久的將來加以解決，以支持高效的高性能網(wǎng)絡(luò)。

以太網(wǎng)RDMA簡史

RDMA最初是為高性能計(jì)算系統(tǒng)開發(fā)的，早期應(yīng)用包括Paragon、Cray的T3D/T3E和ASCI Red等。后來，InfiniBand Verbs RDMA成為超級計(jì)算領(lǐng)域中的標(biāo)準(zhǔn)解決方案。隨后，在數(shù)據(jù)中心環(huán)境中采用了“RDMA over Converged Ethernet”（RoCE）來在向后兼容的以太網(wǎng)環(huán)境中提供RDMA的優(yōu)勢。另一個協(xié)議iWARP（參見IETF 2007年，RFC 5040-5044、6580、6581、7306）將RDMA語義層置于TCP或SCTCP之上。iWARP和RoCE都使用InfiniBand的Verbs與用戶軟件堆棧進(jìn)行接口，因此對用戶而言基本透明。盡管iWARP一開始就支持互聯(lián)網(wǎng)兼容的路由，但并沒有廣泛采用。這可能是因?yàn)橄鄬τ赗oCE所基于的非常簡單的協(xié)議，一個完整的TCP/IP堆棧在硬件上的卸載是復(fù)雜而昂貴的。事實(shí)上，RoCEv1只是在以太網(wǎng)的L2報(bào)頭之上采用了類似InfiniBand的傳輸層（即Base Transport Header，BTH）。后來，RoCEv2添加了IP/UDP L3報(bào)頭以支持?jǐn)?shù)據(jù)中心內(nèi)部和跨數(shù)據(jù)中心的路由。目前，RoCEv2 NIC的部署數(shù)量超過了InfiniBand NIC。

RoCE - 融合還是臨時應(yīng)急？

RoCE的核心設(shè)計(jì)是繼承自20年前為簡單硬件開發(fā)的技術(shù)，對于今天的以太網(wǎng)環(huán)境來說并不是最優(yōu)解。例如，RoCE使用基于InfiniBand的簡單傳輸層，它在很大程度上依賴于按順序傳遞和回退N（go-back-n）重傳語義，這基本上需要一個高度可靠的按順序傳遞的基礎(chǔ)架構(gòu)才能實(shí)現(xiàn)高效的運(yùn)行。因此，RoCE在無丟包的有序傳輸環(huán)境（如InfiniBand）中運(yùn)行效果最佳。傳統(tǒng)上，以太網(wǎng)在交換機(jī)緩沖區(qū)已滿時會丟棄數(shù)據(jù)包，并依賴端到端的重傳機(jī)制。為了支持RoCE，"融合以太網(wǎng)"（CE，Converged Ethernet）引入了優(yōu)先流控制（PFC，Priority Flow Control）來實(shí)現(xiàn)鏈路級無丟包操作。PFC重新利用了以太網(wǎng)中的PAUSE幀，以支持具有不同鏈路傳輸速率的網(wǎng)絡(luò)。PFC通過增強(qiáng)PAUSE幀來停止（或限制）特定優(yōu)先級類別的流量，以避免數(shù)據(jù)包丟失。不幸的是，這一復(fù)雜的協(xié)議集干擾了網(wǎng)絡(luò)中的不同層次，并降低了對一些當(dāng)今最重要的工作負(fù)載的效率。

RoCE的語義、負(fù)載平衡和擁塞控制機(jī)制都是繼承自InfiniBand。這意味著所有的消息應(yīng)該按照順序到達(dá)目的地，就像它們是通過靜態(tài)路由傳輸一樣，這本質(zhì)上禁止了許多分組級別的負(fù)載平衡機(jī)制。對于長期流程的AI訓(xùn)練工作負(fù)載，多路徑機(jī)制可以極大地提高作業(yè)完成時間。此外，RoCEv2使用基于IP的簡化擁塞控制機(jī)制，基于明確擁塞通知（ECN，Explicit Congestion Notification）的機(jī)制。當(dāng)檢測到擁塞時，ECN兼容的交換機(jī)會標(biāo)記數(shù)據(jù)包，并將該信息傳回接收方，接收方再將其傳遞給發(fā)送方，發(fā)送方根據(jù)一個參數(shù)減少注入速率。在無擁塞期之后，速率會自動增加，使用第二個配置參數(shù)。ECN使用二進(jìn)制標(biāo)志表示經(jīng)歷過擁塞，缺乏細(xì)粒度的指示會導(dǎo)致需要許多往返時間（RTTs，Round Trip Times）來確定正確的速率。這種簡單的機(jī)制與InfiniBand最初的前向和后向明確擁塞通知（FECN/BECN）非常相似。它承諾可以與其它流量共存，但在實(shí)踐中很難進(jìn)行配置[4]，[5]，[6]。

現(xiàn)在我們簡要討論一些高性能計(jì)算（HPC）和數(shù)據(jù)中心流量中的重要流量模式，然后詳細(xì)討論RoCE的缺點(diǎn)。

指導(dǎo)流量模式

為了討論方便，我們將確定三種流量模式，代表了當(dāng)前大部分RDMA工作負(fù)載。不幸的是，這些模式也凸顯了RoCE的不足之處。在這里，我們重點(diǎn)關(guān)注在HPC、AI訓(xùn)練和分布式推理、存儲以及一般微服務(wù)或函數(shù)即服務(wù)（FaaS）流量中使用的東西（內(nèi)部）數(shù)據(jù)中心流量。

Incast（IN）

當(dāng)多個源進(jìn)程以可能不協(xié)調(diào)但同時的流量模式針對同一目標(biāo)進(jìn)程時，就會發(fā)生incast流量模式。它的特點(diǎn)是具有多個源進(jìn)程和一個事務(wù)大小。實(shí)際中，當(dāng)服務(wù)在同一時間被許多不協(xié)調(diào)的客戶端請求時，這種模式通常會隨機(jī)出現(xiàn)。例如，假設(shè)有100個客戶端想要向同一個存儲服務(wù)器提交一個10kiB的寫事務(wù)。所有客戶端可能會以滿帶寬發(fā)送，因?yàn)樗麄儾恢兰磳l(fā)生的擁塞。數(shù)據(jù)包將快速填滿網(wǎng)絡(luò)緩沖區(qū)，可能妨礙其它流量，并最終違反服務(wù)級別協(xié)議（SLA）。最具挑戰(zhàn)性的incast模式是由于事務(wù)小于帶寬-延遲乘積而導(dǎo)致?lián)砣刂茩C(jī)制在事務(wù)完成之前無法獲得可靠的信號。我們指出，不斷增長的帶寬將越來越多的工作負(fù)載推入這個關(guān)鍵區(qū)域。

Oblivious bulk synchronous（OBS）

許多HPC和AI訓(xùn)練工作負(fù)載可以采用無感知的批量同步模型（OBS）表示，其中計(jì)算步驟與通信步驟交替進(jìn)行，通常同步進(jìn)程。無感知意味著應(yīng)用程序的通信模式取決于少量參數(shù)（如大小或進(jìn)程數(shù)），并且不依賴于被處理的數(shù)據(jù)。它通常可以在應(yīng)用程序啟動之前靜態(tài)確定。例如，消息傳遞接口（MPI）標(biāo)準(zhǔn)[7]中的所有集合操作都是無感知的。因此，OBS工作負(fù)載可以在算法上避免incast！深度學(xué)習(xí)訓(xùn)練中的三維并行性[2]是一個典型的例子。OBS可以通過進(jìn)程數(shù)、計(jì)算持續(xù)時間和通信大?。總€端點(diǎn)）建模。如果計(jì)算和通信都很小，那么整體工作負(fù)載對延遲敏感，這種模式在HPC和AI推理中經(jīng)常出現(xiàn)。大型通信在AI訓(xùn)練工作負(fù)載中通常具有帶寬敏感性。

Latency-sensitive (LS)

對于某些工作負(fù)載，消息延遲（有時也包括消息速率）起著核心作用。其中一些屬于OBS類別，但其它工作負(fù)載具有復(fù)雜的、數(shù)據(jù)相關(guān)的消息鏈，形成應(yīng)用程序中的關(guān)鍵性能路徑。這些通常是強(qiáng)可伸縮性的工作負(fù)載，解決方案的時間很重要，必須容忍低效的執(zhí)行。嚴(yán)格遵守截止日期的大規(guī)模模擬，如天氣預(yù)報(bào)和石油勘探，屬于這一類別，但也包括一些事務(wù)處理或搜索/推理工作負(fù)載。在這種情況下，通常具有嚴(yán)格的（個位數(shù)微秒）延遲要求。

部署特性

除了流量類型外，部署環(huán)境也在發(fā)生變化。新出現(xiàn)的機(jī)密計(jì)算理念要求所有流量在傳輸過程中進(jìn)行加密。理想情況下，流量在安全隔離環(huán)境中端到端進(jìn)行加密和解密，不信任任何網(wǎng)絡(luò)設(shè)備（網(wǎng)卡或交換機(jī)）。此外，新出現(xiàn)的多租戶場景要求從單個主機(jī)管理數(shù)以萬計(jì)的連接。這些通常由管理資源（如帶寬和安全性）的智能網(wǎng)卡通過速率限制和過濾來支持。此外，新的成本效益高的低直徑和專用拓?fù)浣Y(jié)構(gòu)對于極高帶寬部署而言，更高級的負(fù)載平衡和路由成為必要條件[8]，[2]。這些要求的許多組合對下一代高性能網(wǎng)絡(luò)提出了重大挑戰(zhàn)。

RoCE需要改進(jìn)的方面

RoCE的許多問題已經(jīng)在過去進(jìn)行了討論[9]，并且已經(jīng)有許多研究工作提出了各種解決方案[10]。在這里，我們概述了我們認(rèn)為可以進(jìn)行改進(jìn)的潛在措施，并將其與上述關(guān)鍵工作負(fù)載和部署用例聯(lián)系起來。我們現(xiàn)在提供一個列舉的問題列表，可以改進(jìn)以實(shí)現(xiàn)在基于以太網(wǎng)的高性能RDMA或智能網(wǎng)卡系統(tǒng)中更高效的操作。

1）PFC需要過多的緩沖區(qū)來實(shí)現(xiàn)無丟包傳輸

優(yōu)先流控制（PFC）是實(shí)現(xiàn)融合以太網(wǎng)上無丟包傳輸?shù)暮诵?。通過PFC，接收方監(jiān)視可用輸入緩沖區(qū)空間。一旦此緩沖區(qū)空間降低到與帶寬-延遲乘積BWRTT相關(guān)的某個閾值以下，它會向發(fā)送方發(fā)送一個PAUSE幀。此時，已經(jīng)有BWRTT/2字節(jié)在傳入線上，但在發(fā)送方接收到PAUSE幀之前，它將發(fā)送另外BWRTT/2字節(jié)。完全無丟包傳輸所需的最小緩沖區(qū)要求將是BWRTT + MTU，其中MTU是數(shù)據(jù)包的最大大小。然而，這僅適用于數(shù)據(jù)包立即被接收方處理的情況。即使是最輕微的轉(zhuǎn)發(fā)延遲也可能顯著降低鏈路利用率。

BWRTT緩沖區(qū)空間用于覆蓋PAUSE消息的傳輸延遲，通常被稱為“剩余緩沖區(qū)”，類似于InfiniBand或光纖通道中使用的基于credit的流量控制方案所需的緩沖區(qū)。在這些方案中，接收方主動向發(fā)送方發(fā)送credit（緩沖區(qū)分配），以保持輸入緩沖區(qū)空間處于均衡狀態(tài)，而不是在PFC使其過于充滿之后才作出反應(yīng)。這兩種方案都有其優(yōu)點(diǎn)：credit可以主動地向源端傳遞，而PFC方案在為不同源鏈路分配共享緩沖區(qū)空間時可以更具反應(yīng)性（延遲綁定）。這兩種方案基本上需要為每條鏈路保留BWRTT的空間，僅用于覆蓋鏈路的往返控制延遲，這樣就會導(dǎo)致有效轉(zhuǎn)發(fā)的空間減少。

實(shí)際上，緩沖區(qū)空間對于吸收不斷變化的流量峰值以進(jìn)行時間和空間負(fù)載平衡非常寶貴。此外，僅僅是所需的剩余緩沖區(qū)，如果不冒著丟包的風(fēng)險(xiǎn)，無法用于其它用途，對于下一代交換機(jī)的擴(kuò)展構(gòu)成了重大挑戰(zhàn)。圖1a顯示了在三層Fat Tree上，假設(shè)平均延遲為600ns（包括仲裁、前向糾錯（FEC）和導(dǎo)線延遲）的9kB數(shù)據(jù)包和8個流量優(yōu)先級類別（每個類別具有單獨(dú)的緩沖區(qū)）的情況下，各種交換機(jī)世代所需的剩余空間（不包括其它緩沖區(qū)?。ｋS著高性能地理復(fù)制數(shù)據(jù)中心的普及，覆蓋較長距離（從而引起延遲）也具有挑戰(zhàn)性。圖1b顯示了相同配置情況下，每個端口所需的剩余緩沖區(qū)，假設(shè)端口速率為800G，導(dǎo)線延遲為5ns/m，以及不同的部署類型。

人們可能會考慮使用有丟失的鏈路層協(xié)議來重新利用這些緩沖區(qū)進(jìn)行轉(zhuǎn)發(fā)功能。然而，這會與錯誤處理協(xié)議發(fā)生交互，我們很快將看到。無論如何，浪費(fèi)的緩沖區(qū)空間是影響所有可能受益于附加緩沖區(qū)的工作負(fù)載的一般問題，如果這些空間可用于數(shù)據(jù)包轉(zhuǎn)發(fā)，將會提供幫助。

2）受害者流、擁塞樹、PFC風(fēng)暴和死鎖

另一個問題源于PFC停止整個流量類別（僅使用三個比特進(jìn)行編碼）以及其中的所有流量。這可能導(dǎo)致受阻的受害者流：假設(shè)我們有兩個流A和B共享一個鏈路L。流A沒有擁塞，可以以滿帶寬發(fā)送。然而，流B在下游端口某處被阻塞，并填滿了鏈路L的輸入緩沖區(qū)。最終，鏈路L的分配緩沖區(qū)將被流B的數(shù)據(jù)包填滿，并發(fā)送一個PAUSE幀。該幀還會停止流A的傳輸，而流A本來可以獨(dú)立進(jìn)行。因此，未擁塞的流可能會受到其它擁塞流的影響。這種現(xiàn)象也被稱為排頭堵塞（Head of Line blocking）。

由于下游端口的任何擁塞都會填滿上游緩沖區(qū)，除非端點(diǎn)的擁塞控制協(xié)議作出反應(yīng)，因此PFC事件可以快速形成逆向“擁塞樹”，跟隨網(wǎng)絡(luò)中受害流量的流動。擁塞樹是無丟包網(wǎng)絡(luò)中的一個普遍問題，有時被稱為PFC風(fēng)暴。可以通過更細(xì)粒度地跟蹤擁塞情況來解決這個問題，例如在個別流量而不是優(yōu)先級的基礎(chǔ)上。然而，這要求網(wǎng)絡(luò)交換機(jī)維護(hù)流狀態(tài)以識別個別流量。另一種方法是嘗試將擁塞流動態(tài)地移動到擁塞優(yōu)先級中，以避免受害者（參見擁塞隔離，P802.1Qcz）。另一個問題是無丟包通道現(xiàn)在消耗了已經(jīng)稀缺的流量類別（獨(dú)立的緩沖區(qū)空間）。這從數(shù)據(jù)中心提供商那里奪取了一個重要的資源，他們已經(jīng)將這些流量類別用于差異化服務(wù)，如大流備份、低延遲視頻會議等。用于RoCE（或其它無丟包）流量的任何流量類別都會在整個網(wǎng)絡(luò)中丟失。

這種擁塞樹對于incast工作負(fù)載尤其成問題，它們可能會阻塞整個網(wǎng)絡(luò)，特別是在包級自適應(yīng)或無感知路由的背景下。然而，在incast鏈路上，每個流量的帶寬非常低，這意味著理論上這些流量只需要很少的網(wǎng)絡(luò)緩沖區(qū)就可以飽和鏈路。RoCE擁塞控制的純速率特性允許源端注入（過多）的數(shù)據(jù)包，這些數(shù)據(jù)包會迅速填滿網(wǎng)絡(luò)緩沖區(qū)。例如，基于窗口的方案將允許管理員直接控制每個流的網(wǎng)絡(luò)范圍內(nèi)的緩沖區(qū)占用情況。

任何具有有限緩沖區(qū)的無丟包方案都會遇到死鎖問題，如果路由允許形成循環(huán)?？梢酝ㄟ^無環(huán)路由方案或特殊緩沖策略來避免死鎖，但這都會帶來一定的（?。┏杀尽＜词孤酚赏ǔＪ菬o死鎖的，鏈路故障后發(fā)生的瞬態(tài)狀態(tài)也可能導(dǎo)致死鎖。避免這些情況更加困難，但可以通過在交換機(jī)中配置數(shù)據(jù)包超時來動態(tài)解決這個問題。

3）回退N（Go-back-N）重傳

RoCE的設(shè)計(jì)針對的是非常簡單的硬件，遵循InfiniBand的有序和基于credit的無丟包傳輸。這意味著數(shù)據(jù)包只有在被位錯誤破壞時才會丟失，這是非常罕見的事件。因此，重傳邏輯可以很簡單：如果接收方檢測到數(shù)據(jù)包流中的間隙（即跳過的序列號），它向發(fā)送方發(fā)送負(fù)確認(rèn)（NACK）并丟棄所有后續(xù)數(shù)據(jù)包。然后發(fā)送方從丟失的數(shù)據(jù)包開始重新發(fā)送所有數(shù)據(jù)包。這個方案實(shí)際上丟棄并重傳了一個完整的端到端的BW*RTT（帶寬延遲乘積）的數(shù)據(jù)。

假設(shè)一個具有800Gb/s鏈路速度和最壞情況下每跳延遲為600ns的三層Fat Tree網(wǎng)絡(luò)。端點(diǎn)觀察到的總往返時間（RTT）將為3.6微秒。每條鏈路上的有效誤碼率可以高達(dá)1e-12（根據(jù)以太網(wǎng)規(guī)范提出的建議） ，我們假設(shè)使用9kiB的幀，單個幀丟失的概率為3.3e-8（有關(guān)推導(dǎo)請參見附錄A）。因此，由于回退N重傳而造成的總帶寬損失可以忽略不計(jì)，僅為0.00013%。

簡單的回退N重傳方案的一個更大問題是它不支持多路徑傳輸或無序傳輸。任何兩個經(jīng)過的數(shù)據(jù)包都會觸發(fā)一次昂貴的重傳事件，導(dǎo)致整個BW*RTT傳輸丟失。最新一代的RoCE網(wǎng)絡(luò)接口卡引入了選擇性重傳來緩解這個問題。然而，這些功能通常是有限的。例如，NVIDIA的ConnectX6適配器不支持啟用選擇性重傳的標(biāo)簽匹配的自適應(yīng)路由。然而，回退N重傳具有一個有趣的優(yōu)勢：如果發(fā)生了位錯誤并且數(shù)據(jù)包在較低層次被（悄悄地）丟棄，一旦下一個數(shù)據(jù)包到達(dá)，錯誤就會立即被檢測到。而支持無序傳輸?shù)钠渌桨感枰却l(fā)送方的超時到期，這可能導(dǎo)致更長的恢復(fù)時間和抖動。因此，在設(shè)計(jì)新的傳輸協(xié)議時，需要仔細(xì)考慮所有這些權(quán)衡。

4）擁塞控制與其它流量的協(xié)同

RoCE的默認(rèn)擁塞控制依賴于與無丟包傳輸假設(shè)密切相關(guān)的非常簡單的速率控制。許多研究人員已經(jīng)意識到，這種簡單的機(jī)制與TCP/IP等其它流量集成不良，并且在數(shù)據(jù)中心環(huán)境中通?？梢愿倪M(jìn)。諸如DCQCN [5]、TIMELY [6]和HPCC [4]之類的機(jī)制構(gòu)建在RoCE之上，以改善流量的傳輸。目前大多數(shù)RoCE部署使用非標(biāo)準(zhǔn)的擁塞控制機(jī)制，這導(dǎo)致不同供應(yīng)商之間甚至同一供應(yīng)商的不同硬件版本之間的互操作性困難。這是因?yàn)閾砣刂迫匀皇且粋€棘手的問題，不同的工作負(fù)載可能需要協(xié)議的不同調(diào)優(yōu)版本。

例如，在無感知同步工作負(fù)載中，通常重復(fù)的端點(diǎn)非擁塞自由的大規(guī)模數(shù)據(jù)傳輸可以基于預(yù)期的流量模式進(jìn)行快速學(xué)習(xí)甚至靜態(tài)配置[2]，[13]。高度動態(tài)的incast場景需要通過接收方或網(wǎng)絡(luò)信號協(xié)調(diào)多個發(fā)送方。小于帶寬延遲乘積的小消息的延遲敏感工作負(fù)載可能是最棘手的，特別是如果它們以不可預(yù)測的數(shù)據(jù)驅(qū)動通信模式出現(xiàn)。這些可能需要依靠交換機(jī)緩沖區(qū)來吸收網(wǎng)絡(luò)級的臨時負(fù)載不平衡。總的來說，擁塞控制方案是并將繼續(xù)是研究的重點(diǎn)，即使在部署后也需要不斷進(jìn)行調(diào)優(yōu)。與TCP或QUIC等不同類型的流量共存還需要不斷的采用。因此，這些方案不僅需要在硬件上快速和廉價，還需要靈活并支持廣泛的參數(shù)化設(shè)置。

另一方面的論點(diǎn)考慮了交換機(jī)的隊(duì)列大小和占用情況。數(shù)據(jù)中心交換機(jī)傳統(tǒng)上具有大容量（深度）的緩沖區(qū)，以適應(yīng)流量突發(fā)情況，而無需進(jìn)行丟包來適應(yīng)慢速的端到端速率調(diào)整。另一方面，用于HPC的交換機(jī)通常使用非常淺的緩沖區(qū)并具有嚴(yán)格的反向壓力，這是由于它們可靠的鏈路級流控制機(jī)制所決定的[3]。此外，HPC網(wǎng)絡(luò)拓?fù)渫ǔ＞哂斜葦?shù)據(jù)中心部署更低的直徑[14]。因此，HPC部署支持較低延遲操作，因?yàn)樾〉臄?shù)據(jù)包不太可能在較長的流量后面的緩沖區(qū)中等待。采用RoCE的數(shù)據(jù)中心網(wǎng)絡(luò)通常在效率上結(jié)合了這兩者：它們使用了帶有所有問題的無丟包傳輸，而交換機(jī)的緩沖區(qū)相對較大。因此，許多現(xiàn)代擁塞控制機(jī)制的目標(biāo)是保持緩沖區(qū)占用率較低，使這個非常昂貴的資源不被利用！

5）報(bào)頭大小、數(shù)據(jù)包速率、可擴(kuò)展性

RoCEv2除了InfiniBand的基本傳輸頭（BTH）外，還使用了完整的以太網(wǎng)L2和UDP/IP報(bào)頭。因此，每個數(shù)據(jù)包的報(bào)頭開銷相當(dāng)大：22字節(jié)的L2報(bào)頭、20字節(jié)的IP報(bào)頭、8字節(jié)的UDP報(bào)頭、12字節(jié)的BTH報(bào)頭和4字節(jié)的ICRC，總共為66字節(jié)。例如，本地路由的InfiniBand只有總報(bào)頭大小為20字節(jié)：8字節(jié)用于本地路由報(bào)頭，12字節(jié)用于BTH報(bào)頭。其它HPC協(xié)議的報(bào)頭大小小于40字節(jié)。

這既影響原始數(shù)據(jù)包速率，也影響處理開銷和成本，因?yàn)閺?fù)雜的報(bào)頭需要更多的報(bào)頭處理。僅僅對于小有效載荷的數(shù)據(jù)包速率可能是有問題的。假設(shè)我們以8字節(jié)消息為例，用于共軛梯度求解器的單元素約簡操作或精細(xì)全局圖更新。在800Gb/s的鏈路上，最大速率（不包括報(bào)頭）將達(dá)到12.5千億數(shù)據(jù)包每秒（Gpps）。使用InfiniBand報(bào)頭，速率將下降到3.5Gpps，使用RoCEv2報(bào)頭將下降到1.4Gpps。數(shù)據(jù)包中將近90%是報(bào)頭開銷！而我們忽略了用于MPI或RDMA終端的其它協(xié)議報(bào)頭。然而，鑒于目前的NIC數(shù)據(jù)包處理速度較慢（每個NIC小于1Gpps），報(bào)頭大小可能不是最大的問題。此外，NIC需要處理確認(rèn)數(shù)據(jù)包，這對于選擇性確認(rèn)和重傳協(xié)議可能是特別具有挑戰(zhàn)性的。高用戶級和協(xié)議消息速率要求在NIC中進(jìn)行并行處理，考慮到時鐘速率的停滯。

RoCE的數(shù)據(jù)包格式與InfiniBand的傳輸層謂詞緊密相關(guān)，它的基本概念是隊(duì)列對（QP）之間的連接。單個連接的上下文狀態(tài)大小取決于實(shí)現(xiàn)細(xì)節(jié)，但是大型集群的全互聯(lián)可能會有問題。每個隊(duì)列對至少需要保持連接信息和狀態(tài)，如序列號、目標(biāo)地址和隊(duì)列對號碼。連接狀態(tài)可能相對較大，在某些實(shí)現(xiàn)中可達(dá)1kB每個連接。

在對延遲敏感的工作負(fù)載中，小數(shù)據(jù)包通常很重要，其中一些工作負(fù)載受限于NIC發(fā)出新消息的速率。更精簡的報(bào)頭潛在地降低延遲并增加消息速率，同時允許更高效的帶寬利用率。

6）不支持智能堆棧

隨著網(wǎng)絡(luò)開銷在數(shù)據(jù)中心工作負(fù)載中變得更加重要，設(shè)計(jì)了更智能的堆棧。例如，QUIC協(xié)議允許將傳輸處理推向應(yīng)用程序，應(yīng)用程序可以定義特定于應(yīng)用程序的協(xié)議。這使得可以為不同的服務(wù)需求運(yùn)行不同的協(xié)議，例如對延遲不敏感的視頻流，對延遲敏感的音頻會議，或者通常具有彈性但大型備份流量。RoCE的硬件加速哲學(xué)不支持不同的傳輸協(xié)議，即使用戶級堆棧能夠指定流量的其它屬性（例如，將消息標(biāo)記為對亂序傳遞具有彈性）。

新興的智能網(wǎng)卡在這一領(lǐng)域帶來了新的機(jī)會，用戶可配置的內(nèi)核可以在網(wǎng)卡上執(zhí)行數(shù)據(jù)包和協(xié)議處理[15]。此外，網(wǎng)絡(luò)中的遙測（INT）可以為這些協(xié)議提供額外的信號以做出相應(yīng)的反應(yīng)。因此，即使堆棧對流量類型有額外的了解，當(dāng)前的RoCE也將其限制在相對簡單且不靈活的協(xié)議中，無法充分利用這些知識。

7）安全性

RoCE已知存在一些安全問題[16]，[17]，特別是在多租戶環(huán)境中。其中許多問題源于協(xié)議的安全性、身份驗(yàn)證和加密在設(shè)計(jì)時的次要地位。然而，今天，這些屬性變得更加重要。

IPSEC可以用于保護(hù)L3報(bào)頭和有效載荷，但需要基于每個隊(duì)列對啟用，以確保沒有兩個租戶共享一組密鑰。這在連接上下文開銷和性能方面可能相當(dāng)昂貴。此外，RoCE不支持將內(nèi)存區(qū)域子委托給其它節(jié)點(diǎn)。這兩個問題可以通過現(xiàn)代密鑰派生協(xié)議來解決[16]。

8）鏈路級可靠性

向更高的收發(fā)器速度邁進(jìn)導(dǎo)致了在不斷增長的頻率下運(yùn)行的更復(fù)雜的編碼和調(diào)制方案。在50G通道上，以太網(wǎng)從簡單的兩電平NRZ轉(zhuǎn)移到了四電平PAM4編碼。如今的100G通道以25GHz運(yùn)行，接收器需要在納秒級內(nèi)區(qū)分四個電平。電纜和連接器中的信號衰減以及越來越復(fù)雜的模擬電路導(dǎo)致比特錯誤率（BER）很快會達(dá)到1e-4的高水平。

前向糾錯（FEC）被引入以避免由于網(wǎng)絡(luò)中丟棄損壞的數(shù)據(jù)包而導(dǎo)致過多的端到端重傳。以太網(wǎng)在鏈路層目標(biāo)為1e-12的誤碼率（BER），目前使用Reed-Solomon編碼，使用包含514個這樣的符號的塊，以及30個附加的編碼符號（RS544）。這使得接收器能夠糾正15個隨機(jī)比特錯誤和最多150個連續(xù)（突發(fā)）比特錯誤。其它FEC編碼，如LLFEC（RS272，RS544的一半大?。┖虵irecode提供較低的延遲，但對比特錯誤的保護(hù)也較低。

一般來說，F(xiàn)EC帶來的延遲和能耗成本分為兩類：（1）累積5,140比特的數(shù)據(jù)和（2）編碼和解碼編碼符號。前者隨著鏈路帶寬的增加而減少，后者取決于實(shí)現(xiàn)，實(shí)際上的延遲在20到100納秒之間。圖2顯示了不同鏈路帶寬下的預(yù)期RS544 FEC情況。

對于固定的RS544 FEC，延遲隨著更快的鏈路帶寬而減少，但不會低于FEC計(jì)算開銷。然而，更快的通道可能導(dǎo)致顯著更高的比特錯誤率。事實(shí)上，RS544可能無法將預(yù)期的1e-4的BER糾正到所需的1e-12。因此，未來的以太網(wǎng)標(biāo)準(zhǔn)可能采用更復(fù)雜的FEC機(jī)制，這可能會顯著增加延遲。

在PCIe中使用了一種替代方法，它也涉及由于復(fù)雜連接器而導(dǎo)致的相對較高的BER，但它被設(shè)計(jì)為低延遲的本地互連，目標(biāo)延遲約為5納秒。例如，即將推出的PCIe 6.0規(guī)范使用6個字節(jié)的FEC來保護(hù)242字節(jié)的塊，還有額外的8字節(jié)CRC。接收器首先使用FEC來糾正一些比特錯誤，然后檢查CRC。如果此檢查失敗，它將啟動一個簡單的鏈路層重傳協(xié)議以再次請求數(shù)據(jù)。FEC將比特錯誤率從1e-4降低到1e-6，然后CRC觸發(fā)的重傳概率小于1e-5。由于FEC導(dǎo)致的延遲增加不到2納秒，由于重傳導(dǎo)致的帶寬減少不到2％。以太網(wǎng)面臨的挑戰(zhàn)是更長的鏈路導(dǎo)致更高的鏈路延遲。

系統(tǒng)問題

不斷增長的鏈路級和因此的端到端延遲可能導(dǎo)致系統(tǒng)級問題增加。較高的延遲導(dǎo)致更高的緩沖區(qū)占用和能耗。不太明顯的是，較高的延遲導(dǎo)致?lián)砣刂菩式档停簜鬏斔俣瓤煊趩蝹€往返時間（RTT）的消息無法從依賴接收器通知的擁塞控制機(jī)制中受益。因此，對于具有小消息的不良incast情況來說，情況變得更糟或至少更常見，因?yàn)椤靶∠ⅰ钡拇笮≡黾印D3顯示了當(dāng)前數(shù)據(jù)中心中一些實(shí)際延遲下的帶寬延遲乘積的大小，顯示即使對于1 MiB的消息，通過限制發(fā)送者的速度來有效處理incast仍然被認(rèn)為“太小”。因此，具有較高延遲的問題性incast模式可能會變得更加常見！

換句話說，如果系統(tǒng)可以快速地限制發(fā)送者的速度，那么可以將消息大小降低到incast成為問題的下限以下。這可以通過降低延遲或讓交換機(jī)直接向源報(bào)告incast擁塞（而不經(jīng)過接收器）來實(shí)現(xiàn)。此外，如果只有非常小的消息會導(dǎo)致糟糕的incast情況，那么交換機(jī)緩沖區(qū)可能在常見情況下僅吸收它們，而不會耗盡資源。當(dāng)沿著incast樹傳播時，多組交換機(jī)緩沖區(qū)可以吸收瞬態(tài)incast消息，當(dāng)然，這可能導(dǎo)致網(wǎng)絡(luò)中的擁塞樹。這樣的整體系統(tǒng)問題仍然是一個開放的討論話題，但似乎較低的延遲通常會簡化這些問題。

還需要關(guān)注整體堆棧的其它方面，這些方面可能相當(dāng)復(fù)雜。例如，簡單而清晰的（遠(yuǎn)程）內(nèi)存語義很難定義、推理和正確實(shí)現(xiàn)[19]。此外，將進(jìn)程本地虛擬地址暴露給遠(yuǎn)程主機(jī)可能會對安全性和性能造成問題。可以考慮使用相對于內(nèi)存區(qū)域的尋址方案[20]。從安全性的角度來看，這兩種方案都有其弱點(diǎn)：暴露地址可以了解遠(yuǎn)程進(jìn)程的信息，然而對于攻擊者來說，固定偏移量更容易猜測[17]。我們指出，這些問題是所有RDMA系統(tǒng)的普遍問題，而不僅僅是RoCE。

路由和負(fù)載均衡仍然是一個開放性挑戰(zhàn)-大多數(shù)HPC網(wǎng)絡(luò)使用具有相對先進(jìn)的網(wǎng)絡(luò)內(nèi)部機(jī)制的分組級自適應(yīng)路由[3]，而大多數(shù)數(shù)據(jù)中心網(wǎng)絡(luò)使用簡單的由端點(diǎn)驅(qū)動的無感知ECMP，它通過更改頭字段以非常簡單的方式指導(dǎo)路徑選擇。數(shù)據(jù)中心中這種ECMP負(fù)載均衡的粒度從傳統(tǒng)上的完整流量到最近考慮的流塊都有。流塊是具有足夠間隙的連續(xù)數(shù)據(jù)包序列，即使沿不同路徑發(fā)送，它們也無法相互交錯。這種間隙可以通過延遲數(shù)據(jù)包或自然產(chǎn)生。最近，數(shù)據(jù)中心網(wǎng)絡(luò)正朝著更細(xì)粒度的負(fù)載均衡機(jī)制發(fā)展。另一個挑戰(zhàn)是一些應(yīng)用程序要求按順序傳遞消息?？偟膩碚f，亂序的粒度和能力嚴(yán)重依賴于應(yīng)用程序的要求和端點(diǎn)NIC的能力。更細(xì)粒度和更好的亂序能力簡化了網(wǎng)絡(luò)負(fù)載均衡。

預(yù)測

基于所有這些觀點(diǎn)，我們預(yù)測學(xué)術(shù)界和行業(yè)將重新審視數(shù)據(jù)中心以太網(wǎng)。下一代以太網(wǎng)可能會支持有損和無損的RDMA連接傳輸模式，以允許智能交換機(jī)緩沖區(qū)管理。這將使提供預(yù)留空間緩沖區(qū)成為可選項(xiàng)，并避免無損網(wǎng)絡(luò)的其它問題，如受害流和擁塞樹。下一代以太網(wǎng)也不太可能采用Go-Back-N的重傳語義，而是選擇更細(xì)粒度的機(jī)制，如選擇性確認(rèn)。此外，它可能會將擁塞管理作為規(guī)范的一部分。對于與其它流共存的情況，將特別注意，尤其是在有損流量類別中。這些協(xié)議將以靈活的方式設(shè)計(jì)，以支持智能的網(wǎng)絡(luò)堆棧，安全性將最終成為重要的一環(huán)。我們還可能在報(bào)頭和可靠性方法方面看到創(chuàng)新。

這些現(xiàn)代化將推動人工智能、高性能計(jì)算和存儲系統(tǒng)的新一代高性能網(wǎng)絡(luò)生態(tài)系統(tǒng)，這些系統(tǒng)是超大規(guī)模數(shù)據(jù)中心的核心。這種發(fā)展將結(jié)束HPC和數(shù)據(jù)中心網(wǎng)絡(luò)的融合！

審核編輯：劉清