英偉達迎來一羣勁敵

原標題：英偉達迎來一羣勁敵

近期發佈的超以太網（Ultra Ethernet，簡稱UE）1.0規範，為未來人工智能（AI）和高性能計算（HPC）系統定義了一套變革性的高性能以太網標準。本文由該規範的編寫者共同撰寫，對超以太網的設計進行了高層級概述，為理解其創新點提供了關鍵的設計動因與科學背景。儘管超以太網在整個以太網協議棧中均實現了技術突破，但其最突出的貢獻是創新性的超以太網傳輸層（Ultra Ethernet Transport，簡稱 UET）——這是一種可完全通過硬件加速的協議，專門為超大規模系統中的可靠、高速、高效通信而設計。

二十多年前，InfiniBand（無限帶寬）是高性能網絡領域最后一項重大標準化成果，而超以太網則充分利用了以太網龐大的生態系統，以及每傳輸 1 比特數據所帶來的千倍級計算效率提升，開啟了高性能網絡的新時代。

引言

超以太網（UE）通過標準化的新協議，實現了基於以太網的高性能人工智能（AI）與高性能計算（HPC）網絡支持。本文由超以太網規範的編寫者撰寫，補充了完整規範中的核心內容，重點闡述了歷時近2.5年的研發過程中所涉及的技術發展歷程與創新性技術要點。本文面向廣大讀者羣體，因此對諸多細節進行了簡化處理，並採用通俗易懂的表述與解釋方式。有關超以太網的所有問題，最終權威參考依據為長達562頁的完整規範。

2022 年，全球迅速邁入滿足人工智能系統需求所必需的大規模計算新時代，此時各大數據中心服務商均意識到，InfiniBand 及其配套協議——基於融合以太網的遠程直接內存訪問（Remote Direct Memory Access over Converged Ethernet，簡稱 RoCE）——存在明顯的侷限性。與此同時，以太網作為通用互聯技術的成功地位毋庸置疑：每年部署的端口數量高達數億個，其發明者也在當年榮獲了圖靈獎。

大約十年前，RoCE v2（第二代 RoCE 協議）將 InfiniBand 的傳輸層嵌入到可路由的以太網（OSI 模型第3層，即網絡層）中，從而實現了在數據中心的部署應用。RoCE協議幾乎原封不動地沿用了InfiniBand的傳輸協議，要求網絡提供無損傳輸能力，並保證數據包的嚴格按序交付。在融合以太網中，這種無損按序的數據包交付主要通過優先級流控（Priority Flow Control，簡稱PFC）機制來保障。

然而，PFC 需要為特定流量類別預留大量的頭部緩衝空間，且容易引發擁塞擴散與隊首阻塞（Head-of-Line Blocking）問題。此外，按序交付的要求限制了路徑選擇的靈活性，可能導致網絡性能無法達到*水平。RoCE協議的上述及其他侷限性在文獻中有詳細總結。

最初的 InfiniBand 傳輸層協議誕生於 25 年前，當時的技術環境下，架構設計人員只能在有限的計算資源條件下儘可能提升帶寬 。經過 25 年遵循摩爾定律的指數級發展，晶體管成本（進而帶動計算成本）降低了超過 10 萬倍，而可用帶寬僅從單數據速率（Single Data Rate，簡稱 SDR）提升至擴展數據速率（eXtended Data Rate，簡稱 XDR），增幅僅為 100 倍。因此，不僅終端的加速器性能得到了顯著提升，網絡架構設計人員在每傳輸 1 比特數據時可利用的計算資源也增加了 1000 倍以上。這一變化促使眾多企業開始重新思考內部 AI 產品線 [16,25,32] 與 HPC 部署中的網絡協議棧設計。一些業內人士很早就意識到，數據中心網絡與 HPC 網絡必將融合爲單一技術，隨后幾家企業開啟了相關討論，致力於推動這一融合進程。

2022 年*季度，AMD、博通（Broadcom）、HPE、英特爾（Intel）和微軟（Microsoft）等公司率先組建了一個小型工作組，一致同意基於各企業內部並行開展的技術研發成果，打造一套面向下一代以太網的開放標準，以開拓更廣闊的市場。該項目最初名為 HiPER，后更名為超以太網（Ultra Ethernet，UE）。2022 年 7 月，新的聯盟正式成立，並於同年 9 月舉行了首次線下會議。在首次會議上，各方提出了廣泛的意見：從「將某一種 RoCE 變體標準化」到「基於現有多種技術要素構建全新標準」，整個團隊參與熱情高漲，討論氛圍濃厚。2023 年 1 月，工作組確定了發展方向：融合爲 HPC 設計的功能特性、安全機制，以及為數據中心設計的擁塞管理技術，打造一種全新的技術方案——一種可在傳統以太網（plain old Ethernet）上運行的高可擴展性傳輸層協議。

不久后，2023 年 7 月，超以太網聯盟（Ultra Ethernet Consortium，簡稱 UEC）由AMD、安華高（Arista）、博通（Broadcom）、思科（Cisco）、源訊（Eviden，原 Atos）、HPE、英特爾（Intel）、Meta和微軟（Microsoft）聯合正式宣佈成立。作為 Linux 基金會聯合開發基金會（Joint Development Foundation，JDF）旗下的開放項目，該聯盟發展迅速，截至 2024 年底，成員公司已超過 100 家，參與人數超過 1500 人。

超以太網聯盟（UEC）的目標是定義一套開放的下一代 HPC 與 AI 網絡標準，該標準需與現有以太網部署兼容，且支持不同廠商設備間的互操作。聯盟的討論圍繞以下幾項核心原則展開：

大規模可擴展性：滿足未來 AI 系統大規模部署需求的關鍵。超以太網（UE）設計支持數百萬個網絡端點以靈活的方式部署，並提供無連接 API（Connectionless API）。初期，超以太網重點支持傳統的胖樹（fat tree）拓撲結構，同時不限制其他經過優化的拓撲（如漢明網格（HammingMesh）、蜻蜓（Dragonfly）或精簡飛（Slim Fly））的應用，不過聯盟尚未對這些非傳統拓撲進行測試驗證。

高性能：通過專為大規模部署設計的高效協議實現。例如，超以太網的無連接 API 通過一種無需額外延迟即可建立端到端可靠性上下文的機制提供支持——即*到達的數據包即可建立上下文（耗時可低至納秒級），即便在數據包大規模亂序交付的場景下也能實現。此外，超以太網還支持可選的擴展功能，如數據包裁剪（packet trimming），可實現快速的丟包檢測與恢復。

與現有以太網數據中心部署的兼容性：通過對交換機基礎設施提出*限度的要求，超以太網實現了與現有以太網數據中心部署的兼容性，便於現有基礎設施的輕松部署與逐步擴展。超以太網交換機僅需支持等價多路徑（Equal-Cost Multi-Pathing，簡稱 ECMP）和在出口端標記的基礎顯式擁塞通知（Explicit Congestion Notification，簡稱 ECN）功能，同時可（可選）支持數據包裁剪功能以提升網絡性能。超以太網無需對物理層（PHY Layer，OSI 模型第 1 層）或數據鏈路層（Link Layer，OSI 模型第 2 層）進行修改，但為提升新部署場景下數據鏈路層的性能，定義了若干可選擴展功能，為廠商差異化競爭提供空間。超以太網完全兼容以太網標準，這意味着用户可使用現有的運維管理、調試與部署工具。

廠商差異化：在規範確保互操作性的前提下，超以太網*限度地支持廠商差異化創新。這使得現有的以太網廠商生態系統能夠在活躍且龐大的市場中，推動快速的創新周期與技術研發。在諸多場景中（如數據包負載均衡、快速丟包檢測），規範僅提出一組可實現兼容協議的選項，而非強制要求採用特定方案。廠商既可選擇規範中提出的某一種方案，也可自主研發創新方案。這一設計使架構師能夠根據系統優化目標進行定製化設計，例如，廠商可選擇特定的負載均衡與丟包檢測方案，以打造易於運維、性能可靠的高性能系統。

適用範圍

超以太網將網絡劃分爲三種基本類型：本地網絡（通常稱為縱向擴展型網絡，scale-up）、后端網絡（通常稱為橫向擴展型網絡，scale-out）和前端網絡。圖 1 展示了這三種網絡類型的架構。本地網絡（紫色）用於連接中央處理器（CPU）與加速器（XPU，如 GPU、TPU 等），當前的典型部署場景中，此類節點級或機架級網絡採用 CXL、NVLINK 或以太網技術，傳輸距離可達 10 米，延迟目標為亞微秒級。前端網絡（綠色）是傳統的數據中心網絡，承擔 「東西向」（數據中心內部）和 「南北向」（數據中心與外部）流量傳輸。后端網絡（藍色）是連接計算設備（如加速器）的高性能網絡。后端網絡與前端網絡通常均被稱為 「橫向擴展型網絡」，二者可通過單一物理網絡實例實現，實際上超以太網也支持這種網絡融合部署，同時也允許採用物理上獨立的網絡實例分別部署。

超以太網的關鍵特性

超以太網（UE）可在現有以太網網絡上無縫運行。規範建議將超以太網流量分配至獨立的流量類別，但其擁塞控制算法也可與其他流量共享交換機緩衝區，實現協同工作。超以太網採用與 IPv4 或 IPv6（OSI 模型第 3 層）兼容的（可路由）地址與包頭格式，確保無縫集成。超以太網將結構端點（Fabric Endpoints，簡稱 FEP）定義為邏輯實體，負責終止單播操作中傳輸層的兩端。從功能上看，結構端點（FEP）大致相當於傳統的網絡接口控制器（Network Interface Controller，簡稱 NIC，即網卡）。

超以太網的關鍵特性包括：

下文將在超以太網架構部分詳細闡述這些特性及其他功能。在此之前，首先介紹基於 ECMP 的數據包噴灑技術——這是超以太網中負載均衡的基礎概念。

ECMP 數據包噴灑

等價多路徑（ECMP：Equal-Cost Multi-Pathing）是一種用於網絡流量負載均衡的方案。支持 ECMP 的交換機不會將目標地址直接映射到單一端口，而是映射到一組通往目的地的等價成本路徑所對應的端口。隨后，通過確定性哈希函數p=H(x)為每個數據包選擇輸出端口P。哈希函數的輸入通常是可配置的，一般包含完整的 IP 五元組（源地址、目的地址、源端口、目的端口及協議類型）。因此，若直接採用傳統 ECMP 方案，同一流的所有數據包會沿同一條確定性路徑傳輸（無故障情況下）。超以太網對其中一個字段進行重新定義，用於承載所謂的熵值（Entropy Value，簡稱 EV）。例如，若採用標準 UDP/IP 協議，該字段為 UDP 源端口（傳統場景下此端口未被使用）。

互聯網號碼分配機構（IANA）已將超以太網傳輸層協議（UET）分配至 UDP 4793 端口，該端口不僅是一個較大的質數，同時也是 RoCEv2 端口號的增量值（++RoCEv2++）。超以太網還支持原生純 IP 模式，在此模式下，熵值（EV）的位置與 UDP 源端口保持一致。此時，源結構端點（FEP）可為每個需沿不同路徑傳輸的數據包選擇不同的熵值（EV）；若需按序交付，則為數據包分配相同的熵值（EV）。

圖 2 展示了基於 8 端口交換機（綠色圓圈）構建的全 Clos 網絡架構，該架構支持 64 個端點（灰色方塊）。圖中重點標註了第二層的交換機 X，其包含 4 個上行端口與 4 個下行端口。數據包在網絡中傳輸時，首先通過下行端口進入交換機，除非目的地是該交換機所屬樹形結構的上層節點，否則將通過上行端口轉發。在 Clos 網絡中，當數據包到達源端點與目的端點的公共上層交換機后，會轉向*的下行路徑。以圖中網絡為例，64 個端點分為 4 組，每組 16 個端點；同一組內任意兩個節點（如節點 C 與節點 D）之間存在 4 條等價成本路徑（均需經過 3 跳交換機，圖中綠色與紅色路徑）；不同組內任意兩個節點（如節點 A 與節點 B）之間則存在 16 條路徑（圖中紫色與黃色路徑）。

由於設計簡潔，傳統 ECMP 方案存在一定侷限性：節點無法直接選擇路徑，僅能確定在無故障場景下，具有相同熵值（EV）的兩個數據包會沿同一路徑傳輸；但無法確定不同熵值（EV）是否會因哈希衝突而共享同一條路徑。事實上，這種哈希衝突及相關的（子）路徑共享是普遍存在的！以同一組內節點為例，僅存在 4 條不同路徑，但熵值（EV）的取值範圍卻高達216種。因此，對於理想的均勻分佈哈希函數，隨機選擇兩個熵值（EV）時，衝突概率高達 25%；而不同組內節點間的衝突概率也仍有 6.25%。在實際部署中，若採用更大端口數的交換機，上述概率可能會有所不同。

若兩條路徑發生衝突，每條路徑的可用帶寬將減半，可能導致嚴重的性能損失。在傳統以太網系統中，路徑一旦確定便不再改變，這會引發一種名為 「流量極化」（traffic polarization）的現象，問題將更為突出。

UE 的數據包噴灑技術通過為每個數據包分配不同 EV，可避免此類極化現象，從而在統計意義上實現數據包在所有交換機間的均勻分佈。即使發生哈希衝突，衝突持續時間也較短，且交換機緩衝區可吸收由此產生的流量不均衡，最終實現網絡帶寬的充分利用與長期平均流量均衡。若所有端點均實現均勻噴灑，數據包噴灑機制將非常簡潔；但部分流需按序交付（因此需確定性佔用部分路徑）時，機制實現將更具挑戰性。UE 提供多種可選負載均衡算法，用於確定每個數據包的 EV 分配方式；*方案的選擇仍為廠商差異化與學術研究保留空間。

超以太網配置文件

UE規範提供了三個配置文件(HPC、AIFul和AlBase)，以支撐不同的功能集，從而支持不同複雜度的實現。HPC配置文件提供了最豐富的功能集，包括通配符標記匹配，並針對MPI和OpenSHMEM工作負載進行了優化。AIFul配置文件是AlBase配置文件的超集。兩者都針對無需通配符標記匹配或其他高級通信操作的集合通信庫(*CCLs)而設計。兩個AI配置文件都提供了可延迟的發送功能，該功能專為*CCL通信卸載而設計。此外，AIFuIl提供精確的標籤匹配功能。Al Base 設計時考慮到實現複雜度*，假設匹配協議的其他部分由libfabric提供者或客户端庫(例如 CCL)來處理。

HPC配置文件是Al Base配置文件的超集，通過實現可延迟發送，-個實現可以同時提供HPC配置文件和AI Full配置文件。libfabric定義在UE上使得一個端點可以宣傳多個配置文件，然后與具有*公共特性集的相應配置文件進行協商。

超以太網架構

下文將詳細拆解 UE 架構的組成部分，按照 TCP/IP 標準分層模型（從*層到第四層）展開，架構示意圖如圖 3 所示。

我們從圖的最左下角開始，即以太網中的*層，即物理(PHY)層。該層基本上未因UE而改變，以保持與任何以太網部署的兼容性。首批UE產品將支持100G/lane信令或200G/lane信令。接下來的層是(數據)鏈路層，該層也與標準以太網兼容，以實現互操作性。它包含兩個可選且兼容的UE擴展:基於信用的流量控制(CBFC)和鏈路級重試(LLR)，我們將在第3.5節中予以説明。 網絡層採用相應的RFC所定義的標準的IPv4或IPv6，以允許沿用舊有的數據中心路由和操作方式。在網絡層內，交換機可以實施包修剪功能，這是一種可選特性，使目標能夠檢測網絡中的丟失包。傳輸層是迄今為止最顯著的改變，因為它被專門定義用於UE。它被設計用於在標準IP/UDP上運行或者原生在IP上運行。它可以被細分為四個子層:語義層(SES)、包交付層(PDS)、擁塞管理層(CMS)以及傳輸安全層(TSS)。

TSS 對 PDS和 SES(包括有效載荷)進行加密，並通過驗證IP地址來限制利用傳輸標頭字段欺騙或「猜測」的攻擊。與 PDS結合使用時，TSS 旨在防止重放攻擊，並通過與語義子層(SES)集成來減少協議層攻擊，如不當使用憑據。CMS在字節級別工作，並使用擁塞控制上下文(CCCs)來控制發送窗口的大小。PDS將一個或多個數據包交付上下文(PDC)與每個 CCC 關聯，並在數據包級別工作。PDS負責可靠地傳輸數據包，並在消息處理方面與 SES 合作。SES管理使用數據包實現的通信事務。它直接與應用程序層中的 libfabric接口相連。UE 1.0 使用libfabric作為與更高層次軟件及庫(如 CCL和 MPI)交互的接口。SES還管理在目標上執行的操作，例如將 RMA操作提交到內存中。

傳輸語義子層（SES）

libfabric 接口利用超以太網傳輸（UET）層的 SES，來提供用户標記的發送 / 接收和 RMA 操作。超以太網的 SES 定義了一種受 Portals 4 規範 [9] 啓發的有線協議和語義，以實現高效、輕量級的 libfabric 提供程序。與許多網絡 API 不同，libfabric 和 Portals 4 一樣，將傳統的網絡語義（尋址、完成、授權和故障處理）與連接的概念分離開來。下面將更詳細地探討這種差異如何驅動傳輸層的定義。

一、地址解析

與多數基於以太網的網絡 API 一致，UE 採用 IP 地址（即結構地址，Fabric Address，FA）選擇端點（FEP）。為實現可擴展地址解析，UE 進一步通過 「作業標識（JobID，24 位）」、「目標 FEP 上的進程標識（PIDonFEP，12 位）」 與 「資源索引（RI，12 位）」，定位每個端點上的邏輯上下文。UE 定義兩種地址解析模式，核心差異在於 PIDonFEP 的解讀方式（PIDonFEP 用於標識目標 FEP 上的地址空間（進程））；資源索引則用於選擇目標進程中的接收上下文（如 send/recv 隊列、RMA 匹配緩衝區與完成隊列）。

支持的兩種進程尋址模式，分別是用於集羣中分佈式並行作業的相對尋址，以及用於客户端-服務器應用程序的*尋址。它們通過數據包報頭中的 rel 位來區分。在相對尋址中，每個並行作業由*的 JobID 標識。在這里，FA 標識系統中的一個 FEP（灰色節點）。每個 FEP 都有一個全局 JobID 表，傳入的數據包會與該表進行匹配。每個 JobID 表項標識系統中在該節點上運行進程的一個作業，並指向本地的 PIDonFEP 表。PIDonFEP 表標識由 JobID 標識的作業中的所有進程（地址空間）。然后，表項會解析為每個進程的資源索引表，該表本身附帶服務或其他進程本地資源。

在圖 4 所示的示例中，該地址標識了 FEP 為 FA 1.1.1.2 的節點上，進程 2313 中的 MPI 端點。如果所有端點的進程數量相同，相對尋址方案支持將節點本地尋址和全局尋址解耦。在直接尋址中，每個源進程需要存儲 N*P 個條目，以尋址 N 個節點，每個節點有 P 個進程。而使用超以太網的相對尋址，每個源節點只存儲 N 個條目，並可以將目標進程計算為相對於每個節點的 PIDonFEP 表偏移量。

如圖 4 右側所示，*尋址用於客户端 / 服務器應用程序，以訪問固定的網絡服務，如存儲或微服務。此類服務不屬於作業的一部分，因此 JobID 不用於尋址（它仍在報頭中攜帶，可作為認證令牌）。在*尋址模式下，PIDonFEP 可像 UDP 端口一樣使用。超以太網還支持將 PIDonFEP 和資源索引（RI）合併到單個表中。

通常，發送/接收、帶標記操作和 RMA 操作使用不同的 RI 表。RMA 操作攜帶一個額外的內存密鑰（在 64 位匹配位中），用於在 RI 上下文中識別目標緩衝區。如果緩衝區可以直接與 RIs 關聯，則可以在優化的報頭格式中省略此內存密鑰。授權通過 JobID 來確保，因此 JobID 需要由可信實體分配。可使用 3.4 節中描述的 TSS 來防止網絡內的操作篡改。

這些尋址機制實現了超以太網提供的關鍵可擴展性增強之一。與現有機制相比，例如 InfiniBand 的 Verbs [23]，最初設計為將每個隊列對（QP）與一個接收隊列相關聯。然而，用户很快發現，在一個擁有 10,000,000 個核心的系統中，為每個通信對等方關聯一個接收隊列所需的內存是難以承受的，因此創建了共享接收隊列。相比之下，超以太網模型允許用户在源端無需上下文即可尋址隊列。JobID + PIDonFEP + RI *地尋址一個 FEP 上的單個隊列，這使得傳統 RDMA 網絡中的共享接收隊列概念變得多余。應用程序中的任何一方都可以向此隊列發送數據，並且 JobID 提供了寫入該隊列的授權。

這種沒有隊列對作為連接的設計，還有一個有利的副作用，即它實現了更簡單的每個事務故障和錯誤處理，避免了傳統 RDMA 系統中隊列錯誤狀態帶來的顯著複雜性。

二、消息傳遞和匹配

在接收端，每個 RI 都有一個關聯的接收隊列，到達的消息會與該隊列中的一個條目進行匹配。無標記操作按在接收端添加條目的順序使用這些條目。帶標記的消息使用標記選擇一個條目。如果消息是 「意外的」（沒有匹配條目），接收端可以丟棄該消息併發送 「緩衝區未準備好」 響應，或者緩衝其報頭。可選地，接收端也可以緩衝部分有效載荷，直到接收緩衝區被提交，詳見下文的可延迟發送和會合協議。

硬件消息匹配通過數據包攜帶的發起者 ID（32 位）和匹配密鑰（64 位）來支持。MPI或集體通信庫（CCL）程序會將源等級編碼到發起者 ID 中。額外的匹配密鑰位可用於編碼通信上下文（例如 MPI 通信器）和消息標記。HPC 配置文件支持有序通配符匹配，這在硬件實現上存在一些挑戰 [15]。AI Full 配置文件使用精確匹配且無需排序，以支持簡單的基於哈希或內容尋址存儲器（CAM）的實現。AI Base 配置文件在傳輸層不支持匹配。

為什麼要選擇納入匹配功能呢？簡單來説，匹配是 HPC（例如 MPI）中的基本語義，在無序網絡中，它成為支持最常見的 CCL 消息傳遞語義的有用工具。通過將 AI Full 配置文件限制為精確匹配，並簡化意外消息語義（見下文），可以保持實現的簡潔性。在此過程中，我們獲得了一個強大的工具：使用帶標記的匹配，消息（例如 nccl_send）可以通過無序協議在網絡中傳輸，並最終到達正確的緩衝區。這是通過讓上層（即 CCL）將消息序列號放入匹配位來實現的。

處理大型意外消息：可延迟發送和會合協議：傳統上，短的意外消息會直接在接收端緩衝，然而，大型意外消息需要不同的處理機制。三種配置文件對大型意外消息（在超以太網中，大型消息指超過當前發送窗口大小的消息。在許多現有通信庫中，為簡單起見，該大小通常由一個名為 「熱切限制」se 的可配置參數定義）的處理方式各不相同。如果消息到達時，接收地址已知（即應用程序已調用接收操作），則該消息在接收端被稱為預期消息，否則為意外消息。由於各種因素，如負載不平衡，意外消息往往難以避免，在某些應用程序中甚至非常常見。

會合協議：在傳統的 HPC 會合協議中，小消息通過單步發送，而大消息則分兩步發送 —— 首先發送大小為se 的*部分，以及剩余數據的本地地址，然后通過 RMA 讀取從源地址獲取第二部分。圖 5 左側展示了預期和意外大消息的協議流程。在發送會合發送之前，實現可能會查詢當前窗口大小，以便將發送大小調整為*值。預期情況中，熱切發送步驟用綠色表示，讀取步驟用藍色表示。意外情況則有一個額外的控制消息，用於通知源端消息未匹配。

可延迟發送：可延迟發送協議如圖 5 中間部分所示。預期消息會像普通發送一樣處理，無論大小，消息都會被完整發送並複製到接收緩衝區。與會合協議類似，小的意外消息可能會在接收端緩衝。如果無法緩衝的大型意外消息的*個數據包到達，接收端會立即回覆一個響應消息，告訴源端延迟（停止）發送。大型意外消息允許在接收端部分緩衝數據包（例如，一個窗口大小）。在接收端為延迟消息發佈匹配的接收操作后，會向發送端發送恢復消息的請求。為簡化實現，每個可延迟發送都攜帶一個來自源端的令牌（發起者重啟令牌，irt），用於標識消息，每個響應都攜帶本地存儲數據的大小，以及接收端的消息標識令牌（目標重啟令牌，trt）。這種令牌的使用允許雙方進行簡單的基於表的匹配。可延迟發送支持高效的低資源硬件卸載實現，因為它們不需要 RMA 讀取支持（注：超以太網聯盟決定在 AI Full 中強制要求支持 RMA 讀取，以支持存儲用例）。它們也可以被視為對傳統的、有時很麻煩的 「接收方未準備好」（RNR）流 [22] 的優化，將難以配置的超時替換為明確的信號。此外，可延迟發送可以在發送過程中對發送窗口大小的變化做出反應，因此總是發送*大小的數據，以充分利用帶寬，避免衆所周知的從熱切發送到會合發送的帶寬下降 [37]。

接收方發起：AI Base 配置文件不要求支持上述任何選項。相反，實現者可以選擇由軟件驅動的接收方發起協議，如圖 5 右側所示。在此方案中，硬件支持可以最小化，僅支持將單個數據包發送操作到專用緩衝區，以及僅支持 RMA 寫入。單個數據包發送操作用於將所有有效載荷的 RMA 寫入所需的所有信息發送給發送方，從而使發送方從軟件（即提供程序實現）發起寫入操作 [16]。其代價是發送方需要一些異步活動（例如一個線程）來發起寫入。此外，在最壞的情況下，如果發送操作恰好在接收操作發佈前21 RTT 時提交，該協議會增加一個往返時間（RTT）。

在圖 5 中，UET 框表示超以太網傳輸層在流程中的參與。紅色閃電錶示意外消息的到達。我們假設接收端僅存儲報頭（超以太網允許不存儲任何內容，這將要求發送方在超時后重新傳輸；僅存儲報頭；或者存儲原始事務的報頭和（部分）有效載荷，這將在提交接收操作時導致本地複製步驟）。藍色星號表示發送端的完成，黃色星號表示接收端的完成。爲了便於閲讀，省略了 PDS 確認；如果考慮這些確認，源端的完成事件將延迟最多 1 個 RTT。

現在，我們可以針對每個配置文件，區分預期、意外、小消息和大消息的所有組合的四種不同情況。下表模擬了每個配置文件中四種情況下接收端（黃色星號）的完成時間。我們用 α 表示延迟（½RTT），β 表示帶寬倒數（每字節時間），s 表示消息大小。發送操作在ts 時刻提交，接收操作在tr 時刻提交；在預期情況下，ts≥tr−α ，在意外情況下，ts

請注意，會合協議和可延迟發送在運行時看似相同——這僅適用於發送窗口恆定且精確的情況。由於額外的 RTT（2α）懲罰，如果接收操作可以在tr

RMA 讀/寫：超以太網支持存儲或單邊分佈式算法及同步（例如圖問題 [4]）等工作負載的 RMA 讀和寫操作。超以太網的寫操作很直接，將完整的地址，包括 Job ID、PIDonFEP、資源索引、目標內存密鑰、目的地址和偏移量，編碼到每個數據包中，以便數據包可以無序寫入目標緩衝區。順便提一下，這同樣適用於發送/接收消息傳遞。

超以太網的讀操作旨在最小化目標 FEP 上典型讀操作的狀態，並在讀取者之間提供一定的公平性。因此，它採用單數據包讀取方式，發起者發出一系列≤MTU 大小的讀請求，目標逐個滿足這些請求（也可能是無序的）。如果目標不需要完成通知，則在此協議中只有發起者會保留每個消息的狀態。發起者可以在必要時對請求進行速率限制，並且來自多個發起者的許多讀取操作可以在目標端交錯進行。這與目標端傳出擁塞控制上下文中基於窗口的流控制形成了複雜的關係，每個實現都需要對其進行管理。

超以太網在網絡結構中設計使用兩類流量類別（TC）：擁塞管理子系統（CMS）將一類用於批量數據傳輸，另一類用於控制流量（如確認幀 ACK）。這種分類機制加快了擁塞信息的傳遞速度，並降低了攜帶擁塞信息的確認幀丟失概率。儘管超以太網的核心設計面向盡力而爲（有損）網絡，但它同樣支持無損網絡（如 Slingshot [13]）。為避免協議相關（或消息相關）的死鎖問題，超以太網為無損網絡定義了兩類流量類別的獨立映射規則。早期部分大規模並行處理（MPP）設計通過兩類消息類別（或虛擬通道類別）避免消息相關死鎖；對於消息傳遞系統，宋等人基於早期死鎖避免路由算法的核心原理，對這一機制進行了形式化定義。

在無損網絡中，當請求與響應之間存在資源依賴關係（如數據包與確認幀、讀請求與讀響應）時，可能引發死鎖：若緩衝空間耗盡，目標端因無法生成響應而無法繼續接收請求，死鎖便會產生。有損網絡通過在傳輸無法推進時直接丟棄數據包來解決死鎖問題；純發送或純寫操作類協議則可藉助累積確認機制避免死鎖 —— 該機制允許寫操作持續被接收而無需立即生成確認。而集成讀操作的無損網絡協議主要分為兩類：一類通過兩類流量類別（分別用於讀請求和讀響應）實現，另一類則在目標端為讀請求預先預留緩衝空間（如 RoCE 和 InfiniBand）。長期以來，資源預預留的要求導致遠程直接內存訪問（RDMA）讀操作的性能表現不佳，且這些預預留資源通常與連接結構（如隊列對）相關聯，而超以太網中並不存在此類結構，因此超以太網選擇採用第二類流量類別來解決這一問題。

傳輸層數據包交付子系統（PDS）

超以太網引入了創新性的數據包交付子系統（PDS），該系統藉助臨時數據包交付上下文（PDC）管理數據包從源端到目標端的可靠傳輸。數據包交付上下文（PDC）可在*數據包到達時即時建立，無需額外延迟。同時，超以太網禁止在網絡中對數據包進行分片處理，除消息的最后一個數據包外，所有數據包均以滿*傳輸單元（MTU）有效載荷的形式發送，這一設計大幅簡化了數據包跟蹤邏輯。

超以太網傳輸層（UET）的數據包交付子系統（PDS）定義了三類數據包：一是請求數據包，用於傳輸數據（寫操作和發送操作中從發起者到目標端，或讀操作中從目標端到發起者）；二是確認數據包，用於攜帶此前請求數據包的相關信息；三是控制數據包，用於傳輸層特定控制操作（如檢查接收端的數據包狀態或路徑狀態）。

數據包傳輸模式：超以太網的設計可支持多種應用場景，包括需嚴格按序傳輸的向后兼容工作負載、完全無序的傳輸場景，以及介於兩者之間的各類場景。它提供四種數據包排序與可靠性傳輸模式，分別是可靠無序交付（RUD）、可靠有序交付（ROD）、不可靠無序交付（UUD）和冪等操作可靠無序交付（RUDI）；由於在規範制定時未發現相關應用場景，超以太網暫不支持不可靠有序交付模式。

可靠無序交付（RUD）是默認的批量傳輸模式，適用於所有大型消息傳輸場景，且在無需通配符匹配的場景（如 AI 類配置文件）中，可用於所有傳輸操作。對於 AI Full 配置文件中的可靠無序交付（RUD），一種可能的實現方案是為每個已提交的發送和接收操作分配消息標識（mid，從 0 開始遞增），並將消息標識（mid）與通信器標籤共同納入匹配邏輯 —— 這樣一來，無論數據包在傳輸過程中的順序如何，發送至特定目標端的*發送操作都能與該目標端的*接收操作匹配，且本地每提交一次發送或接收操作，消息標識（mid）都會遞增。由於可靠無序交付（RUD）支持數據包噴灑技術（詳見 3.3 節），因此它被視為超以太網中效率最高的可靠傳輸模式。

若在數據包級別需嚴格按序保障（如 RoCE 或 InfiniBand 的按序要求），可採用可靠有序交付（ROD）模式。例如，在 HPC 配置文件中，MPI（消息傳遞接口）要求支持帶按序保障的通配符匹配，此時便需使用該模式。一種簡單的協議實現方式是：通過可靠有序交付（ROD）通道傳輸會合消息（rendezvous message）的所有 「即時部分」（eager portion），同時通過可靠無序交付（RUD）通道發起讀操作。此外，先進的消息匹配策略可能進一步放寬這一限制 [15]。對於資源受限的端點（如網絡內計算交換機或簡單存儲設備），可靠有序交付（ROD）同樣適用 —— 它僅需實現簡單的 「回退 N 幀」（go-back-N）機制（與 RoCE 類似）。但由於可靠有序交付（ROD）為每個流單元（flowlet）僅使用一條網絡路徑 [7,36]，因此它被視為超以太網中效率較低的可靠傳輸協議。

若需實現不可靠數據報通信，可採用不可靠無序交付（UUD）模式，該模式有助於實現基於軟件的協議部署或系統管理任務。

冪等操作可靠無序交付（RUDI）旨在支持可在目標端多次執行的冪等操作——例如，在應用程序未訪問或修改目標值的前提下，相同的讀或寫操作可多次執行且不改變最終結果。該模式允許實現者在目標端省略對重複數據包 / 消息（重傳）的過濾步驟，以提升實現效率。由於無需維護接收端狀態，冪等操作可靠無序交付（RUDI）是擴展性*的模式，但它的使用門檻較高（用户需確保同步周期內的數據一致性），且不適用於原子加法等非冪等操作。該協議僅針對特殊應用場景設計，且僅在 HPC 配置文件中提供。

需注意的是，所有無序數據包傳輸模式均可能導致數據無序到達主內存，因為語義子層（SES）不會對數據包進行重排序處理。

超以太網（UE）報頭：每個超以太網數據包均攜帶各子層的報頭，其中許多報頭為可選或可配置類型，因此數據包報頭存在多種不同大小的配置方案。如圖 3 所示，每個數據包均包含 14 字節的標準以太網報頭和 4 字節的幀校驗序列（FCS）。超以太網傳輸層（UET）可在 UDP/IP 之上運行，也可選擇原生在 IP 上運行（此時會用 4 字節的熵值報頭替代 8 字節的 UDP 報頭）。數據包交付子系統（PDS）報頭的大小根據傳輸模式有所不同：可靠無序交付（RUD）和可靠有序交付（ROD）模式下為 12 字節（若使用 RCCC 擁塞控制則為 16 字節，詳見 3.3 節），冪等操作可靠無序交付（RUDI）模式下為 8 字節，不可靠無序交付（UUD）模式下為 4 字節。在幀校驗序列（FCS）之前，可選擇添加 4 字節的端到端循環冗余校驗（CRC）字段，用於對報頭和數據進行完整性校驗。語義子層（SES）報頭則包含三種類型：標準操作使用 44 字節報頭，不超過 8 千字節（8kiB）的匹配消息使用 32 字節報頭，非匹配消息使用最小 20 字節報頭。當需要安全保障時，可在數據包交付子系統（PDS）報頭前添加可選的傳輸安全子層（TSS）安全報頭（若使用顯式源標識則為 16 字節，否則為 12 字節），並在數據包末尾、幀校驗序列（FCS）之前添加 16 字節的完整性校驗值（ICV）。由於完整性校驗值（ICV）的安全性遠高於數據包交付子系統（PDS）的循環冗余校驗（CRC），若使用完整性校驗值（ICV），可省略循環冗余校驗（CRC）字段。超以太網報頭的整體結構可參考圖 3。

超以太網提供多種報頭選項，為廠商差異化創新提供空間。例如，擁塞控制字段包括目標擁塞控制上下文中的接收字節數（RCVD_BYTES）、目標端本地處理數據包的時間（SERVICE_TIME），以及用於直接調整發送窗口大小的信用額度（CREDIT）字段；同時支持選擇性確認（SACK）偏移量、64 位位圖（Bitmap），以及可選的無序數據包計數（OOO_COUNT），以支持無序數據包處理。這些字段有助於實現更優的流控和擁塞管理。此外，廠商可通過專用編碼攜帶私有信息以實現特定擴展——超以太網在數據包交付子系統（PDS）類型、語義操作碼和確認狀態的編碼空間中，專門為廠商擴展預留了部分空間。

動態數據包交付上下文（PDC）創建：數據包交付上下文（PDC）的創建無需額外延迟，因為建立連接所需的所有狀態信息均包含在數據包包頭中。該協議甚至支持為無序可靠無序交付（RUD）通道建立連接。圖 6 左側展示了發起者和目標端的簡化數據包交付上下文（PDC）狀態機，右側則展示了數據包交付上下文（PDC）的建立與關閉流程。其中，數據包序列號（PSN）用於標識數據包，數據包交付上下文標識（PDC ID）用於在源端和目標端標識數據包交付上下文（PDC）。該狀態機未包含初始化階段的大部分錯誤/數據包丟失處理邏輯（同步（SYN）狀態下的紅色自循環），以及可能需要重傳的中間狀態轉換過程。

右側場景展示了三條消息的傳輸過程：首先是包含 5 個數據包的寫操作（數據包序列號 PSN 4-8），隨后是包含 3 個數據包的讀操作（數據包序列號 PSN 9-11 和 PSN 2-4），期間發起者收到關閉請求。

該場景初始狀態為無數據包交付上下文（PDC），且存在語義子層（SES）發起的寫請求。源端通過發送*數據包建立標識為 7 的數據包交付上下文（PDC），併發送以隨機數據包序列號 4 開頭的三個數據包至目標端。當*數據包到達目標端時，目標端創建新的數據包交付上下文（PDC）（本場景中標識為 19），並在每個確認數據包中攜帶新建立的數據包交付上下文標識（PDCID）。一旦源端收到包含有效目標端分配數據包交付上下文標識（PDCID）的*確認數據包，便會轉換至 「已建立」（ESTABLISHED）狀態，並繼續發送無需攜帶同步（SYN）標識的數據包——需注意的是，在數據包交付上下文（PDC）建立過程中，源端始終以滿速率發送數據包。當*不攜帶同步（SYN）標識的數據包到達目標端時，目標端同樣轉換至 「已建立」（ESTABLISHED）狀態。雙方均進入 「已建立」 狀態后，數據包交付上下文（PDC）將正常工作，數據包序列號（PSN）空間保持同步。

當數據包交付上下文（PDC）處於空閒狀態時，由發起者啟動關閉流程。發起者無需在數據包交付上下文（PDC）空閒后立即關閉，目標端可通過控制數據包或確認數據包中的標誌位，請求發起者關閉數據包交付上下文（PDC）。一旦源端開始關閉數據包交付上下文（PDC），便會進入 「靜默」（QUIESCE）狀態：此時仍會繼續發送關閉請求發起前已開始的消息對應的數據包，但會拒絕新的消息請求。待所有消息處理完畢后，源端進入 「確認等待」（ACK WAIT）狀態，直至收到所有未完成的響應。收到所有響應后，源端向目標端發送最終關閉命令，目標端隨之關閉數據包交付上下文（PDC）。當源端收到針對關閉命令的最終確認數據包時，源端的數據包交付上下文（PDC）資源將被釋放。

快速數據包丟失檢測

當超以太網數據包丟失時，需從源端重新傳輸。目前，超時機制是重傳丟失數據包的常用標準方法，但超時機制並非可靠的丟包檢測手段——數據包可能仍在交換機緩衝隊列中等待轉發，而源端已因超時觸發重傳，導致帶寬浪費和重複傳輸。若要確保超時數據包未在網絡中等待，需設置極高的超時閾值（尤其在深度緩衝的數據中心交換機和長路徑場景中），但這會導致擁塞丟包鏈路的帶寬利用率大幅降低。在實際應用中，很難找到兼顧 「避免不必要重傳」 與 「保證帶寬利用率」 的*超時閾值。因此，超以太網定義了多種更快速的丟包檢測機制作為替代方案。

超以太網將數據包丟失分為三類（此處稱為 「網絡中的三類丟包」）：一是擁塞丟包，即交換機緩衝空間滿時發生的丟包；二是損壞丟包，即數據包因比特錯誤未通過校驗和檢查導致的丟包；三是配置丟包，即網絡因配置原因（如防火牆攔截、生存時間（TTL）過期）導致的丟包。超以太網定義了三種可選的丟包檢測機制，均能檢測擁塞丟包，其中一種還可可靠檢測損壞丟包。

*種也是最簡單的機制是數據包裁剪（packet trimming），但該機制需交換機支持。在該機制下，可配置交換機對即將丟棄的數據包進行有效載荷裁剪，僅保留報頭，並可能以更高優先級將裁剪后的數據包轉發至目標端。目標端收到裁剪數據包后，即可知曉數據包有效載荷已丟失，並能快速請求源端重傳。超以太網規範定義了基於交換機的數據包裁剪的詳細行為，但該機制無法檢測損壞丟包。

第二種機制是無序計數（out-of-order count），通過計算最后接收的數據包序列號（PSN）與最早缺失的數據包序列號（PSN）之間的差值，估算丟失數據包數量。該計數可在目標端計算后通過可選的無序計數（OOO_COUNT）確認擴展報頭字段發送至源端，也可由源端自行估算。若該計數器超過特定閾值，系統則判定數據包丟失。相較於超時機制，該機制的準確性更高，但在數據包噴灑場景中，若不同路徑的數據包延迟差異過大，仍可能導致重複傳輸。

第三種機制是基於熵值（EV）的檢測方案，可實現精確丟包檢測。最簡單的方案是在源端維護已發送數據包的（熵值EV，數據包序列號 PSN）有序列表，並將每個傳入的確認數據包與該列表進行匹配。由於超以太網的確認數據包按到達順序生成，且攜帶與被確認數據包相同的熵值（EV），在無硬件故障的情況下，一個熵值（EV）對應一條*路徑——因此，源端只需在發送列表中查找具有相同熵值（EV）的最早條目，若接收的數據包序列號（PSN）與該條目不匹配，即可推斷所有具有相同熵值（EV）且數據包序列號（PSN）小於接收值的數據包均已丟失。這一簡單但效率較低的方案可通過 「k個時隙輪詢噴灑數據包」 的機制優化：此時每個時隙預期接收的數據包序列號（PSN）為i、i+k、i+2k…… 若確認數據包對應的數據包序列號（PSN）晚於預期值，則可推斷發生丟包。對於尾部丟包（tail loss），可通過沿特定路徑（熵值EV）發送探測控制數據包檢測；此類探測數據包也可用於負載均衡場景中調整特定時隙的熵值（EV）。

數據包噴灑與可靠性

在數據包噴灑網絡中，由於數據包到達順序與發送順序不一致，可靠傳輸和消息語義機制面臨獨特挑戰。目標端維護位圖（bitmap）用於消息完成狀態跟蹤和可靠性管理。超以太網定義了累積確認（CACK）數據包序列號（PSN），使得一個確認數據包可確認多個數據數據包，該機制在確認數據包丟失時尤為有用。此外，超以太網支持可選的確認合併（ACK coalescing）機制，允許接收端無需對每個數據數據包單獨生成確認——這一機制適用於 「生成每個確認數據包成本過高」 的系統。超以太網的確認數據包還攜帶 64 位選擇性確認（SACK）位圖，位圖中置 1 的位表示對應數據包已到達目標端，據此可推斷部分數據包的丟失情況。

可靠無序協議的核心實現挑戰是「數據包亂序程度控制」——目標端需通過位圖等結構跟蹤亂序到達的數據包。最壞情況下，無序網絡可能 「先交付最后一個數據包」；高帶寬網絡上的小消息（目標 RTT 為 10μs）需覆蓋 「帶寬延迟積（BDP）」 的大幅位圖，超出部分實現的資源承載能力。考慮到 UE 的無連接特性（無需往返握手即可啟動通信）與 「位圖資源動態分配需求」，UE 引入 「* PSN 範圍（Maximum PSN Range，MP_RANGE）」 概念：線協議的 MP_RANGE 字段允許通信目標端 「動態調整允許的未完成 PSN 範圍」，明確限制數據包跟蹤所需的資源。與 UE 的多數設計一致，通信初始階段採用 「樂觀假設」（目標端可跟蹤所有發送的數據包），為 「優化實現與調優應用」 提供性能保障；若后續目標端資源受限，協議可平滑恢復，避免資源溢出。

傳輸層擁塞管理子系統（CMS）

超以太網傳輸層（UET）的擁塞管理子系統設計僅要求交換機基礎設施提供*限度的支持，以便能在傳統網絡環境中部署。該子系統既包含用於限制網絡中字節數量的擁塞控制（CC）功能，也包含用於選擇優質路徑的負載均衡（LB）功能，僅要求交換機支持出口端的基礎顯式擁塞通知（ECN）標記和等價多路徑（ECMP）負載均衡。超以太網的擁塞管理子系統針對盡力而爲型網絡進行了設計和仿真測試，能夠充分利用數據包裁剪等快速丟包檢測機制。

當超以太網與其他流量共享網絡時，其設計假設是可利用以太網的服務類別（CoS）功能將超以太網流量分配到獨立的流量類別中。未來版本可能會增加對先進擁塞信令技術和其他網絡內遙測技術的支持。如前文所述，超以太網定義了多種控制數據包類型，可用於探測路徑狀態，以收集更多擁塞信息或檢測丟包情況。

從本質上講，超以太網的擁塞管理通過擁塞控制上下文（CCC）實現，一個擁塞控制上下文可服務於一個或多個數據包交付上下文（PDC）。通常，一個擁塞控制上下文會協調同一對結構端點（FEP）之間相同流量類型的所有數據包交付上下文。在發送端，擁塞控制上下文會維護一個擁塞窗口，用於限制網絡中未確認字節的數量，該窗口可看作是發送端在等待確認前能向網絡中發送的字節數（信用額度）。

超以太網提供兩種互補的擁塞控制算法：基於網絡信號的擁塞控制（NSCC）和基於接收端信用的擁塞控制（RCCC）。基於網絡信號的擁塞控制在源端運行控制循環以調整窗口大小，所有超以太網網卡（NIC）均支持該算法；基於接收端信用的擁塞控制則定義了一種由接收端驅動的信用分配算法，該算法為可選實現。這兩種算法均可在運行時禁用，因此實現了基於接收端信用的擁塞控制的系統可支持所有可能的配置模式：僅使用基於網絡信號的擁塞控制、僅使用基於接收端信用的擁塞控制，或兩者結合使用。

基於網絡信號的擁塞控制（NSCC）：基於網絡信號的擁塞控制（NSCC）受此前多種算法啓發，其早期版本已由超以太網擁塞管理子系統團隊記錄並分析 [6]，后續有一個子團隊發佈了相關分析報告 [27]。該算法結合了兩種核心信號：往返時間（RTT）和從請求數據包到響應數據包的顯式擁塞通知（ECN）標記。下文假設採用逐包確認（ACK）機制，以便能精確測量這兩種信號；該算法也支持累積確認（CACK）和選擇性確認（SACK，可確認多個數據包），但這兩種確認方式可能會導致更復雜的情況。

顯式擁塞通知（ECN）標記 [29] 可視為一種統計型 1 位信號。交換機被配置為以概率方式標記數據包，若觀測到足夠多的數據包且路徑上交換機緩衝區狀態未發生變化，源端就能準確瞭解路徑的擁塞情況。然而，即使路徑上有多個交換機都要設置顯式擁塞通知擁塞經歷（ECN-CE）標誌（簡稱 「ECN 位」），該標誌最終也只會被設置一次。遺憾的是，這種方式可能需要觀測大量數據包才能收斂，且緩衝區狀態通常處於動態變化中。超以太網要求在數據包離開交換機時（出口端）進行 ECN 標記，這與 RFC 3168 標準的規定不同，但卻是當前交換機的常見實踐方式。通過出口端標記，信號生成可繞過隊列，從而快速反饋給發送端。目前已有多種擁塞控制方案僅依賴 ECN 實現。

另一方面，往返時間（RTT）可視為一種多位信號，因其能根據本地計時器的精度記錄從請求到響應的精確時間。但往返時間會顯著延迟擁塞信號的反饋，因為它無法繞過任何擁塞的交換機隊列。若交換機緩衝區容量大且已接近填滿，同時路徑跳數較多，發送端要獲取用於擁塞控制的往返時間信息可能需要較長時間。即便在穩定狀態下，隨着網絡狀態的快速變化，往返時間信息也可能迅速過時。超以太網在測量往返時間時，會排除接收端的服務時間。目前也有多種擁塞控制方案僅基於往返時間實現。

基於網絡信號的擁塞控制同時利用這兩種信號——快速的 ECN 1 位信號和滯后的 RTT 多位信號，並定義了確認數據包到達時的以下四種情況：

（1）存在 ECN 標記 + 低往返時間：表明至少有一個交換機緩衝區的擁塞正在加劇；

（2）存在 ECN 標記 + 高往返時間：表明網絡已出現擁塞，可能處於過載狀態；

（3）無 ECN 標記 + 低往返時間：表明網絡無擁塞，可能處於未充分利用狀態；

（4）無 ECN 標記 + 高往返時間：表明網絡擁塞狀況正在緩解。

為區分往返時間的 「低」 與 「高」，基於網絡信號的擁塞控制會持續維護一個數值，用於表示其對當前預期無負載往返時間的*估算。該算法在*種情況下不做響應，但會在其他三種情況下調整擁塞窗口大小：第二種情況下，會針對每個傳入的確認數據包大幅減小擁塞窗口；第三種情況下，會根據測量到的往返時間與預期往返時間的差值快速增大擁塞窗口；第四種情況下，則會平緩增大擁塞窗口。

除上述四種情況外，基於網絡信號的擁塞控制還採用快速自適應（QA）算法來估算網絡中的瓶頸（如接收端入向擁塞或交換機處擁塞）。該算法利用丟包信號（如數據包裁剪等快速丟包檢測機制），根據成功交付數據包的比例快速調整發送速率。關於上述四種情況及快速自適應算法的詳細解釋、測量數據和設計思路，可參考 SMaRTT 論文。

基於接收端信用的擁塞控制（RCCC）：超以太網傳輸層的基於接收端信用的擁塞控制（RCCC）受早期同類方案啓發 [18]。與基於網絡信號的擁塞控制不同，發送端不會根據網絡信號調整窗口大小，而是在發送數據包時減小窗口，並在收到接收端反饋的信用額度時增大窗口。所有信用額度管理均由接收端負責，接收端知曉傳入流量的精確數量，並以特定速率向發送端分配信用額度。這種機制對多種流量模式都極為有利，還能考慮源端的需求，為流量需求不穩定的工作負載高效調度各源端的速率。

這種方法的主要優勢在於簡潔性，且對多種相關工作負載均有效。在接收端出現入向擁塞（incast）時，基於接收端信用的擁塞控制能很好地控制流量，而基於網絡信號的擁塞控制對此只能通過快速自適應算法進行推測。但該算法無法應對網絡中的擁塞或源端的出向擁塞（outcast），因此超以太網建議在超訂閲網絡中同時啟用基於網絡信號的擁塞控制。基於接收端信用的擁塞控制也可採用專有實現，利用接收端的其他信號來調整速率。將兩種算法結合使用可實現最高吞吐量，下文將概述三種典型擁塞場景及兩種算法在各場景下的表現。

入向擁塞、出向擁塞與超訂閲：基於接收端信用的擁塞控制和基於網絡信號的擁塞控制均採用樂觀策略，初始時以滿速率（線路速率）運行，擁塞窗口大小等於或略大於帶寬延迟積（BDP）。若網絡無擁塞，兩者會持續以該速率運行，其核心目的是在擁塞發生時控制網絡負載。

圖 7 展示了三種常見的擁塞場景：在 2:1 超訂閲胖樹網絡中，彩色線條代表從源端到目的端的流量。右側第 4 組展示了典型的入向擁塞場景：節點 j、k、l、m 均向節點 I 發送流量。基於接收端信用的擁塞控制會檢測所有傳入流量，併爲每個流量分配 25% 的帶寬。每條流量旁標註的 「x/y%」 表示基於接收端信用的擁塞控制為該流量分配了 y% 的帶寬，實際交付速率為 x%；在入向擁塞場景下，帶寬利用率可達到*。基於網絡信號的擁塞控制最終也能達到相同的帶寬利用率，但所需時間更長（需通過快速自適應算法檢測丟包，或通過往返時間 / ECN 信號機制調整）。

左側第 1 組展示了與入向擁塞相反的出向擁塞場景：這種場景下，基於網絡信號的擁塞控制可輕松應對，但基於接收端信用的擁塞控制可能面臨挑戰。節點 O 向節點 p、q、r、v 發送流量，同時節點 w 也向節點 v 發送流量。基於接收端信用的擁塞控制會為節點 p、q、r 的傳入流量分配 100% 帶寬，為節點 v 的傳入流量分配 50% 帶寬（因節點 v 存在本地入向擁塞）。此時節點 O 的發送速率上限為 100%，因此會向每個目標節點發送 25% 的流量，這本身並無問題；但運行在節點 v 上的基於接收端信用的擁塞控制僅為來自節點 w 的流量分配 50% 帶寬，而實際可分配帶寬為 75%，導致 25% 的帶寬被浪費。基於網絡信號的擁塞控制雖然收斂速度較慢，但最終能調整到*配置。

中間第 2 組和第 3 組展示了更復雜的網絡內擁塞場景：第 2 組中標記為 「C」 的 12 個節點分別以線路速率向第 3 組中同樣標記為 「C」 的對應節點發送流量。在無阻塞網絡中，這種傳輸是可行的；但在超訂閲網絡中，瓶頸交換機（標記為 「B」）需接收 12 條流量，卻僅有 4 個上行端口，因此只能滿足 33% 的帶寬需求。若此時第 3 組中的節點 v 向某一 「C」 節點發送流量，運行在該 「C」 節點上的基於接收端信用的擁塞控制僅會為該流量分配 50% 帶寬，而實際可分配帶寬為 67%，再次導致帶寬利用率低下。

出向擁塞、入向擁塞和網絡內擁塞是推動使用基於網絡信號的擁塞控制的典型場景——儘管受信號傳播延迟影響，其收斂速度可能較慢。基於接收端信用的擁塞控制雖能*應對入向擁塞，但在兩種場景下仍需依賴基於網絡信號的擁塞控制，因此超以太網建議在啟用基於接收端信用的擁塞控制時，同時啟用基於網絡信號的擁塞控制。當然，在某些場景下（如全帶寬網絡且工作負載無出向擁塞模式），單獨使用簡單的基於接收端信用的擁塞控制算法也有望實現良好性能。

目的端流控制：通過擁塞控制調節網絡速率只是實現端點間成功數據傳輸的一部分。接收端、目的端內存或本地總線可能會因速度較慢或負載過高，無法始終以滿速率處理傳入數據包，這會導致目的端結構端點（FEP）與目的端內存之間出現丟包，進而需要重傳。超以太網的目的端流控制（DFC）是一種簡單協議，即便在網絡已允許的情況下，也能進一步限制發送端的速率。

在基於接收端信用的擁塞控制中，目的端流控制通過降低向發送端的信用額度分配速率實現，從而根據目的端擁塞情況調整發送速率；在基於網絡信號的擁塞控制中，接收端會向發送端發送一個 8 字節的擁塞窗口懲罰值，發送端利用該值調整擁塞窗口大小。目的端流控制能讓兩種算法快速響應目的端內存的瞬時或持續擁塞情況。

負載均衡：超以太網為可靠無序交付（RUD）和冪等操作可靠無序交付（RUDI）流量定義了多種負載均衡機制。在超以太網 1.0 版本中，特定數據包交付上下文（PDC）的所有可靠有序交付（ROD）流量必須沿同一條路徑傳輸。超以太網不允許端點選擇特定路徑，但可通過熵值（EV）控制路徑切換時機 —— 實際路徑由基於報頭（含熵值）的哈希函數決定。理論上，可構建僅將熵值作為輸入的特殊哈希函數系統，使端點能選擇特定路徑，但此類系統在處理故障時可能較為複雜。超以太網僅對無故障場景做*限度的保證：（1）相同熵值會選擇同一條路徑；（2）不同熵值大概率會選擇不同路徑，這通常可通過當前廣泛使用的高混淆度哈希函數實現。

超以太網傳輸層的設計確保即便每個數據包選擇不同的熵值/路徑，系統仍能正常運行，因此負載均衡可獨立於可靠性、擁塞控制等其他功能實現。需注意的是，超以太網的擁塞控制基於擁塞控制上下文（CCC）而非單條路徑實現，因此在整體系統架構設計中，必須考慮負載均衡與擁塞控制之間的相互作用。負載均衡策略在擁塞控制上下文層面實現，適用於所有關聯的數據包交付上下文。

最簡單的負載均衡方案是 「無感知噴灑」：源端擁塞控制上下文為每個注入的數據包分配不同的熵值。熵值的數量可能有限制，也可能隨機選擇，但這種方案不考慮路徑反饋信息。超以太網建議將無感知噴灑與數據包裁剪等快速丟包檢測機制結合使用，這樣既能快速恢復丟失的數據包，又能實現網絡流量的統計均衡。若同一流量類別的所有端點均配置無感知噴灑，且無其他流量干擾，該方案的效果*。

若存在其他流量（如可靠有序交付流量）共享網絡或流量類別，無感知噴灑的效果可能不佳。此類場景下，超以太網建議採用 「路徑感知噴灑」：通過跟蹤不同熵值對應的吞吐量來平衡負載。若收到裁剪數據包的否定確認（NACK）或帶 ECN-CE 標記的確認數據包，負載均衡方案會判定對應熵值的路徑存在擁塞。超以太網還提供了一種機制，可區分最后一跳的裁剪與網絡內的裁剪 —— 因調整熵值無法解決最后一跳的裁剪問題。超以太網通常將熵值選擇方式和路徑質量跟蹤方法交由具體實現決定，並提供了兩種示例選擇機制：

（1）循環熵值噴灑（REPS）：其最簡形式不維護任何端點狀態，依賴簡單的控制循環：發送數據包時，優先使用通過確認數據包返回的 「循環熵值」；若無可用循環熵值（如啟動階段），則隨機選擇新的熵值。這些熵值用於發送新數據包后，會通過確認數據包返回。該機制具有自計時特性 —— 例如，若存在一條慢路徑和一條快路徑，最終兩條路徑會因確認數據包的返回速率不同而均以*容量運行。在穩定狀態且網絡條件不變的情況下，循環熵值噴灑可收斂至每條路徑的*帶寬。

（2）超以太網規範中提及的另一種方案：在源端維護一組隨機熵值及對應的位圖。若某一熵值對應的路徑檢測到擁塞，源端會將位圖中對應位置的比特置 1；發送數據包時，源端會循環遍歷熵值，跳過位圖中比特為 1 的熵值；被跳過的熵值對應的比特會在后續操作中置 0，以便在下一輪循環中被重新選擇。熵值的數量可動態調整，以改變重試擁塞熵值的頻率。

超以太網中的所有負載均衡方案均為可選，廠商還可自行研發其他方案。不同負載均衡方案在網絡中可能存在複雜的相互影響，因此在系統設計時需格外注意。

傳輸層安全子系統（TSS）

超以太網在設計之初就充分考慮了安全性，其設計靈感源自 sRDMA 、ReDMArk ，以及 PSP、IPSec和 MACSec 規範。傳輸層安全子系統（TSS）採用 「零信任」 安全模型，為一組結構端點（FEP）之間提供端到端的機密性和認證服務。作為傳輸層安全服務，它不定義與主機內存的交互，但設計為可與 PCI Express 可信執行環境設備接口安全協議（TDISP）等機制協同工作，以提供完整的安全解決方案。語義子層（SES）、數據包交付子層（PDS）和傳輸層安全子層均支持多種計數器，可記錄可能表明攻擊行為的錯誤。

TSS 加密：傳輸層安全子系統（TSS）是一項可選服務，可對數據包交付子層（PDS）報頭、語義子層（SES）報頭、有效載荷以及數據包的 IP 地址進行認證。系統提供靈活配置選項，可選擇對數據包的哪些部分進行加密 —— 這需要在信息泄露風險與網絡可見性之間進行權衡。在零信任模型中，交換機不可信，但需提供擁塞和服務質量信息。因此，顯式擁塞通知（ECN）標記和數據包裁剪操作不進行認證，且會通過嚴格處理將攻擊面降至*（例如，裁剪數據包不得觸發數據包交付上下文（PDC）的創建）。

傳輸層安全子系統定義了 「安全域（SD）」 概念：安全域為一組結構端點提供機密性和認證服務，實現與其他安全域及未加密流量的完全數據隔離。一個安全域可服務於多個作業，也可專用於單個作業，以提供可擴展的架構。安全域的所有成員均使用相同的對稱加密安全域密鑰（SDK）作為認證和機密性服務的基礎，該密鑰由管理實體（SDME）分發給安全域的所有成員，同時管理實體還負責更新密鑰和維護安全域成員列表。

根據使用場景，SD提供了幾種機制來獲取用於每個數據包的symmetrickeys。最簡單的方法是直接使用SDK。第二種模式針對分佈式通信進行了優化，它使用密鑰推導函數(KDF)，這是一種確定性的不可逆函數，它從域密鑰和一些參數(例如源或目標地址)推導出源密鑰。最后，用於客户端-服務器通信的模式使用KDF和目標地址來推導每個源密鑰，從而提升服務器的擴展能力。

UE採用認證加密與關聯數據(AEAD)技術。默認算法為AESGCM。使用256b密鑰和16B身份驗證標籤或ICV(完整性校驗值)。一個關鍵的安全參數是密碼的初始化向量(IV)，它被當作一次性使用的數值，不得在羣組的所有成員間重複使用。SD的一個關鍵特性是，域中的所有成員都擁有相同的密鑰，而確保IV不被重複使用是該協議設計的關鍵部分。每個數據包中都包含一個時間戳計數器(TSC)，它由16位的紀元標識符和48位的包計數器組成紀元由SDME管理，用於協助成員的增加和移除，而包計數器則用於記錄FEP發送的每個數據包的遞增計數。

為應對 IETF（互聯網工程任務組）RFC 9001 附錄 B 中所述的、針對 「AES-GCM 算法因使用固定隨機數（nonce）、已認證數據及加密數據而遭受的攻擊」，傳輸安全子層（TSS）定義了一種初始化向量（IV）掩碼。在將數據包的 IV 輸入密碼算法之前，需先將該 IV 與 IV 掩碼進行異或運算。此操作可確保 IV 具備隨機性，且不會被攻擊者直接獲取。IV 掩碼既可以作為安全域（SD）的屬性進行存儲，也可以通過密鑰派生函數（KDF）生成。

提供了幾種機制來管理關鍵生命周期，即在此上下文中指的是使用同一密鑰加密的包數量。根據安全模型的假設(單用户 vs.多用户)，限制範圍在227到234.5個包之間。

密鑰輪換會更新安全域密鑰（SDK）與關聯編號（AN）。每個接收端會為每個安全域（SD）維護多個關聯編號密鑰（AN 密鑰），以支持無縫密鑰輪換。此外，還可將時間戳計數器（TSC）的部分字段接入密鑰派生函數（KDF），實現 「隨着數據包計數增加，自動周期性更新源端密鑰」 的功能。

防止重放攻擊：為防止數據包序列號（PSN）迴繞時出現重放攻擊，使用加密功能的每個數據包交付上下文（PDC）在發送 20 億個數據包后，必須關閉並重新建立。此外，數據包交付子系統（PDS）本質上是無狀態的，因此若其在建立新 PDC 時接受任意初始數據包序列號（PSN），可能容易遭受重放攻擊——初始數據包中攜帶的事務可能會以非預期方式修改目標端狀態。因此，在使用加密功能時，數據包交付子系統需通過以下兩種方式之一安全地建立初始數據包序列號（PSN）。

*種方式需額外增加一個往返時間（RTT）來建立安全的 PSN：發起方向目標端發送的*個數據包為 「無操作」（NOP）數據包，用於查詢起始 PSN；目標端隨后返回本地已知的隨機起始 PSN，並創建處於 「待處理」 狀態的 PDC。儘管該方案通過協商隨機起始 PSN 可防止重放攻擊，但額外增加的 RTT 可能不符合部分場景的需求。

第二種方案支持 「零開銷啟動」，但需在安全域（SD）內進行一定協調：為每個安全域關聯存儲兩個初始值均為 0 的參數——start_psn和expected_psn。其中，start_psn用於新請求建立的 PDC，expected_psn則是新接入 PDC 的最小可接受 PSN。若目標端收到的連接請求中 PSN 小於expected_psn，會生成否定確認（NACK）並指明應使用的起始 PSN；反之則接受該請求。當某個 PDC 關閉時，目標端會將expected_psn更新為該關閉 PDC 的當前 PSN+1，確保無法進行重放攻擊。更新后的expected_psn會隨 PDC 關閉確認（ACK）數據包反饋給源端，源端隨后將start_psn更新為該值，以確保后續連接可實現 「零 RTT」 建立。該方案無法保證始終實現零 RTT PDC 建立，失敗時會回退到 「一 RTT」 建立方式，同時允許通過額外啓發式算法設置start_psn或expected_psn，以提高零 RTT 建立的概率。兩種方案可實現互操作。

鏈路層特性

超以太網兼容的鏈路層引入了兩項獨立的可選特性：鏈路層重試（LLR）和基於信用的流控制（CBFC）。為保持以太網兼容性，鏈路層通過鏈路層發現協議（LLDP）與對等設備協商是否啟用這兩項特性。

鏈路層重試（LLR）：隨着鏈路帶寬的提升和誤碼率的潛在增加，傳統端到端重傳機制可能對延迟敏感型工作負載產生負面影響。鏈路層重試（LLR）機制可在傳輸以太網幀時，在鏈路層本地處理錯誤：發送端將所有符合 LLR 條件的幀存儲在重放緩衝區中，並在幀的前導碼中編碼序列號；接收端鏈路在成功接收幀后，向源端發送確認（ACK），以釋放源端的重放緩衝區。對於末尾數據包的恢復，採用 「回退 N 幀」（go-back-N）重傳機制——根據幀的到達順序檢測缺失的序列號，併發送否定確認（NACK）；同時，通過重傳超時機制防止末尾數據包（尾部丟失）或 NACK 丟失。確認（ACK）、否定確認（NACK）等控制數據包通過物理層（PHY Layer）的物理編碼子層（PCS）子系統發送，編碼為 8 字節的控制有序集（Control Ordered Sets）。

從超以太網傳輸層（UET）的新協議設計背景來看——其部分設計初衷是消除重傳超時和 「回退 N 幀」 重傳機制——鏈路層選擇上述方案看似矛盾，但鏈路層環境與跨大規模系統的傳輸層環境存在本質差異：在鏈路層環境中，重傳超時可嚴格限定在鏈路往返時間（約 1 微秒）內，且數據包僅因物理層錯誤（如無法糾正的前向糾錯（FEC）符號錯誤或幀校驗序列（FCS）錯誤）被丟棄，擁塞不會導致數據包丟棄或影響往返時間。因此，採用 「回退 N 幀」 協議並輔以短重傳超時機制已足夠滿足需求，同時可避免鏈路層需理解流量排序要求的複雜設計。

基於信用的流控制（CBFC）：超以太網的基於信用的流控制（CBFC）提供鏈路層流控功能，可與融合以太網的基於優先級的流控制（PFC）配合使用，也可替代 PFC。兩種方案的目標均是提供近無損的數據包服務，消除因到達數據包缺乏緩衝空間導致的擁塞丟包——此類擁塞丟包是採用 「回退 N 幀」 重傳策略的端到端可靠系統（如超以太網的可靠有序交付（ROD）服務）性能下降的主要原因。即便擁塞管理機制已優化，交換機緩衝區溢出、網絡路徑過長、流量模式高度可變等因素仍可能導致數據包丟失，而通過端到端（E2E）重傳協議解決此類丟失至少需額外增加一個 RTT 延迟。CBFC 或 PFC 可通過構建無損鏈路層（第二層）網絡結構，優化上述場景的性能。

與 PFC 相比，CBFC 具有以下優勢：

（1）保障交付所需的緩衝空間更小；

（2）發送端可利用各虛擬通道的信用可用信息進行本地調度；

（3）配置更簡單，易於實現保障交付；

（4）對吞吐量有限制的虛擬通道，可使用更少的緩衝空間。

為實現無損操作，PFC 要求每個端口配備 「RTT+MTU」 大小的頭部緩衝空間。從交換機角度而言，有多種方式可優化頭部緩衝空間，但 CBFC 能更高效地分配和管理該緩衝空間，具體細節可參考 Hoefler 等人的研究。

CBFC 在發送端和接收端均使用兩個 20 位循環計數器，根據緩衝區佔用情況跟蹤 「已消耗信用」 和 「接收端釋放的信用」。這些計數器按虛擬通道分別維護，並定期同步以避免信用丟失。超以太網的 CBFC 定義兩種消息類型：一是從接收端發送至發送端的高頻更新消息，編碼為 8 字節控制有序集；二是從發送端發送至接收端的低頻更新消息，編碼為 64 字節數據包。

發送端在發送數據包前，會先本地檢查信用可用性；數據包發送后，從信用中扣除該數據包大小。接收端在數據包離開其緩衝區后，通過更新消息將信用返還給發送端。發送端會定期向接收端發送更新消息，防止信用丟失。總體而言，該協議可確保僅當接收端有足夠緩衝空間時，發送端纔會發送數據包。

總結與結論

超以太網（UE）的研發歷時 30 個月，凝聚了眾多參與者的努力。其 1.0 版本在多個領域實現創新，助力以太網生態系統為人工智能（AI）和高性能計算（HPC）工作負載提供高效、經濟且安全的網絡支持。*版本的規範后續大概率需要經過多輪勘誤澄清與修復。目前，首批超以太網相關產品已正式發佈，預計數月內可投入使用。

參考鏈接

[1] 2018. IEEE Standard for Local and metropolitan area networks—Media Access Control (MAC) Security (MACsec).

https://standards.ieee.org/standard/802_1AE-2018.html

[2] Randall Atkinson. 1995. Security Architecture for the Internet Protocol. Internet Draft draft-ietf-ipsec-arch-00. Internet

Engineering Task Force. https://datatracker.ietf.org/doc/html/draft-ietf-ipsec-arch-00 Work in progress; expires

September 23, 1995.

[3] Maciej Besta and Torsten Hoefler. 2014. Slim Fly: A Cost Effective Low-Diameter Network Topology. Proceedings of

the International Conference on High Performance Computing, Networking, Storage and Analysis (SC14).

[4] Maciej Besta, M. Podstawski, L. Groner, Edgar Solomonik, and Torsten Hoefler. 2017. To Push or To Pull: On Reducing

Communication and Synchronization in Graph Computations. In Proceedings of the 26th International Symposium on

High-Performance Parallel and Distributed Computing (HPDC’17) (Washington, DC, USA). ACM.

[5] Tommaso Bonato, Abdul Kabbani, Ahmad Ghalayini, Michael Papamichael, Mohammad Dohadwala, Lukas Gianinazzi,

Mikhail Khalilov, Elias Achermann, Daniele De Sensi, and Torsten Hoefler. 2025. REPS: Recycled Entropy Packet

Spraying for Adaptive Load Balancing and Failure Mitigation. arXiv:2407.21625 [cs.NI] https://arxiv.org/abs/2407.21625

[6] Tommaso Bonato, Abdul Kabbani, Daniele De Sensi, Rong Pan, Yanfang Le, Costin Raiciu, Mark Handley, Timo

Schneider, Nils Blach, Ahmad Ghalayini, Daniel Alves, Michael Papamichael, Adrian Caulfield, and Torsten Hoefler.

2024. SMaRTT-REPS: Sender-based Marked Rapidly-adapting Trimmed and Timed Transport with Recycled Entropies.

arXiv:2404.01630 [cs.NI] https://arxiv.org/abs/2404.01630

[7] Tommaso Bonato, Daniele De Sensi, Salvatore Di Girolamo, Abdulla Bataineh, David Hewson, Duncan Roweth, and

Torsten Hoefler. 2025. Flowcut Switching: High-Performance Adaptive Routing with In-Order Delivery Guarantees.

arXiv:2506.21406 [cs.NI] https://arxiv.org/abs/2506.21406

[8] R. Brightwell, S. Goudy, and K. Underwood. 2005. A preliminary analysis of the MPI queue characterisitics of several

applications. In 2005 International Conference on Parallel Processing (ICPP’05). 175–183. doi:10.1109/ICPP.2005.13

[9] Ronald Brightwell, William Schonbein, Kevin Pedretti, Karl Scott Hemmert, Arthur B. Maccabe, Ryan E. Grant, Brian W.

Barrett, Keith Underwood, Rolf Riesen, Torsten Hoefler, et al. 2022. The Portals 4.3 Network Programming Interface.

Technical Report. Sandia National Lab. (SNL-NM), Albuquerque, NM (United States). doi:10.2172/1875218

[10] Peng Cheng, Fengyuan Ren, Ran Shu, and Chuang Lin. 2014. Catch the whole lot in an action: rapid precise packet

loss notification in data centers. In Proceedings of the 11th USENIX Conference on Networked Systems Design and

Implementation (Seattle, WA) (NSDI’14). USENIX Association, USA, 17–28.

[11] Inc. Cray Research. 1993. Cray T3D System Architecture Overview. Technical Report HR-04033. Cray Research, Inc. https:

//cray-history.net/wp-content/uploads/2021/08/HR-04033_CRAY_T3D_System_Architecture_Overview_Sep93.pdf

[12] Dally and Seitz. 1987. Deadlock-Free Message Routing in Multiprocessor Interconnection Networks. IEEE Trans.

Comput. C-36, 5 (1987), 547–553. doi:10.1109/TC.1987.1676939

[13] Daniele De Sensi, Salvatore Di Girolamo, Kim H. McMahon, Duncan Roweth, and Torsten Hoefler. 2020. An In-Depth

Analysis of the Slingshot Interconnect. In SC20: International Conference for High Performance Computing, Networking,

Storage and Analysis. 1–14. doi:10.1109/SC41405.2020.00039

[14] Morris Dworkin. 2007. Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and

GMAC. Technical Report SP 800-38D. National Institute of Standards and Technology (NIST), Gaithersburg, MD.

https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38d.pdf

[15] Jerónimo S. García, Salvatore Di Girolamo, Sokol Kosta, J. J. Vegas Olmos, Rami Nudelman, Torsten Hoefler, and Gil

Bloch. 2025. Offloaded MPI message matching: an optimistic approach. In Proceedings of the SC ’24 Workshops of the

International Conference on High Performance Computing, Network, Storage, and Analysis (Atlanta, GA, USA) (SC-W

’24). IEEE Press, 457–469. doi:10.1109/SCW63240.2024.00067

[16] Deepak Goel, Mattheus C. Heddes, Torsten Hoefler, and Xinyuan Xu. 2024. Message communication between integrated

computing devices.

[17] Google LLC. 2022. PSP Architecture Specification. Google LLC. https://github.com/google/psp/blob/main/doc/psp-

architecture-specification.pdf Open source release; version 1.0.

[18] Mark Handley, Costin Raiciu, Alexandru Agache, Andrei Voinescu, Andrew W. Moore, Gianni Antichi, and Marcin

Wójcik. 2017. Re-architecting datacenter networks and stacks for low latency and high performance. In Proceedings of

the Conference of the ACM Special Interest Group on Data Communication (Los Angeles, CA, USA) (SIGCOMM ’17).

Association for Computing Machinery, New York, NY, USA, 29–42. doi:10.1145/3098822.3098825

[19] Torsten Hoefler, Tommaso Bonato, Daniele De Sensi, Salvatore Di Girolamo, Shigang Li, Marco Heddes, Jon Belk,

Deepak Goel, and Steve Scott Miguel Castro. 2022. HammingMesh: A Network Topology for Large-Scale Deep

Learning. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and

Analysis (SC’22).

[20] Torsten Hoefler, Ariel Hendel, and Duncan Roweth. 2022. The Convergence of Hyperscale Data Center and High-

Performance Computing Networks. Computer 55, 7 (2022), 29–37. doi:10.1109/MC.2022.3158437

[21] Torsten Hoefler, Duncan Roweth, Keith Underwood, Robert Alverson, Mark Griswold, Vahid Tabatabaee, Mohan

Kalkunte, Surendra Anubolu, Siyuan Shen, Moray McLaren, Abdul Kabbani, and Steve Scott. 2023. Data Center Ethernet

and Remote Direct Memory Access: Issues at Hyperscale. Computer 56, 7 (2023), 67–77. doi:10.1109/MC.2023.3261184

[22] InfiniBand Trade Association. 2000. InfiniBand Architecture Specification Volume 1, Release 1.0. Technical Report.

InfiniBand Trade Association. Available at https://www.infinibandta.org/.

[23] InfiniBand Trade Association (IBTA). 2007. InfiniBand Architecture Specification Volume 1. Technical Report. InfiniBand

Trade Association. https://www.infinibandta.org/ Latest available version at https://www.infinibandta.org/, accessed

on August 13, 2025. Consult Chapter 11 for Verbs definitions..

[24] Sushant Jain, Alok Kumar, Subhasree Mandal, Joon Ong, Leon Poutievski, Arjun Singh, Subbaiah Venkata, Jim Wanderer,

Junlan Zhou, Min Zhu, Jon Zolla, Urs Hölzle, Stephen Stuart, and Amin Vahdat. 2013. B4: experience with a globally-

deployed software defined wan. SIGCOMM Comput. Commun. Rev. 43, 4 (Aug. 2013), 3–14. doi:10.1145/2534169.2486019

[25] Norman P. Jouppi, Cliff Young, Nishant Patil, David Patterson, Gaurav Agrawal, Raminder Bajwa, Sarah Bates, Suresh

Bhatia, Nan Boden, Al Borchers, Rick Boyle, Pierre-luc Cantin, Clifford Chao, Chris Clark, Jeremy Coriell, Mike

Daley, Matt Dau, Jeffrey Dean, Ben Gelb, Tara Vazir Ghaemmaghami, Rajendra Gottipati, William Gulland, Robert

Hagmann, C. Richard Ho, Doug Hogberg, John Hu, Robert Hundt, Dan Hurt, Julian Ibarz, Aaron Jaffey, Alek Jaworski,

Alexander Kaplan, Harshit Khaitan, Daniel Killebrew, Andy Koch, Naveen Kumar, Steve Lacy, James Laudon, James Law,

Diemthu Le, Chris Leary, Zhuyuan Liu, Kyle Lucke, Alan Lundin, Gordon MacKean, Adriana Maggiore, Maire Mahony,

Kieran Miller, Rahul Nagarajan, Ravi Narayanaswami, Ray Ni, Kathy Nix, Thomas Norrie, Mark Omernick, Narayana

Penukonda, Andy Phelps, Jonathan Ross, Matt Ross, Amir Salek, Emad Samadiani, Chris Severn, Gregory Sizikov,

Matthew Snelham, Jed Souter, Dan Steinberg, Andy Swing, Mercedes Tan, Gregory Thorson, Bo Tian, Horia Toma,

Erick Tuttle, Vijay Vasudevan, Richard Walter, Walter Wang, Eric Wilcox, and Doe Hyun Yoon. 2017. In-Datacenter Performance Analysis of a Tensor Processing Unit. In Proceedings of the 44th Annual International Symposium on Computer Architecture (Toronto, ON, Canada) (ISCA ’17). Association for Computing Machinery, New York, NY, USA, 1–12. doi:10.1145/3079856.3080246

[26] John Kim, Wiliam J. Dally, Steve Scott, and Dennis Abts. 2008. Technology-Driven, Highly-Scalable Dragonfly Topology.

SIGARCH Comput. Archit. News 36, 3 (June 2008), 77–88. doi:10.1145/1394608.1382129

[27] Yanfang Le, Rong Pan, Peter Newman, Jeremias Blendin, Abdul Kabbani, Vipin Jain, Raghava Sivaramu, and Francis

Matus. 2024. STrack: A Reliable Multipath Transport for AI/ML Clusters. arXiv:2407.15266 [cs.NI] https://arxiv.org/

abs/2407.15266

[28] Radhika Mittal, Vinh The Lam, Nandita Dukkipati, Emily Blem, Hassan Wassel, Monia Ghobadi, Amin Vahdat, Yaogong

Wang, David Wetherall, and David Zats. 2015. TIMELY: RTT-based Congestion Control for the Datacenter. SIGCOMM

Comput. Commun. Rev. 45, 4 (Aug. 2015), 537–550. doi:10.1145/2829988.2787510

[29] K. Ramakrishnan, S. Floyd, and D. Black. 2001. The Addition of Explicit Congestion Notification (ECN) to IP. Request for

Comments 3168. Internet Engineering Task Force. https://www.rfc-editor.org/info/rfc3168

[30] Benjamin Rothenberger, Konstantin Taranov, Adrian Perrig, and Torsten Hoefler. 2021. ReDMArk: Bypassing RDMA

Security Mechanisms. In USENIX Security Symposium (USENIX Security 21). 4277–4292. https://www.usenix.org/

conference/usenixsecurity21/presentation/rothenberger

[31] Steve Scott and Greg Thorson. 1994. Optimized routing in the Cray T3D. In Parallel Computer Routing and Communi-

cation, Kevin Bolding and Lawrence Snyder (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 281–294.

[32] Leah Shalev, Hani Ayoub, Nafea Bshara, and Erez Sabbag. 2020. A Cloud-Optimized Transport Protocol for Elastic and

Scalable HPC. IEEE Micro 40, 6 (2020), 67–73. doi:10.1109/MM.2020.3016891

[33] Yong Ho Song and T.M. Pinkston. 2003. A progressive approach to handling message-dependent deadlock in parallel

computer systems. IEEE Transactions on Parallel and Distributed Systems 14, 3 (2003), 259–275. doi:10.1109/TPDS.2003.

1189584

[34] Konstantin Taranov, Benjamin Rothenberger, Adrian Perrig, and Torsten Hoefler. 2020. sRDMA: efficient NIC-based

authentication and encryption for remote direct memory access. In Proceedings of the 2020 USENIX Conference on

Usenix Annual Technical Conference (USENIX ATC’20). USENIX Association, USA, Article 47, 14 pages.

[35] Ultra Ethernet Consortium. 2025. Ultra Ethernet Specification Version 1.0. https://ultraethernet.org/uec-1-0-spec.

Accessed on August 13, 2025.

[36] Erico Vanini, Rong Pan, Mohammad Alizadeh, Parvin Taheri, and Tom Edsall. 2017. Let it flow: resilient asymmetric

load balancing with flowlet switching. In Proceedings of the 14th USENIX Conference on Networked Systems Design and

Implementation (Boston, MA, USA) (NSDI’17). USENIX Association, USA, 407–420.

[37] Tim S. Woodall, Galen M. Shipman, George Bosilca, Richard L. Graham, and Arthur B. Maccabe. 2006. High Performance

RDMA Protocols in HPC. In Recent Advances in Parallel Virtual Machine and Message Passing Interface, Bernd Mohr,

Jesper Larsson Träff, Joachim Worringen, and Jack Dongarra (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg,

76–85.

[38] Yibo Zhu, Haggai Eran, Daniel Firestone, Chuanxiong Guo, Marina Lipshteyn, Yehonatan Liron, Jitendra Padhye,

Shachar Raindel, Mohamad Haj Yahia, and Ming Zhang. 2015. Congestion Control for Large-Scale RDMA Deployments.

SIGCOMM Comput. Commun. Rev. 45, 4 (Aug. 2015), 523–536. doi:10.1145/2829988.2787484

致謝本文作者：