DCQCN
3 秒看懂
DCQCN(資料中心量化擁塞通知)是用於高速資料中心網路(尤其是 RDMA 融合乙太網路 RoCEv2 )的擁塞控制演算法。當網路裝置佇列發生堆積時,它通過標記資料包(ECN)並讓接收端返回擁塞通知包(CNP),告知傳送端分階段降速(量化調節)。這是當前 AI 叢集中 RoCEv2 無損網路事實上的標配演算法,但它本質是“事後響應”——在萬卡叢集突發流量下,其 RTT 級別的反饋延遲已成為瓶頸。
3 分鐘產業解釋
在 AI 訓練叢集中,成千上萬個 GPU 通過高效能網路互聯。這些網路通常使用**融合乙太網路(RoCEv2)**承載遠端直接記憶體訪問(RDMA)流量,要求接近零丟包——傳統 TCP 丟包重傳帶來的毫秒級抖動,會把 GPU 昂貴的算力變成空閒等待。
DCQCN 解決了這個問題:它在交換器側檢測佇列長度,當超過門限時,對資料包的 IP 頭部打上 ECN 擁塞標記(而不是直接丟棄);接收端看到標記後,生成一個 CNP 擁塞通知包回傳傳送端;傳送端根據 CNP 的速率,以多個量化檔位降低注入速率,擁塞緩解後再逐步恢復。
這套機制讓 RoCEv2 幾乎消除了因緩衝區溢位導致的丟包,使“乙太網路做 RDMA”成為現實,支撐了當前大部分 GPU 叢集的互聯。但它在萬卡級 All-to-All 通訊中的滯後性,正驅動業界向更主動的排程機制演進。
15 分鐘專家深入
DCQCN 是一套完整的接收端驅動的量化速率調節體系,融合了三層機制:
- 擁塞檢測(交換器):維護出口佇列的即時長度,當超過預設的水線閾值(Kmin/Kmax)時,對經過的資料包 IP 頭部設定 **CE(Congestion Experienced)**標記(ECT 位從
01/10翻轉為11)。標記機率與佇列深度正相關,遵循類似 RED(Random Early Detection)的機率函式。 - 擁塞訊號傳遞(接收端):接收到的資料包若攜帶 CE 標記,接收端網絡卡協議棧觸發生成一個 CNP 包,立即發回給傳送端。CNP 包含被標記流的五元組資訊,使傳送端能精準定位需降速的流量。
- 速率調節(傳送端):傳送端收到 CNP 後,將當前傳送速率乘以一個小於 1 的係數 α(如 0.5~0.9),降速到一個量化檔位。若持續收到 CNP,則繼續下探;若在一個計時週期內未收到 CNP,則按位元組計數或計時器觸發速率恢復,以“快恢復”函式拉昇速率,典型過程類似加法增加/乘法減小(AIMD)但速率級別是離散的。
該演算法的設計充分考慮了硬體解除安裝實現:網絡卡晶片中可固化狀態機,將標記檢測、CNP 生成與注入速率調節全部做到硬體資料路徑上,實現微秒級響應,釋放 CPU 資源。但這套“被動閉環”在單次 RTT 內,交換器緩衝區可能已經承受了上百微秒的持續衝擊。
技術原理
擁塞標記與訊號迴環(核心機制)
DCQCN 是“ECN + CNP 反饋”構成的閉環。工作流程如下:
[傳送端] [交換器] [接收端]
| | |
|------ 資料包(ECT=10) --->| |
| | (佇列深度 > Kmin) |
| | 將 ECT 改為 CE(11) |
| |------ 資料包(CE) -------->|
| | | (檢測 CE)
|<---------------------------- CNP 包(擁塞通知) ------|
| | |
| (削減傳送速率) | |
| (乘法降檔,進入量化速率級) | |
| | |速率調節的量化狀態機
傳送端維護一個可配置的速率級別表,通常為 816 個離散速率檔位。收到 CNP 後,速率跳變到當前檔位乘以 α 對應的檔位(非連續可調,而是向下跳躍 1N 級)。恢復側採用位元組計數器(Byte Counter)或定時器(Timer)機制:每當無 CNP 時成功傳送 B 個位元組或經過 T 時間後,速率向上提升一級。這種離散化設計的初衷是簡化硬體狀態機、保證確定性的行為邊界。
關鍵引數空間(設計權衡)
| 引數 | 含義 | 典型取值參考(行業綜述) |
|---|---|---|
| Kmin/Kmax | 交換器 ECN 標記的佇列長度閾值 | Kmin 常取幾十 KB,Kmax 數百 KB[行業報告] |
| Pmax | 最大標記機率(Kmax 處) | 常設為 1.0(100% 標記) |
| α | CNP 觸發的速率衰減係數 | 0.5~0.95,可配置[行業實踐] |
| R_AI | 恢復階段加法增加步長 | 每無 CNP 週期,速率增加固定量 |
| T_byte / T_timer | 無 CNP 條件下的速率上調觸發條件 | 位元組數/時間週期,取決於鏈路速率與 RTT |
在乙太網路協議棧中的位置
與經典的 TCP/IP ECN 機制不同,DCQCN 不修改 TCP 頭部,而依賴 IP 頭部 ECN 位 承載擁塞標記(TCP 頭部不參與承載 CE)。CNP 本身是 RoCEv2 傳輸層生成的控制報文,擁有獨立的乙太網路型別(Ethertype)和 RoCE 操作碼,在網絡卡中享有最高發送優先順序,確保不因擁塞而被阻塞。
技術演進史
- 1999-2001 年 ECN 確立(RFC 3168):TCP/IP 協議族引入顯式擁塞通知,允許路由器標記而不丟棄資料包,但延遲觸發機制和速率調節仍由 TCP 慢啟動/AIMD 控制,響應在數十毫秒級。
- 2010 年代 RDMA over Converged Ethernet(RoCE)興起:資料中心要求 RDMA 的低延遲,需要網路近乎零丟包。單純依賴 PFC(優先順序流控)易引發擁塞擴散和死鎖,亟需端到端擁塞控制。
- 2015-2016 年 DCQCN 提出:微軟與 Mellanox(現 NVIDIA Networking)聯合提出基於 ECN 的量化擁塞通知機制,配合 PFC 建置“端到端+逐跳”兩級流控體系,成為 RoCEv2 標配。
- 2020 年代規模化挑戰:隨著 GPU 叢集規模從千卡到萬卡躍升,DCQCN 的 RTT 級延遲在 All-to-All 突發下導致交換器緩衝區溢位事件增加,業界開始探索主動准入(C-AQM)、信用排程等替代方案1。
- 當前前沿方向(2025 前後):根據學術論文和產業實踐,引入“提議-准入”(Propose-and-Admit)機制的主動擁塞管理正成為研究熱點,通過在傳輸層報頭攜帶速率提議位,讓網路裝置提前做出許可或拒絕,加速響應1。
技術路線對比
| 維度 | DCQCN(EERP-based) | PFC(優先順序流控) | TCP ECN + DCTCP | 主動准入方案(C-AQM) |
|---|---|---|---|---|
| 控制層級 | 端到端擁塞控制 | 逐跳鏈路級反壓 | 端到端擁塞控制 | 端到端准入控制 |
| 訊號機制 | 交換器標記→接收端 CNP→傳送端降速 | XOFF 暫停幀直接中斷上游傳送 | 交換器標記→接收端在 ACK 中回傳 ECE | 傳送端攜帶速率提議,交換器許可/拒絕 |
| 響應延遲 | RTT 級(10~100μs) | 鏈路 RTT(數百 ns~數 μs) | RTT 級,疊加軟體處理增加延遲 | RTT 級(但提前預防) |
| 粒度 | 單流(QP 級) | 埠/優先順序 | 單流 | 單流/聚合 |
| 主要弊端 | 滯後性,緩衝區溢位風險 | 擁塞擴散、死鎖風險高 | 依賴 TCP 協議棧,延遲較大 | 協議複雜,需全網升級支援 |
| 硬體依賴 | 網絡卡硬體實現 ECN 檢測/CNP 生成 | 交換器/網絡卡 PFC 模組 | 標準 TCP/IP 棧 | 網絡卡+交換器需支援新傳輸層控制位 |
DCQCN 與 PFC 形成互補:DCQCN 處理長期、寬頻擁塞,PFC 作為“最後一米”的緊急剎車,防止極端場景下緩衝區瞬時溢位。在合理調優下,兩者配合能使 RoCEv2 丟包率降至極低水平。
上下游
上游依賴:
- 交換器 ASIC(晶片):需在資料路徑中實現 ECN 標記引擎,支援基於佇列深度 ECN 水線配置。主流資料中心交換器晶片(Broadcom Tomahawk 系列、NVIDIA Spectrum 系列等)已硬體支援。
- 網絡卡(NIC/DPU):需要硬體完成 CNP 生成、ECN 檢測、速率狀態機執行。NVIDIA ConnectX 系列、Intel E810 系列等均內建 DCQCN 硬體加速。
- 網路作業系統(NOS)與協議棧:SONiC、Arista EOS、Cumulus Linux 等提供 DCQCN 引數調優介面(ECN 閾值、CNP 優先順序對映等)。
下游應用場景:
- 分散式 AI 訓練:GPU 之間 AllReduce 集合通訊的全程 RDMA 寫入,對 DCQCN 依賴極重。
- 分散式儲存:NVMe-oF(NVMe over Fabrics)的 RDMA 資料傳輸,要求低延遲和高頻寬下的無損傳輸。
- 高效能運算(HPC):RoCEv2 在 HPC 叢集的 MPI 通訊中廣泛使用,DCQCN 保障訊息傳遞庫的無丟包執行。
關鍵指標
- CNP 處理延遲(網絡卡) :接收端檢測到 CE 標記至 CNP 包發出的時間間隔。硬體解除安裝下通常 <1μs。
- 收斂速度:從全速率發生擁塞到所有參與流收斂至公平份額所需的時間,受 RTT、流數量、α 和恢復引數共同影響,數十至數百 μs 量級。
- 佇列深度峰值:在收斂過程中交換器緩衝區經歷的最大佇列長度,直接關係到是否需要觸發 PFC。合理的 Kmin/Kmax 與 α 取值可使其控制在配置範圍內。
- 公平性指數(Jain’s Fairness Index) :多流競爭瓶頸鍊路時頻寬分配的均等程度,良好調優下可達 >0.95[行業測試估計]。
- 利用率凹陷(Bandwidth Under-utilization) :過度激進降速導致鏈路在擁塞後出現短暫空閒,影響整體吞吐。在引數配置激進時顯著,通常通過精細恢復策略緩解。
供需與市場資料
DCQCN 作為演算法機制而非獨立產品,其“市場”體現為支援 RoCEv2 無損乙太網路的裝置滲透率:
- 網絡卡側:NVIDIA ConnectX-6/7 系列、Intel E810 等主流 RDMA 網絡卡均已內建硬體 DCQCN 支援,在 GPU 叢集中隨算力卡出貨。
- 交換器側:2023 年後,資料中心 25/100/200/400GbE 交換器新品幾乎標配 ECN 標記與 DCQCN 相關的水線配置介面,已經是標準功能而非差異化賣點[行業報告定性表述]。
- 部署驅動力:AI 叢集建設大規模採用 RoCEv2 作為東西向互聯,DCQCN 作為必備元件被整合。以萬卡 GPU 叢集為例,其葉脊(Leaf-Spine)網路裝置全量執行 DCQCN + PFC。
隨著叢集規模擴大和 Ultra Ethernet Consortium(UEC)等新標準推動,DCQCN 引數調優的複雜度和極限效能約束正被重新審視,這催生了更主動的擁塞管理需求的增長。
代表公司與資本對映
| 公司 | 角色與對映 | 邏輯 |
|---|---|---|
| NVIDIA(Mellanox) | DCQCN 共同提出者,ConnectX 網絡卡與 Spectrum 交換器核心供應商 | 提供端到端硬體解除安裝實現,是 DCQCN 生態的基石 |
| Intel | 至強平台+NIC(E810 系列)的 RoCEv2 方案支援 DCQCN | 在企業級和部分雲端場景推廣 RDMA 無損網路 |
| Broadcom | 資料中心交換器晶片(如 Tomahawk 5)硬體支援 ECN 標記引擎 | 交換器晶片在 DCQCN 路徑上執行標記邏輯 |
| Arista / Cisco | 資料中心交換器廠商,提供 ECN 配置、PFC 與 DCQCN 聯合調優網路OS | 將 DCQCN 引數暴露給使用者,提供調優參考 |
| 華為 | 推出 UB(統一匯流排)等自研擁塞控制機制,明確提出 DCQCN 的滯後性問題 | 對 DCQCN 替代方案的投入,折射主動擁塞管理的產業趨勢1 |
| 雲端廠商(AWS/Meta/Azure) | 大規模 RoCEv2 網路運營者,內部深度定製 DCQCN 引數 | 對演算法最佳化和規模挑戰的理解推動行業實踐 |
投資邏輯
- 短期確定性:DCQCN 是現有 GPU 叢集網路的預設選擇。投資 NVIDIA(交換器+網絡卡)、Arista(交換器)等,相當於押注 AI 算力互聯基礎設施的持續擴容,DCQCN 是其中必需的元件。
- 中期變數:DCQCN 的滯後性在萬卡以上叢集已成為瓶頸。如果出現協議替代方案(如 UEC 定義的傳輸層新規範、C-AQM 等),早期 DCQCN 生態圈的鎖定效應可能被打破,新的晶片/交換器方案可能獲得份額。
- 觀察指標:① 主流網絡卡/交換器晶片供應商下一代產品的擁塞控制特性路線圖;② Ultra Ethernet Consortium 成員的實際落地進展;③ 頭部雲端廠商自研協議(如 Google Falcon 類方案)是否開放生態。
- 風險提示:DCQCN 本身是公開演算法,無專利壁壘,技術護城河體現在“硬體解除安裝實現的穩定性和極端規模的經驗調優”上。單純押注演算法可實現性無意義,真正稀缺的是大規模叢集中調優經驗和端到端驗證能力。
常見誤讀糾偏
誤讀 1:“DCQCN 可以替代 PFC。” 糾偏:DCQCN 和 PFC 是兩個層次的控制——DCQCN 是端到端的擁塞控制,響應時間是 RTT 級;PFC 是逐跳的鏈路級反壓,響應時間是鏈路延遲級。DCQCN 無法防止極端突發在第一輪 RTT 內引起的瞬時溢位,必須依賴 PFC 作為最後一層保護。二者是“協作”而非“替代”關係。缺失 PFC 會導致丟包;缺失 DCQCN 則 PFC 會頻繁觸發,造成擁塞擴散和吞吐坍塌。
誤讀 2:“DCQCN 讓傳送方從接收方獲取網路擁塞資訊,因此是主動的。” 糾偏:從本質講,DCQCN 仍是被動響應機制。它依賴於交換器佇列已經發生堆積才能打標,而不是在擁塞發生前預先調節。當前沿研究已在探索“主動准入”(Propose-and-Admit),即傳送方在加速前徵求路徑同意,這才是真正的主動1。DCQCN 的被動特性在數十微秒內造成緩衝區壓力,是其規模性瓶頸的根本原因。
學習路徑
- 基礎準備(2-3 天):理解 TCP/IP 擁塞控制基礎—慢啟動、擁塞避免、AIMD、ECN(RFC 3168)。推薦《TCP/IP Illustrated》卷 1 相關章節。
- RoCEv2 入門(1 周):學習 RDMA 基本原理和 RoCEv2 協議棧,掌握 QP(佇列對)、RC(可靠連線)模式、傳輸層包封裝。閱讀 InfiniBand Trade Association(IBTA)RoCEv2 規範中的擁塞管理章節。
- DCQCN 論文精讀(2 天):閱讀微軟與 Mellanox 的 DCQCN 原始論文《Congestion Control for Large-Scale RDMA Deployments》(SIGCOMM 2015 近似時期發表),重點理解量化速率狀態機、ECN 水線與 CNP 回傳機制。
- 產業實踐觀察(持續):關注 NVIDIA 的 RoCEv2 配置指南、SONiC 社群對 DCQCN 引數的討論、各大雲端廠商(E.g., Meta, Azure)的網路技術博文,瞭解大規模調優經驗與痛點。
- 前沿追蹤:閱讀 arXiv 上關於資料中心擁塞控制的最新論文(如 2511.04639 等),瞭解主動隔離、C-AQM 等對 DCQCN 的改進路徑15。
一句話總結
DCQCN 是使 RoCEv2 無損乙太網路成為可能的被動量化擁塞控制演算法,通過 ECN 標記與 CNP 迴環實現端到端速率調節。它支撐了當前 AI 訓練的互聯底座,但其 RTT 級滯後性在萬卡以上叢集正逼近物理極限,成為下一代主動擁塞管理技術研發的直接驅動力。
延伸閱讀與來源
- 華為 UB 擁塞控制、死鎖預防與重傳機制實現細節淺析(CSDN,2024),詳細對比 UB 的 C-AQM 主動准入與 DCQCN 的被動滯後機制。1
- ECN 顯式擁塞通知工作原理詳解(SPOTO,2026),闡述 IP 頭部 ECT/CE 位翻轉的精確過程。23
- arXiv:2511.04639 - Improving dynamic congestion isolation in data-center networks,討論 DCQCN 在動態擁塞隔離中的侷限性。5
- InfiniBand Trade Association, Annex A17: RoCEv2 Congestion Management,標準規範中關於 CNP 包格式與生成規則的權威定義。
- 原版 DCQCN 論文: Y. Zhu, et al., “Congestion Control for Large-Scale RDMA Deployments,” in Proc. ACM SIGCOMM, 2015. (詳細資訊應通過學術資料庫獲取)
- 各網絡卡供應商技術手冊(NVIDIA ConnectX 系列、Intel E810),提供 DCQCN 暫存器/引數配置的具體定義。