數(shù)據(jù)中心以太網(wǎng)和RDMA：超大規(guī)模環(huán)境下的問(wèn)題

摘要

我們觀察到新興的人工智能、高性能計(jì)算和存儲(chǔ)工作負(fù)載對(duì)大規(guī)模數(shù)據(jù)中心網(wǎng)絡(luò)提出了新的挑戰(zhàn)?；谌诤?a target="_blank">以太網(wǎng)的RDMA協(xié)議（RoCE，RDMA over Converged Ethernet） 是將現(xiàn)代的遠(yuǎn)程直接內(nèi)存訪問(wèn)（RDMA，Remote Direct Memory Access）功能引入現(xiàn)有以太網(wǎng)的一種嘗試。十年過(guò)去了，我們重新審視了RoCE的設(shè)計(jì)要點(diǎn)，并得出結(jié)論認(rèn)為必須解決其幾個(gè)缺點(diǎn)，以滿(mǎn)足超大規(guī)模數(shù)據(jù)中心的需求。我們預(yù)測(cè)，數(shù)據(jù)中心和高性能計(jì)算市場(chǎng)將會(huì)融合，并在未來(lái)十年內(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ù)中心。在過(guò)去的十年里，數(shù)據(jù)中心經(jīng)歷了巨大的增長(zhǎng)，連接的機(jī)器數(shù)量超過(guò)了目前最大的超級(jí)計(jì)算機(jī)規(guī)模。雖然仍然存在一些差異，但這類(lèi)超大規(guī)模的超級(jí)計(jì)算機(jī)和數(shù)據(jù)中心的網(wǎng)絡(luò)需求非常相似[1]。然而，超級(jí)計(jì)算機(jī)通常使用專(zhuān)用的互連方式進(jìn)行連接，而數(shù)據(jù)中心則建立在以太網(wǎng)之上。由于相似的需求和規(guī)模經(jīng)濟(jì)效益，隨著每一代新技術(shù)的出現(xiàn)，二者繼續(xù)趨近于融合。我們認(rèn)為現(xiàn)在是重新思考融合互連的基本假設(shè)和架構(gòu)的合適時(shí)機(jī)。

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

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

以太網(wǎng)RDMA簡(jiǎn)史

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

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

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

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

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

指導(dǎo)流量模式

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

Incast（IN）

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

Oblivious bulk synchronous（OBS）

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

Latency-sensitive (LS)

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

部署特性

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

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

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

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

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

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

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

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

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

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

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

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

任何具有有限緩沖區(qū)的無(wú)丟包方案都會(huì)遇到死鎖問(wèn)題，如果路由允許形成循環(huán)。可以通過(guò)無(wú)環(huán)路由方案或特殊緩沖策略來(lái)避免死鎖，但這都會(huì)帶來(lái)一定的（小）成本。即使路由通常是無(wú)死鎖的，鏈路故障后發(fā)生的瞬態(tài)狀態(tài)也可能導(dǎo)致死鎖。避免這些情況更加困難，但可以通過(guò)在交換機(jī)中配置數(shù)據(jù)包超時(shí)來(lái)動(dòng)態(tài)解決這個(gè)問(wèn)題。

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

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

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

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

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

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

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

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

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

RoCEv2除了InfiniBand的基本傳輸頭（BTH）外，還使用了完整的以太網(wǎng)L2和UDP/IP報(bào)頭。因此，每個(gè)數(shù)據(jù)包的報(bào)頭開(kāi)銷(xiā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ù)包速率，也影響處理開(kāi)銷(xiāo)和成本，因?yàn)閺?fù)雜的報(bào)頭需要更多的報(bào)頭處理。僅僅對(duì)于小有效載荷的數(shù)據(jù)包速率可能是有問(wèn)題的。假設(shè)我們以8字節(jié)消息為例，用于共軛梯度求解器的單元素約簡(jiǎn)操作或精細(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)頭開(kāi)銷(xiāo)！而我們忽略了用于MPI或RDMA終端的其它協(xié)議報(bào)頭。然而，鑒于目前的NIC數(shù)據(jù)包處理速度較慢（每個(gè)NIC小于1Gpps），報(bào)頭大小可能不是最大的問(wèn)題。此外，NIC需要處理確認(rèn)數(shù)據(jù)包，這對(duì)于選擇性確認(rèn)和重傳協(xié)議可能是特別具有挑戰(zhàn)性的。高用戶(hù)級(jí)和協(xié)議消息速率要求在NIC中進(jìn)行并行處理，考慮到時(shí)鐘速率的停滯。

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

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

6）不支持智能堆棧

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

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

7）安全性

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

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

8）鏈路級(jí)可靠性

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

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

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

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

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

系統(tǒng)問(wèn)題

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

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

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

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

預(yù)測(cè)

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

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

審核編輯：劉清