1、1數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004編號 ODCC-2023-03004數據中心高性能網絡擁塞檢測技術白皮書（2023 年）中移（蘇州）軟件技術有限公司中國信息通信研究院云計算與大數據研究所2023-09 發布I數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004版權聲明版權聲明本白皮書版權屬于中國移動通信集團公司、中國信息通信研究院并受法律保護。轉載、摘編或利用其他方式使用本白皮書內容或觀點，請注明：“來源：數據中心高性能網絡擁塞檢測技術白皮書”。違反上述聲明者，編者將追究其相關法律責任。II數據中心高性能網絡擁塞

2、檢測技術白皮書（2023 年）ODCC-2023-03004編寫組編寫組項目經理：項目經理：趙興華中國移動云能力中心工作組長：工作組長：王超阿里云計算有限公司貢獻專家：貢獻專家：徐軍中國移動云能力中心劉軍衛中國移動云能力中心姚軍中國移動云能力中心孟令坤中國移動云能力中心王東旭中國移動云能力中心張勝舉中國移動云能力中心孫偉云脈芯連科技有限公司張久仙中國移動云能力中心季忠銘中國移動云能力中心許治國中國移動云能力中心潘訓營中國移動云能力中心史成龍中國移動云能力中心陳繼磊中國移動云能力中心楊亞軍中國移動云能力中心王曉輝中國移動云能力中心郝泉澄中國移動云能力中心薛遷中國移動云能力中心徐軍中國移動云能力中

3、心III數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004目目 錄錄版權聲明.I編寫組.II術語與縮略語.VI前言.1一、高性能網絡的機遇與挑戰.3（一）應用背景與現狀.41 分布式儲存場景.42 內存池化場景.63 鍵值存儲場景.74 智能算力場景.9（二）高性能網絡擁堵問題與挑戰.10二、擁塞管理與控制技術體系.13（一）擁塞控制技術.131 基于 ECN 的擁塞控制.142 基于時延的擁塞控制.143 基于 INT 的擁塞控制.154 其他技術方案.165 擁塞控制總結.18（二）鏈路控制技術.211 信用.212 PFC.233 QCN.25IV數據中心

4、高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-030044 鏈路控制總結.26（三）負載均衡技術.271 流級別.272 包級別.293 Flowlet 級別.294 負載均衡總結.30（四）流量調度技術.311 基于規則的調度技術.322 基于反饋的實時調度.343 流量調度總結.34（五）本章小結.35三、高性能網絡擁塞檢測技術.36（一）網側擁塞檢測.371 ECN 檢測.372 TCD 檢測.413 其他檢測技術.42（二）端側擁塞檢測.421 RTT 檢測.432 優先級隊列檢測.44（三）端側協同擁塞檢測.451 INT 檢測.452 ECN#檢測.463 Con

5、Ex 檢測.484 本章小結.49V數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004四、總結與展望.50參考文獻.52VI數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004術語與縮略語術語與縮略語TermTermMeaningMeaningRDMARemote Direct Memory AccessRoCERDMA over Converged EthernetiWarpinternet Wide Area RDMA ProtocolGPUGraphics Processing UnitIOPSInput/Output Ope

6、rations Per SecondSRDScalable Reliable DatagramAWSAmazon Web ServicesDPUData Processing UnitRNICRDMA Network Interface CardECNExplicit Congestion NotificationDCQCNData Center Quantized Congestion NotificationHPCCHigh Precision Congestion ControlPFCPriority Flow ControlREDRandom Early DetectionAQMAct

7、ive Queue ManagementRTTRound Trip TimeINTIn-Net TelemetryECMPEqual-Cost Multi-PathTCDTernary Congestion DetectionCBFCCredit-Based Flow ControlPFCPriority-based Flow ControlQCNQuantized Congestion NotificationRPSRandom Packet SprayingCONGADistributed Congestion-Aware Load BalancingFCTFlow Complete Ti

8、meREDRandom Early DetectionBCNBackward Congestion NotificationFECNForward Explicit Congestion NotificationPCNPre-Congestion NotificationHPQHigh Priority QueueLPQLow Priority Queue1數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004前前 言言“十四五”數字經濟發展規劃中指出數字經濟是繼農業經濟、工業經濟之后的主要經濟形態，是以數據資源為關鍵要素，以現代信息網絡為主要載體，以信息通信技術融

9、合應用、全要素數字化轉型為重要推動力，促進公平與效率更加統一的新經濟形態。隨著數字經濟的持續發展，算力需求呈爆發性增長，逐步成為新時代的核心生產力。算力的發展帶動了網絡的變革，構建了高效、靈活、敏捷的數據中心網絡新型基礎設施，成為算力網絡驅動和演進的關鍵。遠程直接內存訪問（Remote Direct Memory Access，RDMA）網絡是一種高性能網絡傳輸技術。通過繞過操作系統內核，RDMA 可以直接在網絡適配器和內存之間傳送數據，從而減少了數據傳輸過程帶來的延遲和 CPU 開銷，提高了數據傳輸的效率和吞吐量。近年來，高性能網絡廣泛應用于高性能計算、云計算、大數據處理等領域，成為當下網絡

10、領域的研究熱點之一。高性能網絡的重要性在于，為各種應用提供了快速、可靠、安全的數據傳輸能力，并將數據中心、云計算和大數據處理等領域的計算資源、存儲資源和網絡資源緊密結合，提高了整個系統的效率和性能。同時，高性能網絡還可以支持更多的應用和服務，促進了科學研究、產業發展和社會進步。因此，高性能網絡的發展和研究是當前網絡領域的重要方向。2數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004本白皮書通過闡明和分析高性能網絡技術發展的過程與現狀，以網絡擁塞這一關鍵問題展開詳述當前業界擁塞管理控制技術的架構體系，并聚焦擁塞管理控制過程中面臨不同需求所產生的擁塞檢測機制。本白皮

11、書旨在通過對擁塞檢測技術的研究，推動高性能網絡技術的深入發展、生態鏈建設和產業落地。3數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004一、一、高性能網絡的機遇與挑戰高性能網絡的機遇與挑戰在需求端強力驅使下，過去的 10 年中，數據中心網絡鏈路傳輸帶寬經歷了從 1 Gbps 到 100Gbps 的快速增長，并且這一增長趨勢仍在持續。因此，作為未來數據中心服務的提供者，云計算廠商面臨著越來越嚴苛的數據中心網絡建設需求。目前，傳統數據中心應用的 TCP/IP 網絡已經難以高效地滿足新的需求。一方面，快速膨脹的鏈路速率導致了極高的 CPU 占用率，每增加一個用于 TC

12、P 網絡傳輸的 CPU 資源意味著云計算廠商能夠出售的虛擬機減少了一個，這將降低整體的經濟效益。另一方面，機器學習、搜索等業務所要求的超低的網絡延遲（低于 10 us/跳）,傳統的 TCP/IP 協議的性能是很難達到的。為解決這一問題，遠程直接內存獲?。≧emote Direct MemoryAccess,RDMA）技術開始逐漸廣泛地應用于數據中心網絡中（本文提及的 RDMA 無損網絡針對更廣泛應用的以太網絡，如無特殊聲明，適用協議為 RoCEv2）。相較于傳統的 TCP/IP，RDMA 有著如下的優勢：1）降低了 CPU 占用率。數據傳輸過程不再需要 CPU 的持續介入，而是通過硬件卸載的形

13、式完成數據傳輸。2）降低了傳輸時延，避免了數據拷貝過程中頻繁的用戶態和內核態切換。因此，通過硬件卸載、內核旁路，RDMA 完成了數據傳輸和計算的解耦，從而實現高效的并行計算處理。4數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004正因為以上的技術優勢，高性能網絡已經成為云計算領域應用廣泛核心基礎設施之一。據公開文獻1顯示，在微軟 Azure 存儲集群中，RDMA 流量已經占據了超過一半的比例。在可以預見的未來，高性能網絡技術都將作為云計算領域的核心基礎設施之一，深刻地影響數據中心技術格局。圖 1 微軟 Azure 存儲集群流量占比1（一）（一）應用背景與現狀應用

14、背景與現狀隨著云計算技術的發展，高性能網絡的應用場景日益增多。本節主要從分布式云存儲、內存池化、鍵值存儲、智算中心四個方向的應用，對高性能網絡的應用場景和應用現狀進行概述。1 1分布式儲存場景分布式儲存場景分布式存儲是云計算中的一個核心應用。各家云廠商都會提供高達百萬輸入/輸出操作每秒（IOPS）的高性能存儲實例，旨在滿足對性能要求極高的應用場景。5數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004由于百萬 IOPS 云硬盤需要同時處理大量的讀取和寫入請求，這就要求了網絡要提供極高的吞吐量和極低的響應時間。因此，主流云廠商普遍選擇 RDMA 作為高性能分布式存儲

15、的網絡解決方案，如公開文獻中阿里云、微軟云等關于分布式云存儲的工作1,2。圖 2 云存儲基本架構圖阿里云 EBS 云存儲中應用的阿里自研網絡協議棧 Solar3，對云存儲 IO 延遲進行了全面優化。論文中給出了 EBS 產品詳細的網絡延遲性能測評。圖 3 中的數據為阿里云超過 10 萬個計算節點一周時間的測試結果。在圖中，Kernal 是傳統的 TCP/IP 協議，Luna 是用戶態加速協議棧，Solar 是阿里自研的 RDMA 網絡，FN 是計算是存儲的前端網絡，BN 是存儲集群后端網絡，SSD 是落盤網絡，SA 是阿里自研的 SPDK 軟件。該實驗很好的對比了內核態、用戶態、RDMA 對于

16、存儲業務的影響?？梢钥吹?，整體 IO 延遲性能上，Solar RDMA6數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004協議有明顯的優勢。同時，RDMA 網絡協議棧還在很大程度上改善了整個網絡的長尾時延問題，性能實現了數量級的提升。圖 3 阿里云 EBS 網絡性能對比測試2 2內存池化場景內存池化場景圖 4 內存池化的分布式數據中心現有的數據中心是通過服務器構建的，每個服務器緊密集成了計算任務所需的各種資源（CPU、內存、存儲）。雖然這種以服務器為中心的架構已經持續使用了幾十年，但最近的研究表明，未來即將出現一種向分解式數據中心（Disaggregated D

17、atacenter，DDC）轉變的范式。其中，每種資源類型都作為獨立的資源池進行構建，而網絡結構則用于連接這些資源池4。7數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004資源池化的一個關鍵的促進（或阻礙）因素將是網絡。因為將CPU 與內存、磁盤分解開來，原本需要在服務器內部進行的資源間通信，而現在必須通過網絡進行。因此，為了支持良好的應用級性能，網絡結構必須提供低延遲的通信以應對這種負載更大的情況。因此，RDMA 高性能網絡作為一個解決方案在內存池化的場景已經有廣泛的研究5,6。RDMA 有效地提升了內存池化數據中心的效率。盡管沒有完全解決資源池化場景的網絡互

18、連問題，但其仍然是未來分布式數據中心的一個有力的網絡技術方案。3 3鍵值存儲場景鍵值存儲場景圖 5 基于 RDMA 的鍵值存儲系統7鍵值存儲（Key-Value Store）是一種數據存儲方法，它以鍵值對（Key-Value Pair）的形式存儲和訪問數據。與傳統的關系型數據庫相比，鍵值存儲通常更加簡單、靈活、高效，并且可以處理更大規模的數據。鍵值存儲不要求數據具有固定的結構和模式，因此8數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004可以輕松地存儲和檢索各種類型的數據。鍵值存儲還支持高度可擴展性和分布式部署，可以輕松地在多個節點上進行水平擴展和數據復制以提高

19、性能和可靠性。在常見應用中，Redis 就是一種流行的鍵值存儲系統。它支持多種數據類型，包括字符串、哈希、列表、集合和有序集合等。與關系型數據庫不同，Redis 不支持復雜的 SQL 查詢語句，而是提供了一組簡單的操作命令，如 GET、SET、INCR、DECR、LPUSH、RPUSH、SADD、SMEMBERS 等，以實現鍵值對的讀寫和操作。然而，在鍵值存儲中，CPU 是一個顯而易見的性能瓶頸。而RDMA 技術通過繞過內核的方式直接訪問內存，這能夠保證 CPU 資源的高效利用。因此，RDMA 技術在鍵值存儲系統中的應用也逐漸被更多的討論7,8。同時，阿里云也公開聲明了其 eRDMA 技術在

20、Redis產品中的應用9。從測試結果可以看出，無論是 GET 測試還是 SET測試，eRDMA 相對于 TCP 帶來了至少 40%以上的性能測試數據提升。圖 6 RDMA 技術加速 Redis 服務9數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-030044 4智能算力場景智能算力場景圖 7 智算中心高性能網絡組網方案近年來,大型語言模型如 GPT 等在自然語言處理任務上的強大能力引起了廣泛關注。這些模型通過預訓練在海量文本數據上獲取語言知識,然后進行微調應用于下游任務。大模型以極大的模型尺寸、大量數據和計算資源進行訓練。其一系列成果顯示了大模型具備了通過無監督學習獲

21、取語言理解能力的潛力。但是訓練大模型也帶來了巨大的計算和環境成本，需要大規模高速互聯的智算中心，其原因如下：a)模型參數量巨大,單機單卡無法加載整個模型。而使用多機多卡可以將訓練的參數梯度分布在不同設備上。b)訓練時間長。如果只使用單機單卡,訓練大模型往往需要非常長的時間。多機多卡情況下，并行計算可以大幅減少訓練時間。10數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004c)訓練數據量大。多機多卡并行讀取數據后匯總梯度，產生了大量的網絡帶寬需求。因此，在智算中心場景下，高性能 RDMA 網絡實現多個服務器、多個 GPU 的互聯，打造多通道、無收斂、多路徑的參數網

22、絡（如圖5 所示），是當前的主流技術方案之一。AWS 在其超算、智算服務中廣泛的提供 SRD 高性能網絡服務10，進一步的引起了行業內對高性能網絡技術的大規模投入。（二）（二）高性能網絡擁堵問題與挑戰高性能網絡擁堵問題與挑戰高性能網絡已經成為云計算領域應用廣泛核心基礎設施之一。然而，RDMA 網絡中出現擁塞問題將會大幅降低網絡的吞吐和延遲性能，這也成為了限制 RDMA 網絡應用規模的重要因素。當網絡中的數據流量超過了網絡鏈路的處理能力或帶寬限制或者當多個節點同時進行 RDMA 通信時，網絡鏈路無法及時處理或傳輸所有的數據包，就會發生擁塞。擁塞一方面會導致交換機的緩存隊列增大，數據包傳輸的延遲等

23、比例的延長，使網絡服務質量下降；另一方面，交換機中數據包堆積，會觸發 PFC 機制，以保證 RoCE 網絡的無損特性，這導致網絡中會出現一系列相應的風暴、死鎖等問題11。這也一定程度上限制了 RDMA 網絡在以太網環境的部署規模和網絡性能。因此，近年來在11數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004RDMA 高性能網絡方向聚焦擁塞問題，產生了大量的前沿研究和工程實踐工作?？傊?，隨著未來數據中心網絡帶寬需求的不斷增長，RDMA 高性能網絡在云計算、人工智能等領域具有巨大的機遇。同時，擁塞問題作為 RDMA 網絡中限制規模、性能的主要瓶頸，形成標準化、規范化

24、的擁塞管控系統，將已有技術進行歸納延伸，是當前數據中心網絡中迫切要完成的一項工作。擁塞檢測技術中，有如下幾點挑戰亟需解決：a)精度、頻率和開銷的矛盾。對于網絡擁塞信息的檢測，當前存在多種主流方案，其獲取的擁塞信息都不相同，但都遵循“沒有免費的午餐”這一規則。更高的測量精度、更快的測量頻率，都會帶來額外的網絡帶寬開銷（例如 INT 對比 ECN）。這需要對不同的場景需求進行深入的研究，以實現最佳的擁塞檢測效果。b)標準和兼容性：RDMA 技術存在多種標準和實現，如InfiniBand、RoCE（RDMA over Converged Ethernet）和 iWARP（Internet Wide

25、Area RDMA Protocol）。其中，RoCE 網絡的發展近年來尤為迅猛。原有的以太網擁塞檢測機制和協議在 RDMA 網絡中該如何規范化，這也是未來不同 RoCE 網絡設備廠商和用戶潛在的問題。12數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004c)跨層級應用：不同的擁塞檢測機制可以在更多的擁塞管控技術層級進行應用。比如，RTT、ECN 的擁塞信息可以作為流量調度、負載均衡的參考權重。這些研究工作雖然已經較多，但哪些擁塞檢測機制適合哪種層級的擁塞管控協議仍是需要進一步探討的問題。本白皮書通過闡明和分析高性能網絡擁塞管控的技術發展的過程與現狀，整理、探討

26、不同方案中關鍵的擁塞檢測機制，歸納其技術路線與演進，從而推動高性能網絡技術的深入發展，助力完整的生態鏈建設和產業落地。13數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004二、二、擁塞管理與控制技術體系擁塞管理與控制技術體系為了緩解高性能網絡中的擁塞問題，RoCE 高性能網絡協議已經構建了多層的擁塞管理和控制技術體系。這一體系中，細分主要包含擁塞控制、負載均衡、鏈路控制、流量調度等。形成了從用戶層到鏈路層的多層次擁塞管理和控制體系。其中，擁塞控制協議、鏈路控制的響應快、周期短，通過調整流的發送速率實現擁塞的避免，且主流方案通過閉環控制技術實現，因此歸類為擁塞控制

27、技術；負載均衡、流量調度，往往通過管理的方式，對數據進行調度分流，通過更高效的利用網絡拓撲資源實現擁塞的避免，因此歸類為擁塞管理技術。本章中重點對現有擁塞管理與控制技術進行了歸納整理。以便系統的給出后續第 4 部分擁塞檢測技術的技術發展方向。（一）（一）擁塞控制技術擁塞控制技術擁塞控制，顧名思義，可知其在網絡擁塞問題處理中的核心位置。擁塞控制是為了防止網絡過載而采取的一種流量調節機制。當網絡擁塞時，路由器隊列堆積,丟包和延遲增加。擁塞控制算法(如TCP 的滑動窗口)可以通過監控網絡狀況來動態調整發送方的發送速率。比如，在擁塞開始時降低發送速率，擁塞消除后逐漸增加發送速率。這種閉環反饋機制可以使

28、網絡穩定運行在最優狀態，最大化網絡的吞吐量，是保證網絡順暢運行的重要機制。14數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-030041 1基于基于 E ECNCN 的擁塞控制的擁塞控制圖 8 DCQCN 原理為了緩解網絡擁塞，文獻12中微軟提出了一種端到端的 RoCE 擁塞控制協議 DCQCN，這也是近幾年來 RoCE 高性能網絡擁塞控制技術的開端。DCQCN 相比于 PFC 是一種更精細的控制算法。它以 ECN（Explicit Congestion Notification，ECN）作為交換機擁塞程度的量化標記信息，根據生成的 CNP（Congestion No

29、tificationPacket）報文來觸發式的調節網卡傳輸速率。DCQCN 的設計理念結合了既有的 QCN13和 DCTCP14的算法思想。一方面避免了 QCN 方法局限于 L2 網絡的缺點，另一方面降低了 DCTCP 中 ACK 報文的通信開銷。DCQCN 的使用大幅度緩解了 PFC 的觸發，目前仍是最廣泛應用的RDMA 網絡擁塞控制技術。2 2基于時延的擁塞控制基于時延的擁塞控制圖 9 TIMELY 原理1515數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004同期，谷歌在文獻15中提出了一種基于時延的擁塞控制方案TIMELY。TIMELY 使用數據流的往

30、返傳遞時間（Round Trip Time，RTT）作為量化鏈路擁塞的信息，并設計了一套相應的梯度調速算法。相較于傳統的軟件測量的 RTT，谷歌方案在他們的智能網卡中集成了專有的 RTT 硬件測量電路，這使得 RTT 測量擁塞的方案得以實用化。同時 RTT 相比于 ECN 是一個快速、多位的數據，能夠提供更豐富的網絡擁塞信息。3 3基于基于 I INTNT 的擁塞控制的擁塞控制圖 10 HPCC 原理16微軟的 DCQCN 和谷歌的 TIMELY 在 RDMA 網絡擁塞控制方面雖然各有所長，但仍存在各自難以突破的局限性。2019 年，阿里云提出了一種基于帶內遙測（In-Net Telemetr

31、y，INT）的擁塞控制協議HPCC16。相比于 DCQCN 和 TIMELY，HPCC 方法犧牲了一定的帶寬引入了 INT 能力，同時也獲得了超高精度的擁塞控制性能。HPCC 可以實現快速的算法收斂以更優的利用閑置帶寬，同時保持交換機始終處于近零隊列，從而實現超低的數據傳輸延遲。16數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-030044 4其他技術方案其他技術方案盡管 HPCC 在處理擁塞方面的性能得到了普遍的認可，但它過高的網絡帶寬占用仍然為后續的技術改進留下了空間。此后，更多的技術方案進入了學術界的討論。其中，一類是基于已有方案的變種。(1)ECN 方案變種：

32、文獻17中提出了 ACC 來自動調節 DCQCN 中ECN 參數，大幅度降低了運維大規模 RDMA 集群過程中調試算法參數的工作難度；文獻18旨在改進 DCQCN 在 Incast 場景的性能表現，通過自適應的選取 DCQCN 的參數，實現大規模多打一場景小步長，小規模多打一場景大步長的控制效果；文獻19中提出了 IRN，通過改變 RoCE 的重傳機制和基于 BDP 的算法，從原理上改進 DCQCN 和TIMELY 方案下擁塞場景的 RDMA 網絡性能；文獻20改進了交換機的 ECN 標記機制，將傳統的兩態標記優化為三態標記 TCD，提升了ECN 標記攜帶的信息量，從而改進了 DCQCN 的控

33、制效果。(2)RTT 方案變種：文獻21中建立了 DCQCN 和 TIMELY 的流體模型，分別就二者的擁塞控制效果進行了對比研究?；诙咝阅苌系牟顒e，其提出了使用 PI 控制器的改進 TIMELY 算法，一定程度上提升了基于 RTT 方法的控制性能；文獻22為解決 TIMELY 的收斂點不固定這一問題，重新設計了 TIMELY 的調速算法，使用了 AIMD（Additive-Increase Multiplicative-Decrease，AIMD）調速算法，17數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004從而實現了更好的算法穩定性；文獻23通過將 E

34、CN 信號與 RTT 信號結合考慮，提出了 EAR 擁塞控制協議，在多個場景實現了更好的完成時間性能。(3)INT 方案變種：文獻24為了解決 HPCC 中 INT 包頭帶來的明顯的網絡帶寬占用問題，提出了概率性帶內遙測（ProbabilisticIn-band Network Telemetry，PINT）方案。PINT 使用了概率性編碼的方式，大幅度的降低了 HPCC 中網絡帶寬占用的問題。文中的結果顯示，在包頭從 46 B 降低到 1 B 的基礎上，HPCC-PINT 實現了與HPCC-INT 接近的流完成時間分布，HPCC-PINT 在長流上略優但在短流上略差。該方案難以大規模部署的局

35、限在于 P4 可編程交換機的資源瓶頸。圖 11 RoCC 原理25另一類興起的是基于接收方的方案。思科首先提出了 RoCC25。在該方案中，將傳統的由發送方驅動的端到端擁塞控制協議，改進為接收方驅動。在文獻25中認為，多個不同發送方做出的調速決策時常是矛盾的，這導致了最終控制效果的反復波動。而由接收方驅動的擁塞控制協議中，交換機作為擁塞的感知方，可以進行更準確的擁塞反饋。但 RoCC 本身受限于交換機的計算能力和可編程能力，18數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004并未實現大規模商用。其后，文獻26,27實現了網卡作為接收方的擁塞控制協議，在 Inc

36、ast、公平性的場景有明顯優勢?？傮w上看，擁塞問題是 RDMA 網絡目前應用的核心難題，而擁塞控制協議作為處理擁塞問題的最短回路在學術研究和工業應用角度都極具研究價值。目前，擁塞控制協議主流應用的方案仍然是DCQCN、TIMELY 和 HPCC，但顯然這三種方案都存在不同的缺陷。后續提出的方案有些偏向解決某一特定流量場景的問題，有些需要更新的硬件支持，難以大規模商用并完全解決 RDMA 無損網絡擁塞控制的問題。5 5擁塞控制總結擁塞控制總結表 1 擁塞控制協議功能實現對比DCQCNTIMELYHPCCRoCC公平性公平公平公平公平快速收斂慢快快快帶寬利用率低高較高高穩定性穩定局部收斂穩定穩定魯

37、棒性中差中魯棒近零隊列不滿足不滿足滿足滿足兼容性強強差差易用性差差易用易用根據上一節中總結的當前擁塞控制協議的核心功能點，本文就當前具有代表性的四種擁塞控制協議：DCQCN、TIMELY、HPCC、RoCC，進行了定性的對比，如表 1 所示。19數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004DCQCN 協議強項在于兼容性，這也直接決定了 DCQCN 成為了現在最為主流的應用方案。具體來講，DCQCN 協議對于交換機要求較低，只需滿足 ECN 標記功能，當前商用 RoCE 交換機已普遍支持。但是，DCQCN 在收斂速度、帶寬利用率方面與穩定性存在一個博弈，即往

38、往需要犧牲穩定性來實現更高的帶寬利用率，二者不可兼得。其次，DCQCN 在易用性方面有明顯缺陷，端側和網側有十余個參數需要調試且參數相互耦合，維護成本很高。同時，DCQCN 使用了AIMD（Additive Increase Multiplicative Decrease,AIMD）調速機制是不基于模型的調速算法。對于不同場景下的擾動，有較強的魯棒性。但由于輸入信息位數受限，進一步增大了維護成本。TIMELY 協議的優勢主要是檢測精確，RTT 測量的擁塞信息本身就是多位的，這解決了 DCQCN 算法中最大的一個局限點。因此，TIMELY 在收斂速度和帶寬利用率上更高。但是，TIMELY 在公平

39、性和穩定性方面也是存在一組矛盾21：收斂到特定穩定點則不能保證公平，保證公平則不能保證達到目標收斂點。其次，TIMELY 的易用性偏差，主要難點在于目標時延的選擇困難。同時，TIMELY 采用的是基于模型的控制算法，這保證了精確計算的同時，帶來了對于擾動抑制能力差的問題。HPCC 協議在公平性、收斂速度、穩定性方面都達到了相比于DCQCN 和 TIMELY 更好的整體效果。同時，HPCC 實現了近零隊列控制功能，這有效的保證了網絡的平均流完成時間(Flow complete time,20數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004FCT)性能，降低了排隊

40、時延。HPCC 主要問題在于，INT 消耗了 10%左右的網絡帶寬，雖然在 PINT 中有所緩解，但資源的開銷被轉移到了交換機，這方面的開銷導致 HPCC 仍有改進空間。此外，HPCC 對交換機設備的要求較高，需要可編程交換機的支撐，這限制了它的推廣使用。最后，HPCC 的算法是以 BDP 精確計算為基礎的，這本質上還是基于模型的控制方法。對于更復雜的場景，模型和參數的魯棒性存在潛在的問題，有待進一步研究驗證。RoCC 協議是針對其他方案的缺陷設計的，其實現上解決了絕大多數問題，性能指標趨于理想。相比于 HPCC，RoCC 在其基礎上采用了 PI 控制器，該控制方法是不依賴于模型的，在實際應用

41、中相比HPCC 具有更好的魯棒性。但是，RoCC 與 HPCC 存在一個類似的缺點，需要可編程交換機作為運算的主要載體，這對于交換機的性能提出了更高的要求。目前，可編程交換機技術已經開始快速發展，但其芯片架構決定了不適合執行高精度的運算任務。隨著未來芯片技術和可編程交換機技術的發展，RoCC 可能是更優的擁塞控制協議。綜上所述，目前的擁塞控制協議很難在兼容、易用的基礎上，還具備完善的功能、性能。21數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004（二）（二）鏈路控制技術鏈路控制技術鏈路控制技術主要通過速率限制和流量控制來實現，可以動態調整 RDMA 網絡中的數

42、據發送速率,避免擁塞的產生,從而提高網絡效率。鏈路控制對于構建可靠、低延遲的 RDMA 網絡至關重要。相比于 L4 傳輸層的擁塞控制協議，鏈路控制協議工作在 L2 鏈路層。相應的，鏈路控制技術響應的時間相比擁塞控制更加短，速率的調節也更加及時。對應的擁塞檢測機制也明顯有別于 L4 層面，要求響應的速度更快。鏈路層控制中，往往并不獲取網絡內的擁塞程度信息，而是用事件觸發產生的報文進行進行控制。因此，鏈路控制中的擁塞檢測與控制結合的更緊密，往往就是一組報文的交互過程，而非細化到速率的計算與調整。本節受限于篇幅，主要介紹 Infiniband 中常用的信用機制和RoCE 網絡中常用的 PFC 和 Q

43、CN 機制。1 1信用信用圖 12 信用機制原理圖22數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004在 InfiniBand 高性能網絡協議中，提供了一種基于信用的鏈路控制（Credit-Based Flow Control）機制，用于優化數據傳輸。在InfiniBand 中，每個端口都有一個緩沖區，用于存儲接收到的數據包。當發送端發送數據包時，它會向接收端發送一定數量的信用（Credit），表示接收端有多少可用的緩沖區來存儲數據包。在接收端，當緩沖區被占滿時，它會向發送端發送信號，表示不能再接收更多的數據包，從而避免了網絡擁塞的發生?；谛庞玫逆溌房刂瓶梢?/p>

44、顯著提高網絡的吞吐量和性能。它可以避免數據包的丟失和重傳，并減少網絡擁塞和延遲。此外，由于每個端口都有自己的緩沖區，它也可以實現流量隔離和保障，從而提高網絡的可靠性和安全性。通常，信用機制這種傳輸控制與 TCP 中的滑動窗口有相似之處，兩者都是收發兩端協調控制發送數據量的鏈路層流量控制機制。相比滑動窗口使用 ACK 報文確認的方式，信用機制為了更高的性能，設計了特殊信用幀來反饋未使用的信用量。信用機制目前是 Infiniband 定制的鏈路控制技術。這一技術目前未在開放標準的以太網中廣泛應用，這也導致了 RoCE 網絡中普遍需要使用 PFC 來保障網絡的無損特性，同時也導致了 RoCE 網絡沒

45、能繼承 Infiniband 中細粒度擁塞控制的底層基礎。23數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-030042 2P PFCFC圖 13 PFC 控制原理圖優先級流控制（Priority-based Flow Control，PFC）28是IEEE 802.1Qbb 定義的一項用于數據中心的無丟包網絡流量控制協議，主要用于確保網絡的無損特性。無損網絡意味著網絡不會因為擁塞而導致數據包丟失。上圖展示了在交換機層級之間實現 PFC 的示例。PFC 通過 Pause 幀觸發反壓的方式實現無丟包。當交換機隊列接近滿時（達到 ON/OFF 閾值），交換機將向上游交換機

46、發送一個Pause 幀，告知上游不要繼續發送數據包。待擁塞緩解后，再通知上游繼續發送數據包。同時，PFC 通過虛擬隊列將數據包分成不同的優先級。即使某個優先級受到擁塞阻塞，仍然可以通過更高優先級發送數據包，以確保重要分組的及時傳遞。24數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004PFC 解決了無丟包的問題，但會帶來一系列問題：a)導致出現受害者流，無法正常傳輸數據，如上圖中(b)所示，Egress 2 和 3 的數據包盡管未發生擁塞，也會被停止發送，即 HoL（Head of Line）阻塞。b)PFC 風暴，Pause 幀會反向逐級傳遞，形成網絡內大量的

47、設備停止發送.c)PFC 死鎖，當系統中出現 Pause 幀的 CBD（Circular BufferDependency）現象時，PFC 發生死鎖導致網絡傳輸長時間中止，如下圖。圖 14 PFC 死鎖11總而言之，PFC 技術是 RoCE 高性能網絡發展的重要過渡技術。它保障了 RoCE 網絡可以進入生產部署階段，但它的一系列技術上的缺陷又局限了 RoCE 網絡的大規模部署。25數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004近年來，就如何擺脫 PFC 限制，學術界和工業界有大量的研究，包括 PFC 自恢復機制、更高效的擁塞控制協議、選擇重傳19等一系列的解

48、決方案。相關技術的后續研究進程將決定 RoCE 高性能網絡與傳統 Infiniband 高性能網絡在技術上的實質差距。3 3QCNQCN圖 15 QCN 技術原理QCN13是一種 L2 鏈路層的網絡擁塞控制技術，旨在提高網絡的性能和可靠性，避免網絡擁塞引起的數據丟失、延遲和抖動等問題。QCN 通過在交換機中實時監測網絡擁塞情況向終端設備發送擁塞通知，從而調整數據傳輸速率，以適應網絡的擁塞狀況。具體流程上，一旦中間交換機或者路由器發生擁塞，擁塞點會：從交換機讀出隊列長度；26數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004基于隊列長度信息計算反饋的值；格式化一個

49、特殊反饋值的 QCN 幀，使用 源 MAC 地址將該幀返回 QCN 源端；根據 QCN 算法指定的動態信息更新隊列的采樣速率，通過擁塞通告可以一定程度上解決擁塞熱點的問題。然而在真實環境中很少實現，因為它會高度依賴擁塞點反應時間，通過網絡發送 QCN 幀的時間和反應點反應時間；并且它只能運行在二層網絡上，很難適應數據中心大量的三層隧道功能。同時，如能解決設備支持的因素，將 QCN 與 DCQCN 結合實現一個類似于 IB 的鏈路層+傳輸層擁塞控制方案，將是對 RoCE 網絡缺少credit 鏈路控制技術的一個有力補充，這都有待于進一步的研究和工程實踐。4 4鏈路控制總結鏈路控制總結在鏈路控制層

50、面，由于現有的 RoCE 協議中缺少了 Infiniband協議中的信用機制，這一定程度上破壞了原有的雙環控制系統的完整性。用 PFC 替代細粒度的信用機制，在整個控制系統的角度看，可以認為是將一個內環控制系統置換成了一個非線性死區，這一定程度上降低了整個系統的階數。從實際的網絡角度意味著傳輸速率的調節，RoCE 網絡相比Infiniband 會更加的遲鈍。這個技術上的差距是不能通過調節DCQCN 參數彌補的。因此，RDMA 網絡在以太網上的應用更為重要的27數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004技術突破要在鏈路控制的層面進行。但同時，鏈路層的改動需

51、要對協議內容進行更深入的探討和精巧的設計，同時需要在硬件層面進行大量的研發工作，其研發周期往往更長。（三）（三）負載均衡技術負載均衡技術負載均衡技術通過在網絡中多個服務器或鏈路間分配流量，實現網絡流量的均衡分配，防止熱點的產生。負載均衡機制的核心目標在于利用好網絡中冗余的傳輸路徑，使得流量均勻分布。負載均衡技術對于網絡擁塞起到了有效的緩解作用，從擁塞的源頭上，降低了擁塞發生的概率。本節按業內通用的分類，按流級別、包級別、flowlet 級別對常見的典型負載均衡機制進行了分類總結。1 1流級別流級別ECMP 全稱等價多路徑（Equal-cost multi-path），它是一種基于流的負載均衡路

52、由策略。當路由器發現同一目的地址存在多條等價路徑時，路由器會依據相應算法將不同流量分布到不同的鏈路上，以增進網絡帶寬利用率。ECMP 的路徑選擇策略有多種算法：哈希，例如利用流的五元組哈希為流選擇路徑；輪詢，各個流在多條路徑之間輪詢選擇；28數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004基于路徑權重，根據權重系數，系數大的分配流量多。ECMP 是一種簡單的負載均衡策略，但在實際應用中存在許多問題。a)可能加重網絡鏈路的擁塞問題。由于 ECMP 僅使用哈?；蜉喸兎椒ㄟM行負載均衡，它無法感知到鏈路的擁塞情況。因此，在已經存在擁塞的鏈路上使用 ECMP 可能會進一

53、步加劇擁塞情況。b)ECMP 無法解決非對稱網絡的性能損失。當數據中心網絡發生故障時，網絡結構可能會出現非對稱情況導致無法實現網絡物理鏈路的均衡分布，進而造成流量不平衡的問題。c)在流量大小分布均勻的情況下，ECMP 效果較好。然而，在同時存在大流量和小流量的情況下，ECMP 的效果并不理想。假設有一條大流量和一條小流量同時到達路由器，ECMP 會將這兩條流量均勻分配到等價路徑上，但顯然這種情況下等價路徑并沒有被高效利用。因此，盡管 ECMP 是一種簡單的負載均衡策略，但它存在上述問題，限制了其在某些場景下的有效性。在解決這些問題的同時，可以考慮使用更復雜的負載均衡策略或結合其他技術來改善網絡

54、性能和流量分配的均衡性。因此，將 ECMP 直接部署在數據中心這種突發流量多，大象流與老鼠流并存的環境中，需要仔細考慮環境的問題。盡管后續的研究（如 Hedera29，BurstBalancer30）很多考慮了不同的數據流29數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004量特征（大象流、burst 等）。但是，ECMP 由于其工程復雜度低、性能可接受仍然廣泛應用在數據中心網絡中。2 2包級別包級別隨機包噴灑（Random Packet Spraying，RPS）是一種基于包級別的負載均衡策略。當路由器發現有多條等價路徑指向同一目的地址時，RPS 會將數據包以

55、單個包為單位分散到這些路徑上。與 ECMP不同，RPS 以數據包為單位進行操作，而 ECMP 則是以流為單位進行操作。RPS 將同一流中的不同數據包轉發到不同的等價路徑上。RPS 的優點在于簡單易實施，并且能夠充分利用網絡鏈路。在沒有突發流或流大小差異的情況下，RPS 能夠避免網絡出現不均衡的情況，能夠實現更好的負載均衡并提高網絡性能。同時，RPS 也有一些限制。由于數據包的隨機分布，可能會導致同一流中的數據包到達目的地的順序不同，這可能對某些應用程序造成影響。此外，RPS 對網絡中的路由器和交換機的支持程度也可能存在差異。RPS 技術往往需要 RDMA 網卡在傳輸層支持亂序傳輸，這對于當前市

56、場上已有的 RNIC，是一個相對苛刻的硬件要求，這也導致了當前 RPS 方式負載均衡的使用范圍。3 3F Flowletlowlet 級別級別流級別的太過粗糙，包級別的粒度太細。Flowlet 作為一個折中方案，就成為了一個研究點。M.Alizadeh 等人于 2015 年提出CONGA31，它是一種基于網絡的分布式擁塞感知負載平衡系統。其設30數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004計目標是在不增加傳輸層復雜度的前提下，通過分布式方式實現全局負載平衡。CONGA 基于數據中心網絡的特點將流進一 步細分為間隔粒度在微秒級別的小流(Flowlets)，負

57、載均衡也針對每一個 Flowlet 的第一個包，之后每個 Flowlet 使用相同的鏈路。上行鏈路交換機搜集鏈路擁塞狀況并交給收端交換機，保存一個來自各葉節點的擁塞狀況，并反饋給源端交換機。CONGA 通過負載均衡提升了數據中心網絡傳輸性能進而提高吞吐量，但 CONGA 仍然需要網絡負載與實際容量相匹配。當實際容量無法滿足時，CONGA 的性能無法得到保證。此外，這一領域的研究內容也逐漸細化，但整體上講，應用范圍相比 ECMP 更加局限。4 4負載均衡總結負載均衡總結負載均衡作為網絡領域的一個傳統問題，旨在合理分配網絡資源以實現流量的均衡和優化性能。無論是在傳統的 TCP 網絡還是在RDMA

58、網絡中，負載均衡都是一個重要的考慮因素。在傳統的 TCP 網絡中，負載均衡通常通過在網絡層或應用層進行實現。常見的負載均衡方法包括基于輪詢、哈希算法、最短隊列優先等。這些方法旨在將傳入的請求或數據流量分發到多個服務器或網絡路徑上，以實現負載均衡和避免單一節點或路徑的過載。31數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004在 RDMA 網絡中，負載均衡的目標和原則與傳統 TCP 網絡并無區別。然而，由于 RDMA 網絡具有獨特的特性和協議，需要特別考慮一些因素。RDMA 網絡的部署和配置可能涉及特定的硬件和軟件要求。負載均衡解決方案需要考慮 RDMA 適配器、

59、交換機和路由器的支持程度，以及與 RDMA 協議棧的集成。對于無損的 RDMA 網絡和有損的RDMA 網絡，其負載均衡機制上仍應有不同。結合未來更多的高性能網絡應用場景，負載均衡機制上仍有優化的空間，與擁塞的實時檢測信息結合可能是未來的潛在研究方向。（四）（四）流量調度技術流量調度技術流量調度技術不同于前述的幾項技術，它更多的是在給特定的數據流量進行優先級調配，解決全局的網絡服務質量問題。數據中心中的流量調度技術主要通過軟件定義網絡(SDN)來實現。SDN 控制器整合拓撲發現模塊和流量監控模塊獲取全網視圖，再根據業務優先級、網絡狀態、服務器負載狀態等，用開放流協議(OpenFlow)下發流表規

60、則到數據平面，協調網絡設備實現動態的流量調度。這可以按需分配網絡資源，繞過擁塞鏈路，根據業務需求分割帶寬，還可以按照負載將流量導向閑置服務器。流量調度提高了網絡利用率，保證了關鍵業務的質量。32數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004目前來看，流量調度技術分為兩類，一類是開環的管理與分配，這種往往由設置特定的規則來進行調度。本節以調度的特點來分類，對流量調度的典型技術進行了歸納。1 1基于規則的調度技術基于規則的調度技術基于規則的流量調度技術在學術界討論的非常廣泛，例如，pFabric32，PDQ33，PIAS34，FastPass35，Homa36，

61、AuTo37等。它們的研究方法通常是設定特優的規則來給不同的數據流進行優先級分類。例如，對較長的流，減少包丟棄；對時延敏感的流進行優先級排序，平衡網絡負載，使其快速通過。圖 16 PIAS 調度原理38由于流量調度的研究較多且領域更加細化，與應用結合較多，但總體的研究思路是類似的。限于篇幅，此處以 PIAS 舉例說明。PIAS 是一個流調度算法，目的是達成短流高優先級，長流低優先級。PIAS 假定流分布是不可知的，從而尋求將 FCT 最小化。33數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004PIAS 借鑒了模擬最短作業（SJF）工作原理來最小化 FCT。利用

62、現有交換機中可用的多個優先級隊列來實現多級反饋隊列（MLFQ）。在這種隊列中，PIAS 流會根據其發送字節數逐漸從高優先級隊列降級為低優先級隊列。因此，短流能在前幾個高優先級隊列中完成，這使得 PIAS 能夠在無法預先知道流量大小情況下模擬 SJF。如圖 15 所示，PIAS 只部署在端節點，而不用在交換機上部署。問題的難點在于如何準確劃分包長閾值 K，以及端與端之間的配合。閾值不準確和優先級之間失匹配，都會導致性能損失。文中，作者雖然通過建模給出了如何準確計算閾值和解決失匹配問題，但是仍然需要很長的時間使模型收斂。同時，它的優先級匹配的過程，存在慢啟動的問題。即長流可能需要很長時間才能達到一

63、個準確的優先級，導致性能損失。PIAS 論文的研究工作中，我們可以看出基于規則的流量調度技術更多的是需要針對特定的網絡流量環境，通過精細的平衡各方面的 tradeoff，實現某種邊界條件下的網絡性能最優化。這類工作在科研學術的角度，有研究價值，也可以提升封閉環境下的網絡性能。但是在更廣泛應用的云數據中心中，失去了流量特征的種種理想假設，這種敏感的規則平衡幾乎不可能達成。這也一定程度上限制了流量調度技術的落地和廣泛應用。34數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-030042 2基于反饋的實時調度基于反饋的實時調度流量調度本質上與交通、物流等領域的調度問題沒有區別

64、，而實時調度在這些領域中有廣泛的應用。而網絡流量的調度技術中，結合反饋信息的實時調度研究相對較少。其根本原因在于，網絡環境相比傳統的交通、物流，信息更難測量獲取。一些研究確實也引入了一些實時調度的思路，例如 D2TCP39、D340等基于完成時間的流調度技術。這類技術在整體上將原有的從流量的特征制定規則的角度轉到實時的完成的截止時間上。但是，不管是 D3 還是 D2TCP，使用的時間都是截止時間和已發送時間。這種本質上雖然也形成了回路，但系統的傳感器是本地時鐘，這種實時的反饋調度仍然是規則化的。如何利用更多的網內信息，實時的調整調度規則，是未來研究的一個潛在方向。3 3流量調度總結流量調度總結

65、流量調度相比于擁塞控制、鏈路控制、負載均衡，更接近用戶層，與業務耦合更緊密，能有效的優化特定業務場景下的業務服務質量。但是，由于其軟件調度的局限性，它很難完成快速的擁塞避免，這一特點也決定了它需要的檢測手段要具有周期長且準確特點。同時，基于簡單規則的調度技術難以在復雜的流量環境下廣泛的應用，流量調度技術更明顯的在向實時調度的方向演進。隨著擁塞檢測技術的進步，更豐富的網絡實時信息將給流量調度技術帶來35數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004更大的操作空間，也給流量調度技術在未來云數據中心的更廣泛應用提供了更多的契機。（五）（五）本章小結本章小結本章歸納

66、了高性能網絡中，用于處理和緩解擁塞的技術體系，主要包括擁塞控制和鏈路控制組成的擁塞控制技術，負載均衡和流量調度組成的擁塞管理技術。擁塞管理和控制的技術體系，目前仍然是高性能網絡的核心，將更為合適擁塞檢測技術更為廣泛的集成到特定的管控層面，是未來高性能網絡的一個重要課題。同時，在本章中，討論了各項技術與擁塞檢測技術已有以及潛在的結合點?？傮w上看，擁塞檢測在硬件實現更多、響應速度更快的擁塞控制協議、鏈路控制協議中應用更加廣泛。但隨著網絡觀測技術的進步，在負載均衡、流量調度技術方向上，也有較大的潛在應用。36數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004三、三、高

67、性能網絡擁塞檢測技術高性能網絡擁塞檢測技術擁塞檢測技術本身的出現早于高性能網絡，ECN、RTT、INT 等擁塞測量的方案在傳統的 TCP 網絡中就已經被廣泛探討14,41,42，以優化 TCP 網絡的傳輸效率。但在高性能網絡，特別是 RoCE 協議下，擁塞問題的重要性進一步上升，也對擁塞檢測技術提出了更高要求。在高性能網絡的擁塞管理與控制技術體系中，存在一個直觀規律。以擁塞控制協議為例，不同的擁塞控制協議往往對應不同擁塞檢測技術，如 DCQCN 對應 ECN、TIMELY 對應 RTT、HPCC 對應 INT 等。由此可見，擁塞檢測在擁塞控制方案中是決定性的。各種不同協議中控制器的算法之所以存

68、在區別，歸根結底是擁塞檢測的實現方案區別。例如，DCQCN 中使用 CNP 報文的事件驅動型控制，其算法設計上采用 AIMD 來進行逐拍的控制；TIMELY 使用 RTT 作為擁塞信息，其算法則可以使用 PID 進行線性控制。擁塞檢測方案是整個協議的起點，也是不同的擁塞控制方案的本質區別。同時，在之前的研究工作中，擁塞控制的設計缺乏系統性的思考，檢測環節、處理環節、控制環節通常沒有細分的設計。這也導致了控制算法設計上很多與檢測環節強耦合，工程實現上缺乏通用性，且參數繁多。因此，本章對當前的擁塞檢測技術進行系統的歸納，主要以擁塞檢測的主體為分類依據，以交換機、網卡、端網協同三個類別，分別對高性能

69、網絡的擁塞檢測技術的演進思路開展探討。37數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004（一）（一）網側擁塞檢測網側擁塞檢測在高性能網絡中，交換機是擁塞發生最為頻繁的設備節點。因此，交換機設備的擁塞檢測結果，往往代表了整條傳輸鏈路中最大擁塞程度。本節中，以幾個典型的 RDMA 網絡交換機擁塞檢測技術為切入點進行了歸納總結。1 1E ECNCN 檢測檢測顯式擁塞通知43,44（Explicit Congestion Notification，ECN）是對 Internet 協議和傳輸控制協議（TCP）的擴展，定義在RFC 3168（2001）中。ECN 允許在

70、不丟棄數據包的情況下，通知網絡擁塞的發生。ECN 在以太網中是一個可選的功能，在底層網絡基礎設施也支持的情況下，可以在兩個支持 ECN 的終端之間使用。ECN 在 Internet 層和傳輸層都需要特定的支持，在 TCP/IP 中，路由器在 Internet 層運作，而傳輸速率由傳輸層的端點處理。擁塞可能僅由發送器處理，但由于只有在發送了一個數據包之后才知道發生了擁塞，因此接收器必須將擁塞指示回傳給發送器。在沒有ECN 的情況下，擁塞指示回傳是通過檢測丟失的數據包間接實現的。而有了 ECN，擁塞通過將 IP 數據包中的 ECN 字段設置為 CE（Congestion Experienced）來

71、指示，并通過接收器在傳輸協議的頭部設置適當的位來回傳給發送器。ECN 廣泛的應用于以太網絡，因此在 RoCE 高性能網絡協議中，ECN 作為擁塞檢測方案存在廣泛硬件基礎。事實上，應用廣泛的38數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004DCQCN 和 DCTCP 協議都使用了 ECN 作為其擁塞檢測方案，其參數設置上并不完全相同，如下圖所示。圖 17 ECN 標記參數含義ECN 在使用的過程中存在不同的標記算法區別，以下給出了典型的 RED 和 Blue 標記算法。1)RED 標記ECN 在使用的過程中，通常與 RED 功能結合使用。RED 是由Sally

72、 Floyd 和 Van Jacobson 在 1990 年代初發明的交換機隊列管理機制45。RED 會監控平均隊列大小，并根據統計概率丟棄（或在與 ECN 結合使用時標記）數據包。39數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004圖 18 RED 標記原理隨機早期檢測（Random Early Detection，RED）是一種適用于擁塞避免的網絡調度器隊列規則。在傳統的尾部丟棄算法中，路由器或其他網絡組件緩存盡可能多的數據包，并簡單地丟棄無法緩存的數據包。如果緩沖區不斷滿載，表示網絡擁塞。尾部丟棄不公平地分配緩沖區空間給各個流量流。尾部丟棄還可能導致 T

73、CP 全局同步，因所有 TCP 連接會同時退縮并同時前進。網絡會交替地被低效利用和淹沒，形成波動現象。RED 通過在緩沖區完全滿載之前預先丟棄數據包來解決這些問題。它使用預測模型來決定要丟棄的數據包。如果緩沖區幾乎為空，則接受所有傳入的數據包。隨著隊列的增長，丟棄傳入數據包的概率也會增加。當緩沖區已滿時，概率達到 1，所有傳入的數據包都會被丟棄。40數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004RED 后續結合 QoS 等信息，進一步衍生出了 WRED（WeightedRED）和 RIO(RED with In and Out)。2)Blue 標記RED 是

74、一種依賴隊列長度的標記算法。根據排隊論中的著名結果，只有當數據包的到達時間服從泊松分布時，隊列長度才直接與活動源的數量和真正的擁塞水平相關。不幸的是，在網絡鏈路上，數據包到達時間往往不服從泊松分布。Blue46是一種網絡調度器的調度策略，由密歇根大學的研究生馮武昌（Wu-chang Feng）為 Kang G.Shin 教授以及 IBM Thomas J.Watson 研究中心的其他人在 1999 年開發而成。Blue 使用了數據包丟失和鏈路利用率歷史來管理擁塞。通過維護一個單一的概率，用于在數據包排隊時標記（或丟棄）數據包。如果由于緩沖區溢出而導致隊列持續丟包，Blue 會增加標記概率，從而

75、增加發送擁塞通知的速率。相反地，如果隊列變為空或鏈路處于空閑狀態，BLUE 會減小其標記概率。BLUE 相對于 RED 在減少數據包丟失方面有一定的優越性，即使在使用較小的緩沖區時也是如此?；?Blue 的機制，還提出并評估了一種新的機制，用于有效地和可擴展地實現大量流之間的公平性。當前的交換機中普遍使用 RED 與 ECN 結合，通過 RED 標記機制生成 ECN 標記。但隨之 Lossy 逐漸在主流 RoCE 網卡中普及，對于未41數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004來的高性能網絡，Blue 以及近年來的一些其他主動隊列管理的方法可能存在更多

76、的應用場景。2 2T TCDCD 檢測檢測圖 19 TCD 的狀態轉移原理圖20在文獻20中，意識到了擁塞檢測對于整個系統的重要作用。該論文的觀點中，ECN 檢測給出的結果是具有 ON-OFF 特性的，而這種 ON-OFF 發送模式可能對交換機中的擁塞檢測行為產生意外影響，包括引起隊列積壓并影響暫停端口的實際輸入速率。以此為啟發，該論文中提出了一種三元擁塞檢測技術來實現RDMA 網絡的擁塞檢測。它將網絡設備的端口狀態不再用 0-1 標記，而是區分成三種狀態，擁塞、非擁塞和不確定。這三個狀態用上圖所示的方式進行轉移。盡管 TCD 意識到了擁塞檢測對于高性能網絡擁塞的關鍵作用，但其工作仍然是受限于

77、狀態的轉移。本質上講，TCD 是通過擴展 ECN42數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004標記的數據位寬實現更準確的擁塞檢測。相比于其三元狀態的轉移邏輯的設計，該研究工作中體現出的高位寬帶來搞檢測精度最終帶來擁塞控制系統性能的提升結果更加令人振奮。3 3其他檢測技術其他檢測技術（a）BCN 系統模型（b）FECN 系統模型圖 20 BCN、FECN 擁塞檢測相比于 TCD 和 ECN 在 RDMA 網絡中的應用，一些在以太網中也定義的其他的擁塞通知協議如 Backward Congestion Notification（BCN）47，Forward

78、Explicit Congestion Notification48，Pre-Congestion Notification49等，在 21 世紀初的 IEEE 802.1Qau 工作組中都有廣泛的討論。這些擁塞檢測技術同樣有應用到 RoCE 網絡中的潛在可能。（二）（二）端側擁塞檢測端側擁塞檢測交換機和斷網協同完成擁塞檢測，往往意味著需要特定的交換機支持。由于大規模的云廠商對于設備的供應鏈、兼容性、規范性都有苛刻的要求，專屬定制的交換機對于大多數云服務提供商來說是難以接受的。因此，不依賴交換機，在端側通過云廠商自研的43數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-

79、03004DPU、網卡就能獨立完成擁塞檢測的方案，對于云數據中心也具有很大的潛在應用價值。1 1RTTRTT 檢測檢測圖 21 RTT 測量原理RTT（Round Trip TIme）是數據包傳輸的往返時間，在應用于RDMA 高性能網絡之前，就被廣泛的應用于 TCP 網絡協議的傳輸控制中，如 BBR、Reno、Vegas 等，其表達式如下：使用 RTT 進行擁塞檢測遵循一個樸素的哲學，即發生擁塞的鏈路中數據包的傳輸時延增大。當網卡實測的 RTT 與端到端正常的RTT 發生變動時，RTT 的變化量即代表了數據包排隊引起端到端延遲。在 ECN 方案中，具有不同優先級的多個隊列共享同一個輸出鏈路，但

80、 ECN 標記僅提供了超過閾值的隊列的信息。低優先級的流量可能會經歷較大的排隊延遲，而不一定會積累大量的隊列。此外，ECN 標記描述了單個交換機上的行為。在高度利用的網絡中，擁塞發生在多個交換機上，而 ECN 信號無法區分它們之間的差異。44數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004相比于 ECN，RTT 積累了關于端到端路徑的信息，包括可能出現擁塞的網絡接口卡（NIC）。RTT 提供的信息是一個更為精煉、聚合了端到端擁塞的最終量化指標，從這個角度講，RTT 是更為直接的測量指標。但是，文獻21也對 RTT 和 ECN 方法進行了客觀的對比，RTT測量還

81、是會存在對時鐘抖動敏感等問題。同時，使用 RTT 測量的TIMELY 的算法也存在設計上的問題，導致同期提出的 RTT 方案相比ECN 方案不具備優勢。但是，RTT 相比與 ECN，在測量的角度仍有其優勢。在解決了控制器設計的問題后，其方案簡單、測量精度高、端到端、設備依賴弱等特性，使其在未來云數據中心的應用前景更加廣闊。2 2優先級隊列檢測優先級隊列檢測圖 22 優先級隊列測量原理52文獻52中提出了一種使用不同優先級隊列消息，實現擁塞檢測的技術方案。該方案中，使用商用交換機中可用的基本特性（優先級隊列），無需對交換機進行修改或在主機上實施任何復雜的算法。它使用了 Scout 服務技術，Sc

82、out 服務基于一個簡單而有效的想法，即使用交換機中的優先級隊列來獲取擁塞狀態。45數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004圖 23 DWTCP 方案52當高優先級隊列（HPQ）變得更加繁忙（鏈路利用率更高）時，低優先級隊列（LPQ）獲得的服務機會更少（如圖 1 所示）。因此，測量 LPQ 隊列中的消息的 RTT 時延，觀察到鏈路的狀態，并且，這一檢測可以在觀察到 HPQ 建立之前幾個 RTT 檢測到擁塞，相比于傳統的擁塞檢測技術，能有提前預測擁塞的功能。（三）（三）端側協同擁塞檢測端側協同擁塞檢測交換機雖然通常是鏈路中擁塞的瓶頸點，但單獨使用交換機完

83、成的擁塞檢測，不能對網卡的擁塞程度有直接的測量。因此，一些研究工作中提出，要使用端網協同的擁塞檢測方案來實現全鏈路的擁塞檢測。1 1I INTNT 檢測檢測圖 24 INT 檢測及在 HPCC 中的應用1646數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004當前，交換機在數據平面上變得更加開放和靈活。其中，網絡內部遙測（In-Network Telemetry，INT）正在迅速普及。我們所了解的幾乎所有交換機供應商都已經在其新產品中啟用了 INT 功能（例 如，Barefoot Tofino、Broadcom Tomahawk3、BroadcomTrident

84、3 等），越來越多的商用交換機也在逐步支持 INT。通過 INT，發送者可以通過 ACK 數據包準確了解流經路徑上鏈路的負載情況，從而便于發送者進行準確的流量調整。例如，在如圖所示的 HPCC 擁塞控制協議中，阿里云的研究人員通過自定義了擁塞檢測的 INT 報文，準確的獲取了鏈路中網絡設備的隊列長度、時間、發送數據總量等信息，實現了全鏈路細粒度擁塞檢測。但 INT 帶來檢測精度提升是通過增加包問頭的形式完成的，這就造成了一定的帶寬浪費。如何平衡 INT 帶來的檢測精度提升和造成的 overhead，成為了使用 HPCC 不得不考慮的一個問題。后續的研究工作中，文獻24提出了概率添加的 PINT

85、 來減少 INT 的overhead。但是，這項工作并未完全解決 INT 帶來 overhead 的問題，而是給精度和 overhead 這一組 tradeoff 提供了一個歸一化的調節參數，如何平衡這一矛盾仍是一個問題。2 2ECN#ECN#檢測檢測ECN 已經在生產數據中心廣泛使用，以提供高吞吐量和低延遲的通信。盡管取得了成功，但之前基于 ECN 的傳輸機制存在一個重47數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004要的缺點：在計算瞬時 ECN 標記閾值時采用了固定的往返時間（RTT）值，忽視了實際中的 RTT 變化。然而，在數據中心中往返時間（RTT）

86、的變化很常見，因為不同的流量通過不同的處理組件，例如網絡堆棧、虛擬化管理程序和中間件。與服務內部的流量相比，服務之間的流量經歷了來自第四層負載均衡器的額外處理延遲。此外，給定組件的處理延遲也會根據工作負載的不同而變化。據研究顯示，這一波動往往會達到 3 倍以上。文獻50中提出了 ECN#，它基于瞬時和持續的擁塞狀態對數據包進行標記。當滿足以下條件之一時，數據包將被標記：當存在大的瞬時隊列時，ECN#會主動標記數據包以避免緩沖區溢出。當存在持續隊列時，ECN#會保守地標記數據包以減少排隊延遲。ECN#是對 ECN 標記的一個補充，它結合了網卡側的 RTT 信息，使 ECN 標記的閾值設置成動態的

87、。根據文獻50中的評估，ECN#對于短流的平均流完成時間（FCT）可以降低高達 23.4%（99th 百分位數為 31.2%），同時為大流提供類似的 FCT。48數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-030043 3ConExConEx 檢測檢測圖 25 ConEx 架構51ConEx（Congestion Exposure）51是 IETF 標準組織中提出的一種旨在提高網絡的性能和可靠性，避免網絡擁塞引起的數據丟失、延遲和抖動等問題的擁塞檢測技術。ConEx 通過在數據包頭部添加擁塞信息，向網絡設備和終端設備傳遞擁塞信息，從而調整數據傳輸速率，以適應網絡的擁

88、塞狀況。在網絡中的特定測量點，“剩余路徑擁塞”（也稱為“下行擁塞”）是一個流預計在測量點和其最終目標之間經歷的擁塞水平?！吧闲袚砣笔窃跍y量點之前經歷的擁塞。如果網絡中的流量支持 ECN（顯式擁塞通知），則路由器可以在中間節點監測 ECN 信號，并根據該信號量測上行擁塞情況。與之不同的是，ConEx 信號將插入 IP 頭中，從源端到目的端包含了整個網絡路徑中的擁塞情況。因此，如果監測點檢測到這兩個信號，它49數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004可以通過將 ConEx 的路徑擁塞情況減去 ECN 的上行擁塞情況，計算出數據包在監測點和目標之間可能遇到

89、的擁塞情況，也就是剩余路徑擁塞。這個計算可以對所有流量進行匯總。ConEx 目前還沒有公開的文獻討論其在 RoCE 網絡中的應用，但剩余路徑擁塞檢測無疑是當前 ECN 檢測方案的一個有力補充，它更好的利用了端側能提供的信息。4 4本章小結本章小結本章歸納了高性能網絡中，擁塞檢測相關的技術，以網側、端側、端網協同為依據，將現有的擁塞檢測技術及其典型應用進行了簡單的歸納。不同的擁塞檢測機制存在明顯的優缺點，這決定了其在高性能網絡中的應用也需要各有側重。同時，在本章中討論了各項擁塞檢測技術設計的本質?？傮w上看，當前的擁塞檢測機制設計上，檢測、處理、控制多個環節緊耦合的現狀下，擁塞檢測機制難以標準化、

90、模塊化。需要在后續的數據中心網絡領域開展更為系統的研究。50數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004四、四、總結與展望總結與展望隨著未來數字經濟發展，算力網絡宏觀戰略日益落實，東數西算、大模型等新興應用場景與算力需求形成了交替驅動的螺旋上升趨勢。同時，算力需求的膨脹帶動了網絡互連帶寬需求的直線上升，未來數據中心網絡隨著云計算的發展將占據更多的市場份額，這都給高性能網絡技術的發展提供了新的機遇。而在這一新的機遇期，RoCE 網絡由于其開放兼容的優勢，毫無疑問將成為這次技術浪潮中的主角。而相比 Infiniband 傳統高性能網絡，RoCE 網絡在擁塞管理

91、控制技術方面，存在一定的差距。首先，本白皮書中就高性能網絡的背景和現狀進行了研究，總結了當前數據中心中分布式存儲、內存池化、鍵值存儲、智能算力等場景下高性能網絡的應用情況，并分析了高性能網絡中的擁塞問題。然后，本白皮書進一步總結歸納了高性能網絡的擁塞管理控制技術體系。從網絡層、傳輸層、鏈路層逐級分解，對已有的擁塞管理控制技術體系進行了深度的剖析。本白皮書中，以網側驅動、端側驅動、端網協同為劃分依據，對現有的擁塞檢測技術進行了細致的分類，同時深入討論了不同擁塞檢測技術方案設計的優缺點，探討了不同方案的本質特點，對工業部署廣泛、學術影響深遠的技術方案和方法進行了系統解讀。本白皮書為探索更多擁塞檢測

92、技術應用，實現標準化、規范化、模塊化的高性能網絡擁塞檢測技術落地，提供一些理論和實踐參考。51數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004目前，擁塞檢測技術仍存在如下的挑戰：1、檢測效果與資源占用不可兼得的矛盾。提高檢測的精度和頻率通常需要增加系統的復雜度和提高資源的占用，如何權衡方案的損失收益，目前沒有明確的評價規范。例如，INT 帶來的擁塞控制效果提升，與其 overhead 占用的資源，怎樣評估利弊。這一規范需要進一步系統的研究和審慎的論證。2、檢測環節與處理、控制環節的耦合。當前的擁塞管理與控制方案中，檢測、處理、控制三個環節往往通過一個整體來設計

93、，這也導致離開整體系統的特定硬件，檢測環節難以獨立工作。這需要當前 RoCE 網絡的標準化工作更加系統的對擁塞檢測技術進行分解，實現擁塞檢測技術的標準化、規范化、模塊化。3、檢測技術多層次應用。當前的擁塞檢測技術普遍的應用于擁塞控制協議中，構建閉環的控制系統。閉環控制系統能夠有效的抵御外部擾動，這對于高性能網絡在復雜的云場景應用有重要意義。而更上層的負載均衡、流量調度技術中，目前較少應用反饋的機制，這也導致很多新技術在復雜場景不具應用前景?？偟膩碚f，高性能網絡擁塞管理與控制的技術體系目前越發清晰。作為其中的基石技術，擁塞檢測技術在各種技術方案中具有核心影響。而未來，擁塞檢測技術是整個擁塞管理控

94、制技術體系的基石，其關鍵的系統化、標準化、模塊化工作，將成為高性能網絡進一步規模應用的重要技術支撐。52數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004參考文獻參考文獻1W.Bai et al.,“Empowering Azure Storage with RDMA”.2Y.Gao et al.,“When Cloud Storage Meets RDMA,”in 18th USENIXSymposium on Networked Systems Design and Implementation(NSDI 21),2021,pp.519533.3R.Miao

95、 et al.,“From luna to solar:the evolutions of the compute-to-storagenetworks in Alibaba cloud,”in Proceedings of the ACM SIGCOMM 2022Conference,Amsterdam Netherlands:ACM,Aug.2022,pp.753766.doi:10.1145/3544216.3544238.4P.X.Gao et al.,“Network Requirements for Resource Disaggregation,”in 12thUSENIX Sy

96、mposium on Operating Systems Design and Implementation(OSDI16),Savannah,GA:USENIX Association,Nov.2016,pp.249264.Online.Available:https:/www.usenix.org/conference/osdi16/technical-sessions/presentation/gao5P.Zuo,J.Sun,L.Yang,S.Zhang,and Y.Hua,“One-sided RDMA-ConsciousExtendible Hashing for Disaggreg

97、ated Memory”.6A.Dragojevi,D.Narayanan,O.Hodson,and M.Castro,“FaRM:Fast RemoteMemory,”in Proceedings of the 11th USENIX Conference on NetworkedSystems Design and Implementation,in NSDI14.USA:USENIX Association,2014,pp.401414.7X.Wei,R.Chen,and H.Chen,“Fast RDMA-based Ordered Key-Value Storeusing Remot

98、e Learned Cache”.8X.Jin et al.,“NetCache:Balancing Key-Value Stores with Fast In-NetworkCaching,”in Proceedings of the 26th Symposium on Operating SystemsPrinciples,ShanghaiChina:ACM,Oct.2017,pp.121136.doi:10.1145/3132747.3132764.9“5_最佳實踐-使用 SMC 和 ERI 透明加速 Redis 應用-OpenAnolis 代碼庫.”https:/ 年）ODCC-202

99、3-0300410 L.Shalev,H.Ayoub,N.Bshara,and E.Sabbag,“A Cloud-Optimized TransportProtocol for Elastic and Scalable HPC,”IEEE Micro,vol.40,no.6,Art.no.6,Nov.2020,doi:10.1109/MM.2020.3016891.11 S.Hu et al.,“Tagger:Practical PFC Deadlock Prevention in Data CenterNetworks,”in Proceedings of the 13th Interna

100、tional Conference on emergingNetworking EXperiments and Technologies,Incheon Republic of Korea:ACM,Nov.2017,pp.451463.doi:10.1145/3143361.3143382.12 Y.Zhu et al.,“Congestion Control for Large-Scale RDMA Deployments,”inProceedings of the 2015 ACM Conference on Special Interest Group on DataCommunicat

101、ion,London United Kingdom:ACM,Aug.2015,pp.523536.doi:10.1145/2785956.2787484.13“802.1Qau Congestion Notification|.”https:/1.ieee802.org/dcb/802-1qau/(accessed Apr.10,2023).14 M.Alizadeh et al.,“Data Center TCP(DCTCP),”in Proceedings of the ACMSIGCOMM 2010 Conference,in SIGCOMM 10.New York,NY,USA:Ass

102、ociationforComputingMachinery,2010,pp.6374.doi:10.1145/1851182.1851192.15 R.Mittal et al.,“TIMELY:RTT-based Congestion Control for the Datacenter,”in Proceedings of the 2015 ACM Conference on Special Interest Group on DataCommunication,London United Kingdom:ACM,Aug.2015,pp.537550.doi:10.1145/2785956

103、.2787510.16 Y.Li et al.,“HPCC:high precision congestion control,”in Proceedings of theACM Special Interest Group on Data Communication,Beijing China:ACM,Aug.2019,pp.4458.doi:10.1145/3341302.3342085.17 S.Yan,X.Wang,X.Zheng,Y.Xia,D.Liu,and W.Deng,“ACC:automaticECN tuning for high-speed datacenter netw

104、orks,”in Proceedings of the 2021ACM SIGCOMM 2021 Conference,Virtual Event USA:ACM,Aug.2021,pp.384397.doi:10.1145/3452296.3472927.18 Y.Gao,Y.Yang,T.Chen,J.Zheng,B.Mao,and G.Chen,“DCQCN+:TamingLarge-Scale Incast Congestion in RDMA over Ethernet Networks,”in 2018IEEE 26th International Conference on Ne

105、twork Protocols(ICNP),Cambridge:54數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004IEEE,Sep.2018,pp.110120.doi:10.1109/ICNP.2018.00021.19 R.Mittal et al.,“Revisiting network support for RDMA,”in Proceedings of the2018 Conference of the ACM Special Interest Group on Data Communication,BudapestHungary:ACM,Aug

106、.2018,pp.313326.doi:10.1145/3230543.3230557.20 Y.Zhang,Y.Liu,Q.Meng,and F.Ren,“Congestion detection in losslessnetworks,”in Proceedings of the 2021 ACM SIGCOMM 2021 Conference,VirtualEventUSA:ACM,Aug.2021,pp.370383.doi:10.1145/3452296.3472899.21 Y.Zhu,M.Ghobadi,V.Misra,and J.Padhye,“ECN or Delay:Les

107、sons Learntfrom Analysis of DCQCN and TIMELY,”in Proceedings of the 12thInternational on Conference on emerging Networking EXperiments andTechnologies,Irvine California USA:ACM,Dec.2016,pp.313327.doi:10.1145/2999572.2999593.22 G.Kumar et al.,“Swift:Delay is Simple and Effective for Congestion Contro

108、l inthe Datacenter,”in Proceedings of the Annual conference of the ACM SpecialInterest Group on Data Communication on the applications,technologies,architectures,and protocols for computer communication,Virtual Event USA:ACM,Jul.2020,pp.514528.doi:10.1145/3387514.3406591.23 G.Zeng,W.Bai,G.Chen,K.Che

109、n,D.Han,and Y.Zhu,“Combining ECN andRTT for Datacenter Transport,”in Proceedings of the First Asia-PacificWorkshop on Networking,Hong Kong China:ACM,Aug.2017,pp.3642.doi:10.1145/3106989.3107002.24 R.Ben Basat,S.Ramanathan,Y.Li,G.Antichi,M.Yu,and M.Mitzenmacher,“PINT:Probabilistic In-band Network Tel

110、emetry,”in Proceedings of the Annualconference of the ACM Special Interest Group on Data Communication on theapplications,technologies,architectures,andprotocolsforcomputercommunication,Virtual Event USA:ACM,Jul.2020,pp.662680.doi:10.1145/3387514.3405894.25 P.Taheri,D.Menikkumbura,E.Vanini,S.Fahmy,P

111、.Eugster,and T.Edsall,“RoCC:robust congestion control for RDMA,”in Proceedings of the 16th55數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004InternationalConferenceonemergingNetworkingEXperimentsandTechnologies,BarcelonaSpain:ACM,Nov.2020,pp.1730.doi:10.1145/3386367.3431316.26 X.Zhong,J.Zhang,Y.Zhang,Z.Guan

112、,and Z.Wan,“PACC:Proactive andAccurate Congestion Feedback for RDMA Congestion Control,”in IEEEINFOCOM 2022-IEEE Conference on Computer Communications,London,UnitedKingdom:IEEE,May2022,pp.22282237.doi:10.1109/INFOCOM48880.2022.9796803.27 J.Zhang et al.,“Receiver-Driven RDMA Congestion Control by Dif

113、ferentiatingCongestion Types in Datacenter Networks,”in 2021 IEEE 29th InternationalConference on Network Protocols(ICNP),Dallas,TX,USA:IEEE,Nov.2021,pp.112.doi:10.1109/ICNP52444.2021.9651938.28“802.1Qbb Priority-based Flow Control|.”https:/1.ieee802.org/dcb/802-1qbb/(accessed Sep.03,2022).29 M.Al-F

114、ares,S.Radhakrishnan,B.Raghavan,N.Huang,and A.Vahdat,“Hedera:Dynamic Flow Scheduling for Data Center Networks”.30 Z.Liu et al.,“BurstBalancer:Do Less,Better Balance for Large-scale DataCenter Traffic”.31 M.Alizadeh et al.,“CONGA:distributed congestion-aware load balancing fordatacenters,”in Proceedi

115、ngs of the 2014 ACM conference on SIGCOMM,ChicagoIllinoisUSA:ACM,Aug.2014,pp.503514.doi:10.1145/2619239.2626316.32 M.Alizadeh et al.,“pFabric:minimal near-optimal datacenter transport,”inProceedings of the ACM SIGCOMM 2013 conference on SIGCOMM,HongKong China:ACM,Aug.2013,pp.435446.doi:10.1145/24860

116、01.2486031.33 C.-Y.Hong,M.Caesar,and P.B.Godfrey,“Finishing flows quickly withpreemptivescheduling,”inProceedingsoftheACMSIGCOMM2012conference on Applications,technologies,architectures,and protocols forcomputer communication,Helsinki Finland:ACM,Aug.2012,pp.127138.doi:10.1145/2342356.2342389.56數據中心

117、高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-0300434 W.Bai,L.Chen,K.Chen,D.Han,C.Tian,and H.Wang,“Information-Agnostic Flow Scheduling for Commodity Data Centers”.35 J.Perry,A.Ousterhout,H.Balakrishnan,D.Shah,and H.Fugal,“Fastpass:acentralized zero-queue datacenter network,”in Proceedings of the 2014 ACMconferen

118、ce on SIGCOMM,Chicago Illinois USA:ACM,Aug.2014,pp.307318.doi:10.1145/2619239.2626309.36 B.Montazeri,Y.Li,M.Alizadeh,and J.Ousterhout,“Homa:a receiver-drivenlow-latency transport protocol using network priorities,”in Proceedings of the2018 Conference of the ACM Special Interest Group on Data Communi

119、cation,BudapestHungary:ACM,Aug.2018,pp.221235.doi:10.1145/3230543.3230564.37 L.Chen,J.Lingys,K.Chen,and F.Liu,“AuTO:scaling deep reinforcementlearning for datacenter-scale automatic traffic optimization,”in Proceedings ofthe2018ConferenceoftheACMSpecialInterestGrouponDataCommunication,Budapest Hunga

120、ry:ACM,Aug.2018,pp.191205.doi:10.1145/3230543.3230551.38 杜鑫樂,“數據中心網絡的流量控制：發展現狀與趨勢,”計算機學報,2020.39 B.Vamanan,J.Hasan,and T.N.Vijaykumar,“Deadline-aware datacenter tcp(D2TCP),”in Proceedings of the ACM SIGCOMM 2012 conference onApplications,technologies,architectures,andprotocolsforcomputercommunicatio

121、n,Helsinki Finland:ACM,Aug.2012,pp.115126.doi:10.1145/2342356.2342388.40 C.Wilson,H.Ballani,T.Karagiannis,and A.Rowtron,“Better never than late:meeting deadlines in datacenter networks,”in Proceedings of the ACMSIGCOMM 2011 conference,Toronto Ontario Canada:ACM,Aug.2011,pp.5061.doi:10.1145/2018436.2

122、018443.41 L.S.Brakmo,S.W.OMalley,and L.L.Peterson,“TCP Vegas:new techniquesfor congestion detection and avoidance,”in Proceedings of the conference onCommunications architectures,protocols and applications-SIGCOMM 94,London,UnitedKingdom:ACMPress,1994,pp.2435.doi:57數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-202

123、3-0300410.1145/190314.190317.42 D.Scholz,B.Jaeger,L.Schwaighofer,D.Raumer,F.Geyer,and G.Carle,“Towards a Deeper Understanding of TCP BBR Congestion Control,”in 2018IFIP Networking Conference(IFIP Networking)and Workshops,Zurich,Switzerland:IEEE,May2018,pp.19.doi:10.23919/IFIPNetworking.2018.8696830.

124、43 J.H.Salim and U.Ahmed,“Performance Evaluation of Explicit CongestionNotification(ECN)in IP Networks,”Internet Engineering Task Force,Requestfor Comments RFC 2884,Jul.2000.doi:10.17487/RFC2884.44 K.K.Ramakrishnan and S.Floyd,“A Proposal to add Explicit CongestionNotification(ECN)to IP,”Internet En

125、gineering Task Force,Request forComments RFC 2481,Jan.1999.doi:10.17487/RFC2481.45 S.Floyd and V.Jacobson,“Random early detection gateways for congestionavoidance,”IEEE/ACM Trans.Networking,vol.1,no.4,pp.397413,Aug.1993,doi:10.1109/90.251892.46 W.Fengy,D.D.Kandlurz,D.Sahaz,and K.G.Shiny,“BLUE:A New

126、Class ofActive Queue Management Algorithms”.47 B.Nandy,N.Seddigh,and J.H.Salim,“A proposal for Backward ECN for theInternet Protocol(IPv4/IPv6),”Internet Engineering Task Force,Internet Draftdraft-salim-jhsbnns-ecn-00,Jun.1998.Accessed:Aug.25,2023.Online.Available:https:/datatracker.ietf.org/doc/dra

127、ft-salim-jhsbnns-ecn-0048 R.Jain,“Enhanced Forward Explicit Congestion Notification(E-FECN)Schemefor Datacenter Ethernet Networks”.49 P.Eardley,“Pre-Congestion Notification(PCN)Architecture,”Art.no.rfc5559,Jun.2009,doi:10.17487/RFC5559.50 J.Zhang,W.Bai,and K.Chen,“Enabling ECN for datacenter network

128、s withRTT variations,”in Proceedings of the 15th International Conference onEmerging Networking Experiments And Technologies,Orlando Florida:ACM,Dec.2019,pp.233245.doi:10.1145/3359989.3365426.51 B.Briscoe,R.Woundy,and A.Cooper,“Congestion Exposure(ConEx)58數據中心高性能網絡擁塞檢測技術白皮書（2023 年）ODCC-2023-03004Concepts and Use Cases,”Art.no.rfc6789,Dec.2012,doi:10.17487/RFC6789.52 S.Abbasi,S.Ketabi,A.Munir,M.Bahnasy,and Y.Ganjali,“DWTCP:UltraLowLatencyCongestionControlProtocolforDataCenters,”no.arXiv:2207.05624.arXiv,Jul.12,2022.Accessed:Jul.14,2022.Online.Available:http:/arxiv.org/abs/2207.05624