HPCC: High Precision Congestion Control 論文閱讀
摘要部分和簡介
- CC(擁塞控制, 以下都用CC表示)的目標：低延遲，高頻寬，網路穩定。但是現有的CC演算法在大規模高速RDMA網路上實現這些目標具有潛在限制。
- 提出HPCC，利用網路內遙測(INT, in-Network teletry)來獲得 (1) 精確的鏈路負載資訊 (2) 精確控制交通
- 針對面臨延遲INT資訊以及對INT過度反應的挑戰，HPCC可以快速收斂以利用限制頻寬，維護很短的網路佇列。並且容易在硬體上進行部署。
- 相較於DCQCN和TIMELY， HPCC大幅縮短了流完成時間。
簡介
-
三個目標：低時延，高頻寬，網路穩定。
-
基於RoCE2協議部署的RDMA網路仍然無法達到上述三個目標，主要是因為會遇到以下困難：
- PFC（優先流控制風暴）。
- incast 事件：分散式系統或資料中心網路中，多個傳送者同時向一個接收者傳送大量資料的情況。這種通訊模式被稱為many-to-one（多對一），在雲端計算應用中非常常見，尤其是在分散式儲存和計算應用中，例如Hadoop、MapReduce和HDFS等。
- PFC暫停幀：Priority Flow Control (PFC) 是一種基於優先順序的流量控制機制，它允許網路裝置在擁塞時只暫停特定優先順序的流量。PFC的工作原理是將網路流量分為不同的優先順序，每個優先順序都有自己的佇列。當某個優先順序的佇列長度超過預設的閾值時，下游裝置會向上遊裝置傳送一個 PFC Pause 幀，要求上游裝置暫停傳送該優先順序的流量。這樣，只有擁塞優先順序的流量被暫停，而其他優先順序的流量可以繼續傳輸，從而避免了整個鏈路的流量被暫停，提高了網路的效率。
- 在大流量的網路中，incast事件會導致長期的pfc風暴。因此我們需要調整擁塞演算法來減少風險（限制和避免pfc暫停）。但是這樣會導致鏈路利用率過低。
- 長時間延遲。由於一個雲端儲存系統導致的入網佇列過長，影響到了不對頻寬有很大要求的應用，導致時延過長。
- PFC（優先流控制風暴）。
-
需要一個好的擁塞演算法以避免pfc和包重傳以增加穩定性和減少損失。現有的DCQCN和TIMELY都具有以下三個問題：
- 過低的收斂速度。
- 無法避免的包佇列導致時延增加。
- 複雜的引數調整。
-
提出了新的擁塞控制機制HPCC，利用INT中存在的鏈路負載資訊來計算精確的流速率更新。
-
相較於其他的演算法，大部分情況下HPCC只需要更新一次。可以為高利用率快速調高速率或為了避免擁塞而快速降低速率。
-
調整流速率來使得輸入流量稍微小於鏈路容量防止鏈路隊伍增加以及保持高鏈路利用率。
-
引數很少，只有三個引數用於調整公平性和效率。
-
防止盲從INT訊息導致過度反應，選擇性地結合每個ACK反應和RTT反應選擇性地進行響應。
實驗和動機
- 說明在大型，高速RDMA網路中的CC演算法的限制和困難。
- 給出了下一代控制演算法的要求和方向。
RDMA部署
- 資料中心：Clos 拓撲，三層結構： TOR， AGG， 核心交換機。PoD(point of delivery), 擁有10個Tor交換機，相互與Agg交換機相連。每個伺服器有兩個上行鏈路，連結兩個Tor。
- 採用RoCEv2：DCQCN擁塞控制演算法，整合在RDMA NIC供應商網路卡中。
- 恢復演算法：go back N，回退重傳。
目標
- RDMA對資源具有高要求。
- PFC有潛在的巨大且破壞性影響。
- PFC具有抑制大量無辜傳送端的情況。
當前RDMA CC演算法權衡
- DCQCN
- 利用ECN來發現擁塞風險和快速反應。
- 允許主機在邊緣速率快速傳輸並且在瞬態擁塞後快速提升速率。
- 平衡吞吐和穩定性。
- 平衡頻寬和延遲。
下一代高速網路擁塞控制演算法目標
- 快速收斂。
- 近0佇列。
- 少量引數。
- 流量公平。
- 部署建議。
設計
- 依賴於交換機提供精確的負載資訊，例如佇列大小，累計傳輸接收流量等。
- 直接控制流動位元組的數量來避免反饋訊號延遲而導致的利用率下降。
- 結合RTT和ACK反應來實現快速反應和減少擁塞過度反應。
主要框架
- 傳送端驅動的控制擁塞網路框架。
- 在包傳送過程中，每一個交換機都會在包後增加INT資訊（時間戳，佇列長度，傳輸位元組，鏈路容量等資訊。）
- 接收端收到資訊後，將這些資料記錄在ACK資訊中傳送回傳送端。傳送端從ACK中決定如何調整流量。
基於傳輸資料量控制
- 基於窗的CC演算法，控制傳輸中的人資料流位元組數。在沒有擁塞的情況下為\(inflight = rate \times T\).
- 傳送端透過傳送視窗限制傳輸資料。初始傳輸\(W_{init}=B_{NIC}\times T\).
- 使用資料包節流避免爆發性流量。節流速率R=W/T。W：視窗大小。T：基礎RTT。
基於傳輸資料量的擁塞訊號和控制方法
-
與鏈路利用率直接相關。
-
假設鏈路頻寬B， 第i條經過的流有視窗大小\(W_i\)，那麼傳輸資料量即為\(I=\sum{W_i}\).
-
Case I: \(I < B\times T\)。 流的throughput則為\(\frac{W_i}{T}\)。所有流的總throughput小於鏈路頻寬。
-
Case II: \(I \geqslant B\times T\)，存在擁塞，形成了佇列。可能是這條鏈路發生了擁塞，也有可能是在其他的地方出現（存在多個bottleneck）
-
目標就是控制I滿足情況一，並且僅可能地使得I最大。這樣沒有擁塞和沒有佇列。
-
鏈路流量估計： \(I_j=佇列長度+輸出速率\times T\)
-
輸出速率計算：\(\frac{ack_1.txB-ack_0.txB}{ack_1.ts-ack_0.ts}\)。輸出位元組差與時間戳之差的比值。
-
假設了相同的RTT，在資料中心中是合理的。
-
存在瓶頸j時，\(I_j\)為下界。
-
傳送端要保證滿足情況一。因此有\(I_j=\eta\times B_j\times T\),\(\eta\approx 95\%\)。這樣對於鏈路j，可以以\(K_j=\frac{I_j}{\eta\times B_j\times T}=U_j/\eta\)來減小視窗大小，\(U_j\)時標準化的傳輸流量：
(2)
- 傳送端應該對最為擁堵的鏈路做出反應,\(W_{AI}\)用於保持公平性。
(3)
- 分離了鏈路利用率控制和公平性控制，可以快速抓取自由頻寬或避免擁塞。
- 多瓶頸：多輪迭代解決擁塞問題。單瓶頸：一輪迭代解決問題。
快速反應且避免過度反應
從(2) 和 (3) HPCC的傳送端可以對每一個ACK包做出反應，可以實現快速擁塞避免，但是會對描述相同包的ack重複反應。
上圖中，P1看到了qLen=4，假設透過方程得到W1=W0/2, 那麼對於P2，看到了qLen=4又看到了qLen=4，因此W2=W1/2=W0/4.導致過度反應。
-
當出隊的包看見一組全新的包時才進行更新。上例中，P7在傳送端收到P1的ACK後才發出，這樣其後面的佇列與P1完全不同。因此僅在收到上一次視窗調整後立即發出的包的ACK後才進行視窗調整。缺點是每次RTT才調整一次視窗可能對於處理緊急情況（錯誤，incast）事件來講太慢。
-
結合ACK與RTT方法一起進行調整。當ACK包收到時，我們更新\(W_i^c=W_i\)，用當前的視窗長度更新參考的視窗長度。然後透過遞迴的方式更新當前視窗長度：
這樣在上圖的情況下，收到P2的ACK時，參考視窗長度不會發生變化。因此我們不會進行更新，所以\(W(2)=W(1)=W(0)/2=W^c/2\).當P7的ACK到來時，再更新\(W^c\)。
演算法框架如下：
三個引數\(\eta,\text{maxstage},W_{AI}\)
- \(\eta\) 95%初始值，減少頻寬損失。
- \(maxStage\):平衡獲得自由頻寬的速度以及頻寬的穩定性。
- \(W_{AI}\)控制最大併發流在一個鏈路上的數量，可以維持近0佇列以及收斂到公平的速度。\(W_{AI}=\frac{W_{init}\times(1-\eta)}{N}\)
HPCC 性質
- 引數少。
- 採用txRate，更好地衡量傳輸中的資料量，rxRate則沒有具體的物理意義，並且與qlen具有重疊。所以XCP和RCP將會合並基於Qlen和rxRate的項來對引數進行微調。txRate可以反應rxRate在佇列中一個RTT後的結果。
- txRate收斂穩定，無震盪。
部署
INT在交換機上的填充
UDP報文後進行填充。
- nhop: 跳躍個數。
- pathID: 所有的路由器的ID的異或值，判斷路徑變化。
- 第一跳資料端：B：出口埠速率。TS：包離開出口埠時間戳，txBytes：累計流量。qLen：出口埠佇列長度。
- 硬體最佳化：除法最佳化。查詢表的方式進行。
- 支援許多並行流量。時鐘引擎限制了並行流的數量，採用RR方式。採用了多個獨立的引擎來排程多個獨立的流量。
參考閱讀：SIGCOMM】阿里巴巴新一代高速雲網路擁塞控制協議HPCC