1數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-030041數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004版權聲明本白皮書版權屬于中國移動通信集團公司、中國信息通信研究院并受法律數據中心高性能網絡擁塞檢測技術白皮書”。違反上述聲明者，編者將追究其I編寫組數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004 I II VI 1 3 4 4 6 7 9 10 13 13 14 14 15 16 18 21 21 23 25數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004 26 27 27 29 29 30 31 32 34 34 35 36 37 37 41 42 42 43 44 45 45 46 48 49數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004V術語與縮略語MeaningExplicitCongestionDataCenterQuantizedCongestionHighPrecisionCongQuantizedCongestionDistributedCongestion-AwareLoBackwardCongestionNForwardExplicitCongestion數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004《“十四五”數字經濟發展規劃》中指出數字經濟是繼農業經濟、工業經濟之后的主要經濟形態，是以數據資源為關鍵要素，以現代信息網絡為主要載體，以信息通信技術融合應用、全要素數字隨著數字經濟的持續發展，算力需求呈爆發性增長，逐步成為靈活、敏捷的數據中心網絡新型基礎設施，成為算力網絡驅動和演遠程直接內存訪問（RemoteDirectMemoryAccess，RDMA）網絡是一種高性能網絡傳輸技術。通過繞過操作系統內核，RDMA可以直接在網絡適配器和內存之間傳送數據，從而減少了數據傳輸過程高性能網絡廣泛應用于高性能計算、云計算、大數據處理等領域，高性能網絡的重要性在于，為各種應用提供了快速、可靠、安全的數據傳輸能力，并將數據中心、云計算和大數據處理等領域的計算資源、存儲資源和網絡資源緊密結合，提高了整個系統的效率和性能。同時，高性能網絡還可以支持更多的應用和服務，促進了科學研究、產業發展和社會進步。因此，高性能網絡的發展和研究1數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004本白皮書通過闡明和分析高性能網絡技術發展的過程與現狀，以網絡擁塞這一關鍵問題展開詳述當前業界擁塞管理控制技術的架構體系，并聚焦擁塞管理控制過程中面臨不同需求所產生的擁塞檢測機制。本白皮書旨在通過對擁塞檢測技術的研究，推動高性能網2數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004在持續。因此，作為未來數據中心服務的提供者，云計算廠商面臨的需求。一方面，快速膨脹的鏈路速率導致了極高的CPU占用率，每增加一個用于TCP網絡傳輸的CPU資源意味著云計算廠商能夠出售的虛擬機減少了一個，這將降低整體的經濟效益。另一方面，機器學習、搜索等業務所要求的超低的網絡延遲（低于10us/跳）,為解決這一問題，遠程直接內存獲取（RemoteDirectMemoryAccess,RDMA）技術開始逐漸廣泛地應用于數據中心網絡中（本文提及的RDMA無損網絡針對更廣泛應用的以太網絡，如無特殊聲明，1）降低了CPU占用率。數據傳輸過程不再需要CPU的持續介2）降低了傳輸時延，避免了數據拷貝過程中頻繁的用戶態和內3數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004正因為以上的技術優勢，高性能網絡已經成為云計算領域應用廣泛核心基礎設施之一。據公開文獻[1]顯示，在微軟Azure存儲集群中，RDMA流量已經占據了超過一半的比例。在可以預見的未來，高性能網絡技術都將作為云計算領域的核心基礎設施之一，深刻地隨著云計算技術的發展，高性能網絡的應用場景日益增多。本節主要從分布式云存儲、內存池化、鍵值存儲、智算中心四個方向分布式存儲是云計算中的一個核心應用。各家云廠商都會提供4數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004就要求了網絡要提供極高的吞吐量和極低的響應時間。因此，主流云廠商普遍選擇RDMA作為高性能分布式存儲的網絡解決方案，如公間的測試結果。在圖中，Kernal是傳統的TCP/IP協議，Luna是用的前端網絡，BN是存儲集群后端網絡，SSD是落盤網絡，SA是阿里自研的SPDK軟件。該實驗很好的對比了內核態、用戶態、RDMA對于存儲業務的影響。可以看到，整體IO延遲性能上，SolarRDMA5數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004協議有明顯的優勢。同時，RDMA網絡協議棧還在現有的數據中心是通過服務器構建的，每個服務器緊密集成了為中心的架構已經持續使用了幾十年，但最近的研究表明，未來即將出現一種向分解式數據中心（DisaggregatedDatacenter，DDC）轉變的范式。其中，每種資源類型都作為獨立的資源池進行構建，6數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004資源池化的一個關鍵的促進（或阻礙）因素將是網絡。因為將CPU與內存、磁盤分解開來，原本需要在服務器內部進行的資源間通信，而現在必須通過網絡進行。因此，為了支持良好的應用級性因此，RDMA高性能網絡作為一個解決方案在內存池化的場景已盡管沒有完全解決資源池化場景的網絡互連問題，但其仍然是未來鍵值存儲（Key-ValueStore）是一種數據存儲方法，它以鍵值對（Key-ValuePair）的形式存儲和訪問數據。與傳統的關系型數據庫相比，鍵值存儲通常更加簡單、靈活、高效，并且可以處理更大規模的數據。鍵值存儲不要求數據具有固定的結構和模式，因此7數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004可以輕松地存儲和檢索各種類型的數據。鍵值存儲還支持高度可擴展性和分布式部署，可以輕松地在多個節點上進行水平擴展和數據在常見應用中，Redis就是一種流行的鍵值存儲系統。它支持多種數據類型，包括字符串、哈希、列表、集合和有序集合等。與關系型數據庫不同，Redis不支持復雜的SQL查詢語句，而是提供然而，在鍵值存儲中，CPU是一個顯而易見的性能瓶頸。而RDMA技術通過繞過內核的方式直接訪問內存，這能夠保證CPU資源的高效利用。因此，RDMA技術在鍵值存儲系統中的應用也逐漸被更多的討論[7],[8]。同時，阿里云也公開聲明了其eRDMA技術在Redis產品中的應用[9]。從測試結果可以看出，無論是GET測試還是SET8數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-030044．智能算力場景近年來,大型語言模型如GPT等在自然語言處力引起了廣泛關注。這些模型通過預訓練在海量文本數據上獲取語言知識,然后進行微調應用于下游任務。大模型以極大的模型尺寸、大量數據和計算資源進行訓練。其一系列成果顯示了大模型具備了但是訓練大模型也帶來了巨大的計算和環境成本，需要大規模a)模型參數量巨大,單機單卡無法加載整個模型。而使用多b)訓練時間長。如果只使用單機單卡,訓練大模型往往需要9數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004c)訓練數據量大。多機多卡并行讀取數據后匯總梯度，產生多個GPU的互聯，打造多通道、無收斂、多路徑的參數網絡（如圖5所示），是當前的主流技術方案之一。AWS在其超算、智算廣泛的提供SRD高性能網絡服務[10]，進一步的引起了行業內對高性高性能網絡已經成為云計算領域應用廣泛核心基礎設施之一。然而，RDMA網絡中出現擁塞問題將會大幅降低網絡的吞吐和延遲性據流量超過了網絡鏈路的處理能力或帶寬限制或者當多個節點同時進行RDMA通信時，網絡鏈路無法及時處理或傳輸所有的數據包，就擁塞一方面會導致交換機的緩存隊列增大，數據包傳輸的延遲等比例的延長，使網絡服務質量下降；另一方面，交換機中數據包中會出現一系列相應的風暴、死鎖等問題[11]。這也一定程度上限制數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004RDMA高性能網絡方向聚焦擁塞問題，產生了大量的前沿研究和工程總之，隨著未來數據中心網絡帶寬需求的不斷增長，RDMA高性能網絡在云計算、人工智能等領域具有巨大的機遇。同時，擁塞問化的擁塞管控系統，將已有技術進行歸納延伸，是當前數據中心網絡中迫切要完成的一項工作。擁塞檢測技術中，有如下幾點挑戰亟a)精度、頻率和開銷的矛盾。對于網絡擁塞信息的檢測，當前存在多種主流方案，其獲取的擁塞信息都不相同，但都遵循“沒有免費的午餐”這一規則。更高的測量精度、更快的測量頻率，都會帶來額外的網絡帶寬開銷（例如INT對比ECN）。這需要對不同b)標準和兼容性：RDMA技術存在多種標準和實現，如InfiniBand、RoCE（RDMAoverConve（InternetWideAreaRDMAProtocol）。其中，RoCE網絡的發展近年來尤為迅猛。原有的以太網擁塞檢測機制和協議該如何規范化，這也是未來不同RoCE網絡設備數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004c)跨層級應用：不同的擁塞檢測機制可以在更多的擁塞管控負載均衡的參考權重。這些研究工作雖然已經較多，但哪些擁塞檢本白皮書通過闡明和分析高性能網絡擁塞管控的技術發展的過程與現狀，整理、探討不同方案中關鍵的擁塞檢測機制，歸納其技術路線與演進，從而推動高性能網絡技術的深入發展，助力完整的數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004為了緩解高性能網絡中的擁塞問題，RoCE高性能網絡協議已經構建了多層的擁塞管理和控制技術體系。這一體系中，細分主要包含擁塞控制、負載均衡、鏈路控制、流量調度等。形成了從用戶層其中，擁塞控制協議、鏈路控制的響應快、周期短，通過調整因此歸類為擁塞控制技術；負載均衡、流量調度，往往通過管理的方式，對數據進行調度分流，通過更高效的利用網絡拓撲資源實現本章中重點對現有擁塞管理與控制技術進行了歸納整理。以便擁塞控制，顧名思義，可知其在網絡擁塞問題處理中的核心位置。擁塞控制是為了防止網絡過載而采取的一種流量調節機制。當網絡擁塞時，路由器隊列堆積,丟包和延遲增加。擁塞控制算法(如TCP的滑動窗口)可以通過監控網絡狀況來動態調整發送方的發送速率。比如，在擁塞開始時降低發送速率，擁塞消除后逐漸增加發送速率。這種閉環反饋機制可以使網絡穩定運行在最優狀態，最大化數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004為了緩解網絡擁塞，文獻[12]中微軟提出了一種端到端的RoCE擁 塞控制協議DCQCN，這也是近幾年來RoCE高性能網絡擁塞控制技術的開端。DCQCN相比于PFC是一種更精細的控制算法。它以ECN（ExplicitCongestionNotification，ECN）作為交換機擁塞程度的量化標記信息，根據生成的CNP（CongestionNotificationPacket）報文來觸發式的調節網卡傳輸速率。DCQCN的設計理念結合了既有的QCN[13]和DCTCP[14]的算法思想。一方面避免了QCN方法局 DCQCN的使用大幅度緩解了PFC的觸發，目前仍是最廣泛應用的數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004同期，谷歌在文獻[15]中提出了一種基于時延的擁塞控制方案TIMELY。TIMELY使用數據流的往返傳遞時間（RoundTripTime，相較于傳統的軟件測量的RTT，谷歌方案在他們的智能網卡中集成了專有的RTT硬件測量電路，這使得RTT測量擁塞的方案得以實用化。同時RTT相比于ECN是一個快速、多位的數據，能夠提供更豐微軟的DCQCN和谷歌的TIMELY在RDMA網絡擁塞控制方面雖然各有所長，但仍存在各自難以突破的局限性。2019年，阿里云提出了一種基于帶內遙測（In-NetTelemetry，INT）的擁塞控制協議HPCC[16]。相比于DCQCN和TIMELY，HPCC方法犧牲了了INT能力，同時也獲得了超高精度的擁塞控制性能。HPCC可以實現快速的算法收斂以更優的利用閑置帶寬，同時保持交換機始終處數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-030044．其他技術方案盡管HPCC在處理擁塞方面的性能得到了普遍的認可，但它過高的網絡帶寬占用仍然為后續的技術改進留下了空間。此后，更多的ECN參數，大幅度降低了運維大規模RDMA集群過程中調試算法參數通過自適應的選取DCQCN的參數，實現大規模多打一場景小步長，小規模多打一場景大步長的控制效果；文獻[19]中提出了IRN，通TIMELY方案下擁塞場景的RDMA網絡性能；文獻[20]改進了交換機的ECN標記機制，將傳統的兩態標記優化為三態標記TCD，提升了(2)RTT方案變種：文獻[21]中建立了DCQCN和TIMELY的流體模型，分別就二者的擁塞控制效果進行了對比研究。基于二者性能上的差別，其提出了使用PI控制器的改進TIMELY算法，一定程度點不固定這一問題，重新設計了TIMELY的調速算法，使用了AIMD（Additive-IncreaseMultiplicative-Decrease，AIMD）調速算法，數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004從而實現了更好的算法穩定性；文獻[23]通過將ECN信號與RTT信號結合考慮，提出了EAR擁塞控制協議，在多個場景實現了更好的(3)INT方案變種：文獻[24]為了解決HPCC中INT包頭帶來的明顯的網絡帶寬占用問題，提出了概率性帶內遙測（ProbabilisticIn-bandNetworkTelemetry，PINT）方案。PINT使用了概率性編HPCC-INT接近的流完成時間分布，HPCC-PINT在長流上略優但在短流上略差。該方案難以大規模部署的局限在于P4可編程交換機的資另一類興起的是基于接收方的方案。思科首先提出了RoCC[25]。在該方案中，將傳統的由發送方驅動的端到端擁塞控制協議，改進為接收方驅動。在文獻[25]中認為，多個不同發送方做出的調速決策時常是矛盾的，這導致了最終控制效果的反復波動。而由接收方驅動的擁塞控制協議中，交換機作為擁塞的感知方，可以進行更準數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004控制協議作為處理擁塞問題的最短回路在學術研究和工業應用角度都極具研究價值。目前，擁塞控制協議主流應用的方案仍然是DCQCN、TIMELY和HPCC，但顯然這三種方案都存在不同的缺陷。后續提出的方案有些偏向解決某一特定流量場景的問題，有些需要更新的硬件支持，難以大規模商用并完全解決RDMA無損網絡擁塞控制慢快快快低高高中差中強強差差差差根據上一節中總結的當前擁塞控制協議的核心功能點，本文就數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004DCQCN協議強項在于兼容性，這也直接決定了DCQCN成為了現在最為主流的應用方案。具體來講，DCQCN協議對于交換機要求較是，DCQCN在收斂速度、帶寬利用率方面與穩定性存在一個博弈，即往往需要犧牲穩定性來實現更高的帶寬利用率，二者不可兼得。其次，DCQCN在易用性方面有明顯缺陷，端側和網側有十余個參數需要調試且參數相互耦合，維護成本很高。同時，DCQCN使用了AIMD（AdditiveIncreaseMultiplicativeDecrease,AIMD）調速機制是不基于模型的調速算法。對于不同場景下的擾動，有較強的TIMELY協議的優勢主要是檢測精確，RTT測量的擁塞信息本身就是多位的，這解決了DCQCN算法中最大的一個局限點。因此，TIMELY在收斂速度和帶寬利用率上更高。但是，TIMELY在公平性和穩定性方面也是存在一組矛盾[21]：收斂到特定穩定點則不能保證公平，保證公平則不能保證達到目標收斂點。其次，TIMELY的易用性偏差，主要難點在于目標時延的選擇困難。同時，TIMELY采用的是基于模型的控制算法，這保證了精確計算的同時，帶來了對于擾動HPCC協議在公平性、收斂速度、穩定性方面都達到了相比于功能，這有效的保證了網絡的平均流完成時間(Flowcompletetime,數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004FCT)性能，降低了排隊時延。HPCC主要問題在于，INT消耗了10%了交換機，這方面的開銷導致HPCC仍有改進空間。此外，HPCC對交換機設備的要求較高，需要可編程交換機的支撐，這限制了它的推廣使用。最后，HPCC的算法是以BDP精確計算為基礎的，這本質上還是基于模型的控制方法。對于更復雜的場景，模型和參數的魯RoCC協議是針對其他方案的缺陷設計的，其實現上解決了絕大多數問題，性能指標趨于理想。相比于HPCC，RoCC在其基礎了PI控制器，該控制方法是不依賴于模型的，在實際應用中相比需要可編程交換機作為運算的主要載體，這對于交換機的性能提出了更高的要求。目前，可編程交換機技術已經開始快速發展，但其芯片架構決定了不適合執行高精度的運算任務。隨著未來芯片技術綜上所述，目前的擁塞控制協議很難在兼容、易用的基礎上，數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004鏈路控制技術主要通過速率限制和流量控制來實現，可以動態調整RDMA網絡中的數據發送速率,避免擁塞的相比于L4傳輸層的擁塞控制協議，鏈路控制協議工作在L2鏈路層。相應的，鏈路控制技術響應的時間相比擁塞控制更加短，速率的調節也更加及時。對應的擁塞檢測機制也明顯有別于L4層要求響應的速度更快。鏈路層控制中，往往并不獲取網絡內的擁塞因此，鏈路控制中的擁塞檢測與控制結合的更緊密，往往就是本節受限于篇幅，主要介紹Infiniband中常用的信用機制和數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004控制（Credit-BasedFlowControl）機制，用于優化數據傳輸。在InfiniBand中，每個端口都有一個緩沖區，用于存儲接收到的數據包。當發送端發送數據包時，它會向接收端發送一定數量的信用（Credit），表示接收端有多少可用的緩沖區來存儲數據包。在接收端，當緩沖區被占滿時，它會向發送端發送信號，表示不能再接基于信用的鏈路控制可以顯著提高網絡的吞吐量和性能。它可以避免數據包的丟失和重傳，并減少網絡擁塞和延遲。此外，由于每個端口都有自己的緩沖區，它也可以實現流量隔離和保障，從而兩者都是收發兩端協調控制發送數據量的鏈路層流量控制機制。相比滑動窗口使用ACK報文確認的方式，信用機制為了更高的性能，數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004優先級流控制（Priority-basedFlowControl，PFC）[28]是IEEE802.1Qbb定義的一項用于數據中心的無丟包網絡流量控制協議，主要用于確保網絡的無損特性。無損網絡意味著網絡不會因為擁塞而導致數據包丟失。上圖展示了在交換機層級之間實現PFC的PFC通過Pause幀觸發反壓的方式實現無丟包。當交換機隊列接近滿時（達到ON/OFF閾值），交換機將向上游交換機發送一個Pause幀，告知上游不要繼續發送數據包。待擁塞緩解后，再通知上游繼續發送數據包。同時，PFC通過虛擬隊列將數據包分成不同的優先級。即使某個優先級受到擁塞阻塞，仍然可以通過更高優先數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004a)導致出現受害者流，無法正常傳輸數據，如上圖中(b)所示，Egress2和3的數據包盡管未發生擁塞，也會被停止發送，即HoL（HeadofLine）阻塞。b)PFC風暴，Pause幀會反向逐級傳遞，形成網絡內大停止發送.c)PFC死鎖，當系統中出現Pause幀的CBD（CircularBufferDependency）現象時，PFC發生死鎖導致網絡傳輸長時間中止，如[11]總而言之，PFC技術是RoCE高性能網絡發展的重要過渡技術。數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004包括PFC自恢復機制、更高效的擁塞控制協議、選擇重傳[19]等一系列的解決方案。相關技術的后續研究進程將決定RoCE高性能網絡與QCN[13]是一種L2鏈路層的網絡擁塞控制技術，旨在提高網絡的QCN通過在交換機中實時監測網絡擁塞情況向終端設備發送擁塞通數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004格式化一個特殊反饋值的QCN幀，使用源MAC地址將該幀返根據QCN算法指定的動態信息更新隊列的采樣速率，通過擁塞通告可以一定程度上解決擁塞熱點的問題。然而在真實環境中很少實現，因為它會高度依賴擁塞點反應時間，通過網絡發送QCN幀的時間和反應點反應時間；并且它只能運行在二層網絡上，很難適應同時，如能解決設備支持的因素，將QCN與DCQCN結合實現一credit鏈路控制技術的一個有力補充，這都有待于進一步的研究和4．鏈路控制總結在鏈路控制層面，由于現有的RoCE協議中缺少了Infiniband協議中的信用機制，這一定程度上破壞了原有的雙環控制系統的完整性。用PFC替代細粒度的信用機制，在整個控制系統的角度看，可以認為是將一個內環控制系統置換成了一個非線性死區，這一定從實際的網絡角度意味著傳輸速率的調節，RoCE網絡相比Infiniband會更加的遲鈍。這個技術上的差距是不能通過調節DCQCN參數彌補的。因此，RDMA網絡在以太網上的應用更為重要的數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004技術突破要在鏈路控制的層面進行。但同時，鏈路層的改動需要對協議內容進行更深入的探討和精巧的設計，同時需要在硬件層面進源頭上，降低了擁塞發生的概率。本節按業ECMP全稱等價多路徑（Equal-costmulti-path），它是一種基于流的負載均衡路由策略。當路由器發現同一目的地址存在多條等價路徑時，路由器會依據相應算法將不同流量分布到不同的鏈路數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004ECMP是一種簡單的負載均衡策略，但在實際應用中存在許多問方法進行負載均衡，它無法感知到鏈路的擁塞情況。因此，在已經b)ECMP無法解決非對稱網絡的性能損失。當數據中心網絡發生故障時，網絡結構可能會出現非對稱情況導致無法實現網絡物理c)在流量大小分布均勻的情況下，ECMP效果較好。然而，在同時存在大流量和小流量的情況下，ECMP的效果并不理想。假設有一條大流量和一條小流量同時到達路由器，ECMP會將這兩條流量均勻題，限制了其在某些場景下的有效性。在解決這些問題的同時，可以考慮使用更復雜的負載均衡策略或結合其他技術來改善網絡性能老鼠流并存的環境中，需要仔細考慮環境的問題。盡管后續的研究（如Hedera[29]，BurstBalancer[30]）很多考慮了不同的數據流數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004量特征（大象流、burst等）。但是，ECMP由于其工程復雜度低、隨機包噴灑（RandomPacketSpraying，RPS）是一種基于包級別的負載均衡策略。當路由器發現有多條等價路徑指向同一目的地址時，RPS會將數據包以單個包為單位分散到這些路徑上。與ECMP不同，RPS以數據包為單位進行操作，而ECMP則是以流為單位RPS的優點在于簡單易實施，并且能夠充分利用網絡鏈路。在沒有突發流或流大小差異的情況下，RPS能夠避免網絡出現不均衡的情況，能夠實現更好的負載均衡并提高網絡性能。同時，RPS也有一些限制。由于數據包的隨機分布，可能會導致同一流中的數據RPS技術往往需要RDMA網卡在傳輸層支持亂序傳輸，這對于當前市場上已有的RNIC，是一個相對苛刻的硬件要求，這也導致了當流級別的太過粗糙，包級別的粒度太細。Flowlet作為一個折中方案，就成為了一個研究點。M.Alizadeh等人于2015年提出CONGA[31]，它是一種基于網絡的分布式擁塞感知負載平衡系統。其設數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004計目標是在不增加傳輸層復雜度的前提下，通過分布式方式實現全CONGA基于數據中心網絡的特點將流進一步細分為間隔粒度在微秒級別的小流(Flowlets)，負載均衡也針對每一個Flowlet的第一個包，之后每個Flowlet使用相同的鏈路。上行鏈路交換機鏈路擁塞狀況并交給收端交換機，保存一個來自各葉節點的擁塞狀況，并反饋給源端交換機。CONGA通過負載均衡提升了數據中心網絡傳輸性能進而提高吞吐量，但CONGA仍然需要網絡負載與實際容此外，這一領域的研究內容也逐漸細化，但整體上講，應用范4．負載均衡總結數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004流量調度技術不同于前述的幾項技術，它更多的是在給特定的SDN控制器整合拓撲發現模塊和流量監控模塊獲取全網視圖，再根據業務優先級、網絡狀態、服務器負載狀態等，用開放流協議(OpenFlow)下發流表規則到數據平面，協調網絡設備實現動態的流量調度。這可以按需分配網絡資源，繞過擁塞鏈路，根據業務需求分割帶寬，還可以按照負載將流量導向閑置服務器。流量調度提高數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004基于規則的流量調度技術在學術界討論的非常廣泛，例如，pFabric[32]，PDQ[33]，PIAS[34]，FastPass[35]，Homa[36]，AuTo[37]等。它們的研究方法通常是設定特優的規則來給不同的數據流進行優先級分類。例如，對較長的流，減少包丟棄；對時延敏感的流進行優先由于流量調度的研究較多且領域更加細化，與應用結合較多，但總體的研究思路是類似的。限于篇幅，此處以PIAS舉例說明。數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004PIAS借鑒了模擬最短作業（SJF）工作原理來最小化FCT。利用在這種隊列中，PIAS流會根據其發送字節數逐漸從高優先級隊列降級為低優先級隊列。因此，短流能在前幾個高優先級隊列中完成，問題的難點在于如何準確劃分包長閾值K，閾值不準確和優先級之間失匹配，都會導致性能損失。文中，作者雖然通過建模給出了如何準確計算閾值和解決失匹配問題，但是仍然需要很長的時間使模型收斂。同時，它的優先級匹配的過程，存在慢啟動的問題。即長流可能需要很長時間才能達到一個準確的優PIAS論文的研究工作中，我們可以看出基于規則的流量調度技術更多的是需要針對特定的網絡流量環境，通過精細的平衡各方面的tradeoff，實現某種邊界條件下的網絡性能最優化。這類工作在但是在更廣泛應用的云數據中心中，失去了流量特征的種種理想假設，這種敏感的規則平衡幾乎不可能達成。這也一定程度上限制了數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004流量調度本質上與交通、物流等領域的調度問題沒有區別，而實時調度在這些領域中有廣泛的應用。而網絡流量的調度技術中，結合反饋信息的實時調度研究相對較少。其根本原因在于，網絡環一些研究確實也引入了一些實時調度的思路，例如D2TCP[39]、D3[40]等基于完成時間的流調度技術。這類技術在整體上將原有的從但是，不管是D3還是D2TCP，使用的時間都是截止時間和已發送時間。這種本質上雖然也形成了回路，但系統的傳感器是本地時鐘，這種實時的反饋調度仍然是規則化的。如何利用更多的網內信流量調度相比于擁塞控制、鏈路控制、負載均衡，更接近用戶層，與業務耦合更緊密，能有效的優化特定業務場景下的業務服務質量。但是，由于其軟件調度的局限性，它很難完成快速的擁塞避同時，基于簡單規則的調度技術難以在復雜的流量環境下廣泛的應用，流量調度技術更明顯的在向實時調度的方向演進。隨著擁塞檢測技術的進步，更豐富的網絡實時信息將給流量調度技術帶來數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004更大的操作空間，也給流量調度技術在未來云數據中心的更廣泛應本章歸納了高性能網絡中，用于處理和緩解擁塞的技術體系，主要包括擁塞控制和鏈路控制組成的擁塞控制技術，負載均衡和流量調度組成的擁塞管理技術。擁塞管理和控制的技術體系，目前仍然是高性能網絡的核心，將更為合適擁塞檢測技術更為廣泛的集成同時，在本章中，討論了各項技術與擁塞檢測技術已有以及潛在的結合點。總體上看，擁塞檢測在硬件實現更多、響應速度更快的擁塞控制協議、鏈路控制協議中應用更加廣泛。但隨著網絡觀測技術的進步，在負載均衡、流量調度技術方向上，也有較大的潛在數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004擁塞檢測技術本身的出現早于高性能網絡，ECN、RTT、INT等擁塞測量的方案在傳統的TCP網絡中就已經被廣泛探討[14],[41],[42]，在高性能網絡的擁塞管理與控制技術體系中，存在一個直觀規律。以擁塞控制協議為例，不同的擁塞控制協議往往對應不同擁塞由此可見，擁塞檢測在擁塞控制方案中是決定性的。各種不同協議中控制器的算法之所以存在區別，歸根結底是擁塞檢測的實現方案區別。例如，DCQCN中使用CNP報文的事件驅動型控制，其算法設計上采用AIMD來進行逐拍的控制；TIMELY使用RTT作為擁塞信息，其算法則可以使用PID進行線性控制。擁塞檢測方案是整個同時，在之前的研究工作中，擁塞控制的設計缺乏系統性的思考，檢測環節、處理環節、控制環節通常沒有細分的設計。這也導致了控制算法設計上很多與檢測環節強耦合，工程實現上缺乏通用因此，本章對當前的擁塞檢測技術進行系統的歸納，主要以擁塞檢測的主體為分類依據，以交換機、網卡、端網協同三個類別，數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004在高性能網絡中，交換機是擁塞發生最為頻繁的設備節點。因此，交換機設備的擁塞檢測結果，往往代表了整條傳輸鏈路中最大顯式擁塞通知[43],[44]（ExplicitCongestionNotification，ECN）是對Internet協議和傳輸控制協議（TCP）的擴展，定義在RFC3168（2001）中。ECN允許在不丟棄數據包的情況下，通知網絡擁塞的發生。ECN在以太網中是一個可選的功能，在底層網絡基路由器在Internet層運作，而傳輸速率由傳輸層的端可能僅由發送器處理，但由于只有在發送了一個數據包之后才知道發生了擁塞，因此接收器必須將擁塞指示回傳給發送器。在沒有（CongestionExperienced）來指示，并通過接收器在傳輸協議的ECN廣泛的應用于以太網絡，因此在RoCE高性能網絡協議中，ECN作為擁塞檢測方案存在廣泛硬件基礎。事實上，應用廣泛的數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004DCQCN和DCTCP協議都使用了ECN作為其擁塞檢測方案，其參數設ECN在使用的過程中存在不同的標記算法區別，以下給出了典ECN在使用的過程中，通常與RED功能結合使用。RED是由SallyFloyd和VanJacobson在1990年代初發明的交換機隊列管理機制[45]。RED會監控平均隊列大小，并根據統計概率丟棄（或在數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004隨機早期檢測（RandomEarlyDetection，RED）是一種適用于在傳統的尾部丟棄算法中，路由器或其他網絡組件緩存盡可能多的數據包，并簡單地丟棄無法緩存的數據包。如果緩沖區不斷滿載，表示網絡擁塞。尾部丟棄不公平地分配緩沖區空間給各個流量流。尾部丟棄還可能導致TCP全局同步，因RED通過在緩沖區完全滿載之前預先丟棄數據包來解決這些問則接受所有傳入的數據包。隨著隊列的增長，丟棄傳入數據包的概率也會增加。當緩沖區已滿時，概率達到1，所有傳入的數據包都數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004RED后續結合QoS等信息，進一步衍生出了WRED（WeightedRED是一種依賴隊列長度的標記算法。根據排隊論中的著名結果，只有當數據包的到達時間服從泊松分布時，隊列長度才直接與活動源的數量和真正的擁塞水平相關。不幸的是，在網絡鏈路上，Blue[46]是一種網絡調度器的調度策略，由密歇根大學的研究生 馮武昌（Wu-changFeng）為KangG.Shin教授以Blue使用了數據包丟失和鏈路利用率歷史來管理擁塞。通過維護一個單一的概率，用于在數據包排隊時標記（或丟棄）數據包。如果由于緩沖區溢出而導致隊列持續丟包，Blue會增加標記概率，從而增加發送擁塞通知的速率。相反地，如果隊列變為空或鏈路處于空閑狀態，BLUE會減小其標記概率。BLUE相對于RE基于Blue的機制，還提出并評估了一種新的機制，用當前的交換機中普遍使用RED與ECN結合，通過RED標記機制生成ECN標記。但隨之Lossy逐漸在主流RoCE網卡中普及，40數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004來的高性能網絡，Blue以及近年來的一些其他主動隊列管理的方法在文獻[20]中，意識到了擁塞檢測對于整個系統的重要作用。該論文的觀點中，ECN檢測給出的結果是具有ON-OFF特性的，而這種ON-OFF發送模式可能對交換機中的擁塞檢測行為產生意外影響，包括引起隊列積壓并影響暫停端口的實際輸入以此為啟發，該論文中提出了一種三元擁塞檢測技術來實現RDMA網絡的擁塞檢測。它將網絡設備的端口狀態不再用0-1標記，而是區分成三種狀態，擁塞、非擁塞和不確定。這三個狀態用上圖盡管TCD意識到了擁塞檢測對于高性能網絡擁塞的關鍵作用，但其工作仍然是受限于狀態的轉移。本質上講，TCD是通過擴展ECN41數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004標記的數據位寬實現更準確的擁塞檢測。相比于其三元狀態的轉移邏輯的設計，該研究工作中體現出的高位寬帶來搞檢測精度最終帶（a）BCN系統模型（b）FECN系統模型義的其他的擁塞通知協議如BackwardCongestionNotification（BCN）[47]，ForwardExplicitCongestionNotification[48]，Pre-CongestionNotification[49]等，在21世紀初的IEEE8作組中都有廣泛的討論。這些擁塞檢測技術同交換機和斷網協同完成擁塞檢測，往往意味著需要特定的交換機支持。由于大規模的云廠商對于設備的供應鏈、兼容性、規范性都有苛刻的要求，專屬定制的交換機對于大多數云服務提供商來說是難以接受的。因此，不依賴交換機，在端側通過云廠商自研的42數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004DPU、網卡就能獨立完成擁塞檢測的方案，對于云數據中心也具有很RTT（RoundTripTIme）是數據包傳輸的往返時間，在應用于RDMA高性能網絡之前，就被廣泛的應用于TCP網絡協議的傳輸控制使用RTT進行擁塞檢測遵循一個樸素的哲學，即發生擁塞的鏈路中數據包的傳輸時延增大。當網卡實測的RTT與端到端正常的在ECN方案中，具有不同優先級的多個隊列共享同一個輸出鏈路，但ECN標記僅提供了超過閾值的隊列的信息。低優先級的流量可能會經歷較大的排隊延遲，而不一定會積累大量的隊列。此外，ECN標記描述了單個交換機上的行為。在高度利用的網絡中，擁塞43數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004相比于ECN，RTT積累了關于端到端路徑的信息，包括可能出現擁塞的網絡接口卡（NIC）。RTT提供的信息是一個更為精煉、聚合了端到端擁塞的最終量化指標，從這個角度講，RTT是更為直接的但是，文獻[21]也對RTT和ECN方法進行了客觀的對比，RTT測量還是會存在對時鐘抖動敏感等問題。同時，使用RTT測量的TIMELY的算法也存在設計上的問題，導致同期提出的RTT方案相比但是，RTT相比與ECN，在測量的角度仍有其優勢。在解決了控制器設計的問題后，其方案簡單、測量精度高、端到端、設備依賴文獻[52]中提出了一種使用不同優先級隊列消息，實現擁塞檢測的技術方案。該方案中，使用商用交換機中可用的基本特性（優先級隊列），無需對交換機進行修改或在主機上實施任何復雜的算法。它使用了Scout服務技術，Scout服務基于一個簡單而有效的44數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004當高優先級隊列（HPQ）變得更加繁忙（鏈路利用率更高）時，測量LPQ隊列中的消息的RTT時延，觀察到鏈路的狀態，并且，這一檢測可以在觀察到HPQ建立之前幾個RTT檢測到擁塞，相比于傳交換機雖然通常是鏈路中擁塞的瓶頸點，但單獨使用交換機完成的擁塞檢測，不能對網卡的擁塞程度有直接的測量。因此，一些研究工作中提出，要使用端網協同的擁塞檢測方案來實現全鏈路的45數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004當前，交換機在數據平面上變得更加開放和靈活。其中，網絡內部遙測（In-NetworkTelemetry，INT）正在迅速普及。我們所了解的幾乎所有交換機供應商都已經在其新產品中啟用了INT功能），通過INT，發送者可以通過ACK數據包準確了解流經路徑上鏈路的負載情況，從而便于發送者進行準確的流量調整。例如，在如圖所示的HPCC擁塞控制協議中，阿里云的研究人員通過自定義了擁塞檢測的INT報文，準確的獲取了鏈路中網絡設備的隊列長度、時但INT帶來檢測精度提升是通過增加包問頭的形式完成的，這就造成了一定的帶寬浪費。如何平衡INT帶來的檢測精度提升和造成的overhead，成為了使用HPCC不得不考慮的一個問題。后續的而是給精度和overhead這一組tradeoff提供了一個歸一化的調節ECN已經在生產數據中心廣泛使用，以提供高吞吐量和低延遲的通信。盡管取得了成功，但之前基于ECN的傳輸機制存在一個重46數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004然而，在數據中心中往返時間（RTT）的變化很常見，因為不同的流量通過不同的處理組件，例如網絡堆棧、虛擬化管理程序和中間件。與服務內部的流量相比，服務之間的流量經歷了來自第四層負載均衡器的額外處理延遲。此外，給定組件的處理延遲也會根據工作負載的不同而變化。據研究顯示，這一波動往往會達到3倍以文獻[50]中提出了ECN#，它基于瞬時和持續的擁塞狀態對數據當存在大的瞬時隊列時，ECN#會主動標記數據包以避免緩沖區ECN#是對ECN標記的一個補充，它結合了網卡側的RTT信息，使ECN標記的閾值設置成動態的。根據文獻[50]中的評估，ECN#對于短流的平均流完成時間（FCT）可以降低高達23.4%），47數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004種旨在提高網絡的性能和可靠性，避免網絡擁塞引起的數據丟失、延遲和抖動等問題的擁塞檢測技術。ConEx通過在數據包頭部添加擁塞信息，向網絡設備和終端設備傳遞擁塞信息，從而調整數據傳在網絡中的特定測量點，“剩余路徑擁塞”（也稱為“下行擁塞”）是一個流預計在測量點和其最終目標之間經歷的擁塞水平。如果網絡中的流量支持ECN（顯式擁塞通知），則路由器可以在中間節點監測ECN信號，并根據該信號量測上行擁塞情況。與之不同的是，ConEx信號將插入IP頭中，從源端到目的端包含了整個網絡路徑中的擁塞情況。因此，如果監測點檢測到這兩個信號，它48數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004可以通過將ConEx的路徑擁塞情況減去ECN的上行擁塞情況，計算出數據包在監測點和目標之間可能遇到的擁塞情況，也就是剩余路剩余路徑擁塞檢測無疑是當前ECN檢測方案的一個有力補充，它更本章歸納了高性能網絡中，擁塞檢測相關的技術，以網側、端側、端網協同為依據，將現有的擁塞檢測技術及其典型應用進行了簡單的歸納。不同的擁塞檢測機制存在明顯的優缺點，這決定了其同時，在本章中討論了各項擁塞檢測技術設計的本質。總體上看，當前的擁塞檢測機制設計上，檢測、處理、控制多個環節緊耦合的現狀下，擁塞檢測機制難以標準化、模塊化。需要在后續的數49數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004隨著未來數字經濟發展，算力網絡宏觀戰略日益落實，東數西算、大模型等新興應用場景與算力需求形成了交替驅動的螺旋上升未來數據中心網絡隨著云計算的發展將占據更多的市場份額，這都而在這一新的機遇期，RoCE網絡由于其開放兼容的優勢，毫無首先，本白皮書中就高性能網絡的背景和現狀進行了研究，總結了當前數據中心中分布式存儲、內存池化、鍵值存儲、智能算力等場景下高性能網絡的應用情況，并分析了高性能網絡中的擁塞問題。然后，本白皮書進一步總結歸納了高性能網絡的擁塞管理控制技術體系。從網絡層、傳輸層、鏈路層逐級分解，對已有的擁塞管理控制技術體系進行了深度的剖析。本白皮書中，以網側驅動、端側驅動、端網協同為劃分依據，對現有的擁塞檢測技術進行了細致的分類，同時深入討論了不同擁塞檢測技術方案設計的優缺點，探討了不同方案的本質特點，對工業部署廣泛、學術影響深遠的技術模塊化的高性能網絡擁塞檢測技術落地，提供一些理數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-030041、檢測效果與資源占用不可兼得的矛盾。提高檢測的精度和頻率通常需要增加系統的復雜度和提高資源的占用，如何權衡方案的損失收益，目前沒有明確的評價規范。例如，INT帶來的擁塞控制方案中，檢測、處理、控制三個環節往往通過一個整體來設計，這也導致離開整體系統的特定硬件，檢測環節難以獨立工作。這需要塞控制協議中，構建閉環的控制系統。閉環控制系統能夠有效的抵御外部擾動，這對于高性能網絡在復雜的云場景應用有重要意義。總的來說，高性能網絡擁塞管理與控制的技術體系目前越發清晰。作為其中的基石技術，擁塞檢測技術在各種技術方案中具有核心影響。而未來，擁塞檢測技術是整個擁塞管理控制技術體系的基石，其關鍵的系統化、標準化、模塊化工作，將成為高性能網絡進數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004SymposiumonNetworkedSystemsDesignandImplementation(NSDI21),2021,networksinAlibabacloud,”inProceedingsoftheACMSIGCOMM2022Conference,AmsterdamNetherlands:ACM,Aug.2022,pp.753–766.doi:USENIXSymposiumonOperatingSystemsDesignandImplementation(OSDIAvailable:/conference/osdi16/technical-ExtendibleHashingforDisaggregatedMMemory,”inProceedingsofthe11thUSENIXConferenceonNetworkedSystemsDesignandImplementation,inNSDI’14.USA:USEusingRemoteLearnedCacheCaching,”inProceedingsofthe26thSymposiumonOperatingSystems[9]“5_最佳實踐-使用SMC和ERI透明加速Redis應用-OpenAnolis代碼庫.”/sig/high-perf-network/doc/735934915657Aug.24,2023).數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004ProtocolforElasticandNetworks,”inProceedingsofthe13thInternationalConferenceonemergingNetworkingEXperimentsandTechnologies,IncheonRepublicofKorea:ACM,Proceedingsofthe2015ACMConferenceonSpecialInterestGrouponDataCommunication,LondonUnitedKingdom:ACM,Aug.2015,pp.523–536.do[14]M.Alizadehetal.,“DataCenterTCP(DCTCP),”inProceediSIGCOMM2010ConfeAssociationfor[15]R.Mittaletal.,“TIMELY:RTT-basedCongesinProceedingsofthe2015ACMConferenceonSpecialInterestGrouponDataCommunication,LondonUnitedKingdom:ACM,Aug.2015,p[16]Y.Lietal.,“HPCC:higACMSpecialInterestGrouponDataCommunication,BeijingChina:ACM,ECNtuningforhigh-speeddatacenternetworks,”inProceedingsofthe2021ACMSIGCOMM2021Conference,VirtualEventUSA:ACM,Aug.2021,pp.Large-ScaleIncastCongestioninRDMAoverEthernetNetworks,”IEEE26thInternationalConferenceonNetworkProtocols(ICNP),Cambridge:數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004[19]R.Mittaletal.,“RevisitingnetworksupportforRDMA,”2018ConferenceoftheACMSpecialInterestGrouponDataCommunication,BudapestHungary:ACM,Au[20]Y.Zhang,Y.networks,”inProceedingsofthe2021ACMSIGCOMM2021Conference,VirtualEventUSA:ACM,Aug.fromAnalysisofDCQCNandTIMELY,”inProceedingsofthe12thInternationalonConferenceonemergingNetworkingEXperimentsandTechnologies,IrvineCaliforniaUSA:ACM,Dec.2016,pp.313–327.doi:theDatacenter,”inProceedingsoftheAnnualconferenceoftheACMSpecialInterestGrouponDataCommunicationontheapplications,technolarchitectures,andprotocolsforcomputercommunication,VirtualEventUSA:RTTforDatacenterTransport,”inProceedingsoftheFirstAsia-PacificWorkshoponNetworking,HongKongChina:ACM,Aug.2017,pp.36–42.doi:“PINT:ProbabilisticIn-bandNetworkTelemetry,”inProceedingsoftheAnnualconferenceoftheACMSpecialInterestGrouponDataCommunicationontheapplications,technologies,architectures,andprotocolsforcomputer“RoCC:robustcongestioncontrolforRDMA,”inProceedingsofthe16th數據中心高性能網絡擁塞檢測技術白皮書（2023年）ODCC-2023-03004InternationalConferenceonemergingNetworkingEXperimentsandAccurateCongestionFeedbackforRDMACongestionControlINFOCOM2022-IEEEConferenceUnitedKingdom:IEEE,May2022,pp.2228–2237[27]J.Zhangetal.,“Receiver-DrivenRDMACoCongestionTypesinDatacenterNetworks,”in2021IEEE29tConferenceonNetworkProtocols(ICNP),Dallas,TX,U(accessedSep.03,20[29]M.