@2019__SIGCOMM__HPCC - High Precision Congestion Control

> [!abstract] 概要(SIGCOMM '19 abstract の日本語訳) > 輻輳制御(congestion control, CC)は、高速ネットワークにおいて超低遅延・高帯域・ネットワーク安定性を同時に達成するための鍵である。大規模・高速 RDMA ネットワークを運用してきた経験から、我々は既存の高速 CC 方式にはこれらの目標を達成するうえで本質的な限界があることを見出した。本論文では、この3つの目標を同時に達成する新しい高速 CC 機構 HPCC(High Precision Congestion Control)を提案する。HPCC はインバンドネットワークテレメトリ(in-network telemetry, INT)を活用して正確なリンク負荷情報を取得し、トラフィックを精密に制御する。輻輳時に INT 情報が遅延する問題や INT 情報への過剰反応といった課題に対処することで、HPCC は空き帯域を素早く利用しながら輻輳を回避する方向へ迅速に収束でき、超低遅延のためほぼゼロの in-network キューを維持できる。HPCC は公平でもあり、ハードウェアへの実装も容易である。我々は市販のプログラマブル NIC とスイッチを用いて HPCC を実装した。評価の結果、DCQCN・TIMELY と比較して HPCC はフロー完了時間(FCT)を最大95%短縮し、大規模インキャスト下でも輻輳をほとんど引き起こさない。 ## 論文情報 - タイトル: HPCC: High Precision Congestion Control - 著者: Yuliang Li、Rui Miao、Hongqiang Harry Liu、Yan Zhuang、Fei Feng、Lingbo Tang、Zheng Cao、Ming Zhang、Frank Kelly、Mohammad Alizadeh、Minlan Yu - 所属: [[Alibaba Group]](Yuliang Li・Rui Miao・Hongqiang Harry Liu・Yan Zhuang・Fei Feng・Lingbo Tang・Zheng Cao・Ming Zhang)、[[Harvard University]](Yuliang Li・Minlan Yu)、[[University of Cambridge]](Frank Kelly)、[[Massachusetts Institute of Technology]](Mohammad Alizadeh) - 媒体: SIGCOMM '19(2019 Conference of the ACM Special Interest Group on Data Communication)、2019年8月19〜23日、北京 - DOI: https://doi.org/10.1145/3341302.3342085 ## 概要 Alibaba が大規模・高速 RDMA(RoCEv2)ネットワークを本番運用してきた経験から、既存の高速輻輳制御(DCQCN・TIMELY)には「遅い収束」「回避不能なキュー蓄積」「複雑なパラメータチューニング」という3つの本質的限界があることを指摘する。根本原因は、スイッチからのフィードバックが ECN の1ビット、あるいは RTT という粗粒度情報に限られる点にある。HPCC は、スイッチの INT 機能を使って ACK パケットにキュー長・送信バイトレート・リンク帯域容量を直接埋め込み、送信者がリンクごとの inflight bytes を精密に制御することで、ほぼ1回のレート更新で適正な送信レートに収束する新しい CC 機構である。 ## 問題設定 - **入力**: 送信者から受信者へ送られる各パケットへの、経路上の各スイッチによる INT メタデータ付加(タイムスタンプ ts・キュー長 qLen・累積送信バイト txBytes・リンク帯域容量 B)。受信者はこれらをすべて ACK にコピーして送信者へ返す。 - **出力**: 各送信者(RDMA フロー)が次に使うウィンドウサイズ $W_i$ とペーシングレート $R = W/T$($T$ はベース RTT)。 - **前提条件**: データセンター内では大半のサーバペア間のベース RTT がほぼ同一である(トポロジの規則性による)ため、Eqn (1) は全フローが同一の既知ベース RTT を持つと仮定してよい。スイッチは INT 機能(P4 の一部機能のみで実装可能な標準的な INT)を持つ。 - **必要なデータ**: 経路上の各リンクの qLen・txBytes・ts・B。これらはすべて標準的な INT 情報である。 ### 本番運用での動機(§2) Alibaba の RDMA(RoCEv2)本番ネットワークは Clos トポロジ(ToR/Agg/Core の3層)であり、CC は DCQCN、ロスレス化は PFC を用いる。この運用から観測された2つの困難が HPCC 提案の動機である。 - **PFC ポーズの伝播と容量損失**: PoD 内の PFC ポーズ伝播グラフを監視すると、約10%の PFC イベントが3ホップ伝播し(単一または少数の送信者が PoD 全体に影響)、10%超の PFC ポーズがデータセンター全体容量の3%超を抑制、最悪ケースで容量損失が25%に達する。 **Figure 1: 本番環境でのPFCポーズの影響** ![[_attachments/HPCC---high-precision-congestion-control-/fig01-pfc-pause-impact.png]] (Figure 1. (a) Propagation depth: PFCポーズの伝播ホップ数のCDFで、約10%が3ホップまで伝播する。(b) Suppressed bandwidth: 抑制される帯域割合のCDFで、10%超のPFCポーズがネットワーク全容量の3%超を抑制し、最悪25%に達する。Source: Adapted from Figure 1.) - **DCQCNのスループット対安定性トレードオフ(throughput vs. stability)**: 230サーバのテストベッドでWebSearchトラフィックを用いた実験では、レート増加タイマー$T_i$を小さく・レート減少タイマー$T_d$を大きくすると FCT スローダウンは改善するが、incast時の PFC ポーズ時間と95パーセンタイルレイテンシが悪化する。この2つは常にトレードオフの関係にある。 **Figure 2: 異なるレート増減タイマーでのDCQCNのFCTスローダウンとPFCポーズ(WebSearch)** ![[_attachments/HPCC---high-precision-congestion-control-/fig02-dcqcn-timer-tradeoff.png]] (Figure 2. (a) 30%負荷下、95パーセンタイルFCTスローダウンは $T_i$ が小さく $T_d$ が大きいほど改善する。(b) 30%負荷+incastでのPFCポーズ時間・95パーセンタイルレイテンシは、同じ設定(小さい$T_i$・大きい$T_d$)でむしろ悪化する。Source: Adapted from Figure 2.) - **DCQCNの帯域対レイテンシトレードオフ(bandwidth vs. latency)**: ECNマーキング閾値($K_{min}$, $K_{max}$)を低く設定すると小フロー(レイテンシ重視)のFCTは改善するが大フロー(帯域重視)のFCTが悪化し、負荷が高いほどこの傾向は顕著になる。$K_{min}=400KB$, $K_{max}=1600KB$では50%負荷時の95パーセンタイルRTTが約150μs(ML アプリケーションが要求する50μs未満を大幅に超過)に達する。 **Figure 3: 異なるECN閾値でのFCTスローダウンの95パーセンタイル分布(WebSearch)** ![[_attachments/HPCC---high-precision-congestion-control-/fig03-ecn-threshold-tradeoff.png]] (Figure 3. (a) 30%負荷: ECN閾値が低いほど小フローのFCTは改善するが大フローは悪化する。(b) 50%負荷: 同じ傾向がより顕著に現れる。Source: Adapted from Figure 3.) これらの経験から、著者らは次世代の高速CCが同時に満たすべき5要件——(i) 高速収束、(ii) ほぼ空のキュー、(iii) 少ないパラメータ、(iv) 公平性、(v) ハードウェアへの実装容易性——を提示する。INTの普及とNICのプログラマブル化という2つの技術トレンドがこれを実現可能にしたと位置づける。 ## 提案手法 - **アーキテクチャ**: HPCC は送信者駆動(sender-driven)の CC フレームワークである。送信者が送るすべてのパケットは受信者によって ACK される。パケットが送信者から受信者へ伝搬する間、経路上の各スイッチはそのスイッチング ASIC の INT 機能を用いて、パケットの egress ポートの現在の負荷(タイムスタンプ ts、キュー長 qLen、送信バイト txBytes、リンク帯域容量 B)を示すメタデータを挿入する。受信者はこれらのメタデータをすべて ACK メッセージにコピーして送信者へ返す。送信者は ACK を受信するたびに、そのネットワーク負荷情報に基づいて送信レートを調整する(Figure 4)。 **Figure 4: HPCC フレームワークの全体像** ![[_attachments/HPCC---high-precision-congestion-control-/fig04-hpcc-framework-overview.png]] (Figure 4. Sender が pkt を送出し(①)、Link-1・Link-2 が INT メタデータを付加しながら中継し(②〜⑤)、Receiver が全メタデータをコピーした ACK を返す(⑥)。Sender は ACK ごとに送信レートを調整する。Source: Adapted from Figure 4.) - **inflight bytes に基づく輻輳制御(§3.2)**: HPCC はレートではなく inflight bytes(送信済みだが未確認応答のデータ量)を直接制御するウィンドウベースの CC である。無輻輳時は inflight bytes とレートは $inflight = rate \times T$ で等価に交換可能だが、輻輳時に inflight bytes を直接制御することで、フィードバックが遅延しても送信者は限度を超えて送信し続けない。リンク $j$ の inflight bytes を Eqn (1) で推定する。 $I_j = qlen + txRate \times T \quad (1)$ ここで $qlen$ は INT から直接得られ、$txRate$ は2つの ACK 間の txBytes と ts の差分から計算される($txRate = \frac{ack_1.txBytes - ack_0.txBytes}{ack_1.ts - ack_0.ts}$)。目標は、すべてのリンクについて $I_j$ を $B_j \times T$ よりわずかに小さく($\eta \times B_j \times T$、$\eta$ は 95% など 1 に近い定数)保つことである。正規化 inflight bytes $U_j$ を Eqn (2) で定義する。 $U_j = \frac{I_j}{B_j \times T} = \frac{qlen_j}{B_j \times T} + \frac{txRate_j}{B_j} \quad (2)$ 送信者は最も輻輳したリンクに反応する(Eqn (3))。 $W_i = \frac{W_i}{\max_j(U_j)/\eta} + W_{AI} \quad (3)$ 第1項は MIMD(乗算的増加・乗算的減少)項で効率と安定性を担い、$W_{AI}$(加算的増加)は公平性のための小さな増分である。効率制御と公平性制御を分離することで、送信者は空き帯域を素早く獲得あるいは輻輳を回避しつつ、公平性へ緩やかに収束する。この設計は XCP に着想を得ている。 - **過剰反応なしの高速反応(§3.2)**: HPCC は ACK ごとに反応することで高速な輻輳回避を実現できるが、同じパケット・同じキューを描写する複数の ACK に多重反応すると過剰反応(overreaction)を起こす。Figure 5 はこの問題を示す。 **Figure 5: 連続する2つの ACK への過剰反応** ![[_attachments/HPCC---high-precision-congestion-control-/fig05-overreaction-two-acks.png]] (Figure 5. S1 から送られた P1・P2・P5 と S2 から送られた P3・P4 が同一 egress buffer に滞留する。P1 の ACK が qLen=4 を報告して S1 がウィンドウを半減させた直後、ほぼ同じキュー状態を見ている P2 の ACK にも反応すると、ウィンドウが本来の1/4まで過剰に縮小してしまう。Source: Adapted from Figure 5.) HPCC はこれを、per-RTT で更新される参照ウィンドウ $W_i^c$ を導入して解決する。現在の $W_i^c$ で送られた最初のパケットの ACK を受信したときにのみ $W_i^c = W_i$ と更新し、Eqn (4) で安全にウィンドウを更新する。 $W_i = \frac{W_i^c}{\max_j(U_j)/\eta} + W_{AI} \quad (4)$ $W_i$ は1RTT内で固定される $W_i^c$ から計算されるため、同一のネットワーク負荷に対して過剰反応しない。一方、inflight bytes が RTT 内で急変した場合でも $U_j$ 自体は更新されるため、Eqn (4) によってウィンドウは適切に調整される。 - **アルゴリズム(Algorithm 1)**: 送信側の全体ワークフローは擬似コードとして提示されている。 ``` function MeasureInflight(ack): u = 0 for each link i on the path: txRate = (ack.L[i].txBytes - L[i].txBytes) / (ack.L[i].ts - L[i].ts) u' = min(ack.L[i].qlen, L[i].qlen) / (ack.L[i].B * T) + txRate / ack.L[i].B if u' > u: u = u'; τ = ack.L[i].ts - L[i].ts τ = min(τ, T) U = (1 - τ/T) * U + (τ/T) * u return U function ComputeWind(U, updateWc): if U >= η or incStage >= maxStage: W = Wc / (U/η) + W_AI if updateWc: incStage = 0; Wc = W else: W = Wc + W_AI if updateWc: incStage += 1; Wc = W return W procedure NewAck(ack): if ack.seq > lastUpdateSeq: W = ComputeWind(MeasureInflight(ack), True) lastUpdateSeq = snd_nxt else: W = ComputeWind(MeasureInflight(ack), False) R = W / T; L = ack.L ``` `MeasureInflight` は Eqn (2) に基づき正規化 inflight bytes を推定する。現在・直前の qlen の最小値でノイズを除去し(Line 5)、$\max_i(U_i)$ を EWMA でフィルタしてタイマー誤差や一時的なキューのノイズを平滑化する(Line 9)。`ComputeWind` は乗算的増加/減少(MI/MD)と加算的増加(AI)を組み合わせる。増加余地があると判断すると、まず $maxStage$ 回まで AI ステップ $W_{AI}$ を試し(Line 17)、それでも余地があるか正規化 inflight bytes が $\eta$ を超えていれば Eqn (4) を1回適用して急速にランプアップ/ダウンする(Line 12-13)。 - **txRate を使う理由(Key insight)**: XCP・RCP のような rxRate と qlen を組み合わせる方式は、両者が同じ輻輳を別の側面から二重計測しているため相対重みのスケーリングパラメータが必要になる。一方 txRate は、ウィンドウベースの CC においてパケット送信が ACK によってクロックされる性質上、そのスイッチキューでの txRate が1RTT先の rxRate を反映する。したがって txRate に基づいてウィンドウを調整すると、測定時点から1RTT後の輻輳の程度を先取りして反応でき、rxRate を使うより正確になる。 **Figure 6: txRate と rxRate の比較** ![[_attachments/HPCC---high-precision-congestion-control-/fig06-txrate-vs-rxrate.png]] (Figure 6. 2対1輻輳シナリオでの queue length の時系列。rxRate を用いた HPCC-rxRate は収束前に振動するのに対し、txRate を用いた HPCC は振動なく滑らかに収束する。Source: Adapted from Figure 6.) - **実装上の工夫**: - **パケットフォーマット(§4.1, Figure 7)**: INT パディングは UDP ヘッダの後、IB BTH(Base Transport Header)の前に挿入される。nHop(4bit、経路のホップ数)と pathID(12bit、経路上の全スイッチ ID の XOR、経路変化検知に使用)を持ち、各ホップは B(4bit、ポート速度種別)・TS(24bit、タイムスタンプ)・txBytes(20bit、単位128バイト)・qLen(16bit、単位80バイト)の8バイトを追加する。データセンター内の経路長は通常5ホップ以内であり、パディング総量は最大42バイト(1KBパケットの4.2%)にとどまる。 **Figure 7: HPCC のパケットフォーマット** ![[_attachments/HPCC---high-precision-congestion-control-/fig07-packet-format.png]] (Figure 7. UDP Header と IB BTH の間に nHop・pathID・各ホップの B/TS/txBytes/qLen フィールドが挿入される。5ホップで INT オーバーヘッドは42バイト。Source: Adapted from Figure 7 + 本文の項目説明。) - **NIC 実装(§4.2, Figure 8)**: 商用プログラマブル NIC 上に FPGA チップを実装し、PCIe モジュールと MAC モジュールの間に CC(Congestion Control)モジュール・Flow Scheduler・TX/RX pipe を配置する。Flow Scheduler はラウンドロビンでクレジットベースのペーシングを行い、TX pipe が IB/UDP/IP スタックを実装し、RX pipe が受信パケットを解析してデータパケット→ACK生成、ACK受信→CCモジュールへの通知、NAK受信→go-back-N再送開始、といったイベントを発行する。 **Figure 8: HPCC の NIC 実装の概要** ![[_attachments/HPCC---high-precision-congestion-control-/fig08-nic-implementation.png]] (Figure 8. FPGA 上の PCIe Module・Congestion Control Module・Flow Scheduler・TX/RX pipe・MAC Module の接続関係。Update/Notify/PktSend/PktRecv イベントで各モジュールが連携する。Source: Adapted from Figure 8.) - **ハードウェア高速化(§4.3)**: ACK 受信ごとの Eqn (4) の除算は FPGA では高コストなため、$1/n$ の値をルックアップテーブル化して乗算に置き換え、除算を約8倍高速化した。誤差を一定範囲(ε)に抑えつつテーブルサイズを削減するため、隣接する $1/n$ の差が ε 以上になる n だけを格納する($1 \le n \le 2^{22}$ を約10KBで表現)。また、フロースケジューラのクロックエンジン速度がボトルネックになるため、FPGA では6個の独立エンジンで並列に25GEインタフェースあたり300並行フローを、ASIC実装では最大9000並行フローをサポート可能と見積もる。 ## 新規性既存の DCQCN・TIMELY は ECN の1ビットマーキングや RTT という粗粒度フィードバックしか得られないため、適正なレートへ収束するまで多数回のヒューリスティックな反復調整が必要であり、(i) 大規模輻輳イベントへの収束が遅い、(ii) キューが構築されてから初めて反応するため遅延が避けられない、(iii) DCQCN は15個のノブを持つなど環境ごとのパラメータチューニングが複雑、という3つの限界を抱える。HPCC は INT による正確なリンク負荷情報を利用することで、ほとんどの場合1回のレート更新で適正な送信レートに到達でき、これら3限界を同時に解消する。また XCP・RCP のような既存の明示的フィードバック方式は、輻輳信号がヒューリスティックな複数種フィードバックの組み合わせであるためスケーリングパラメータが必要になるのに対し、HPCC の輻輳信号(inflight bytes)は具体的な物理的意味を持つため、そうしたパラメータを必要としない。 ## 実験設定 - **実験環境**: - テストベッド: Alibaba の本番 RDMA PoD を模した小規模構成。Agg スイッチ1台・ToR スイッチ4台(ToR1〜ToR4)を100Gbpsリンクで接続、サーバ32台(各25GbpsNIC×2)。ラック内ベースRTT 5.4μs、ラック間8.5μs。 - シミュレーション: NS3 上の FatTree トポロジ。Core16台・Agg20台・ToR20台・サーバ320台(ラックあたり16台、各100GbpsNIC1本)、Core-Agg間・Agg-ToR間はすべて400Gbps、伝搬遅延1μs(最大ベースRTT 12μs)、スイッチバッファ32MB。 - **データセット**: 公開データセンタートラフィックトレース WebSearch・FB_Hadoop を用い、平均リンク負荷を30%・50%に調整。 - **比較対象**: DCQCN・TIMELY(いずれも RDMA 向け CC)、両者にウィンドウを追加した DCQCN+win・TIMELY+win、DCTCP(スロースタート除去版)。 - **評価指標**: (i) FCT スローダウン、(ii) 個々フローのリアルタイム帯域、(iii) ネットワーク遅延、(iv) PFC ポーズ時間、(v) in-network キューサイズ。 - **パラメータ**: HPCC は $W_{AI}=80$ bytes、$maxStage=5$、$\eta=95\%$、$T=9\mu s$(テストベッド)/$13\mu s$(シミュレーション)。DCQCN・DCTCP はベンダー推奨/文献推奨値を帯域比例スケーリングして使用。 ## 実験結果 - **定量評価**: - **rate recovery**: Long-Short トラフィックで、HPCC は短フロー終了直後に長フローのレートをライン速度に回復するが、DCQCN は2ms(>350RTT)後もライン速度に回復しない。 - **congestion avoidance**: 7送信者の Incast で HPCC は1往復で反応しキューを速やかに排出するが、DCQCN はキューが550KBまで蓄積する。 - **network latency**: 2本のエレファントフローで飽和したリンクを通過するマウスフロー(1KB)のレイテンシは、HPCC でベースRTTに近い約5.4μs、DCQCN では標準的に35μs超。 - **FCT slowdown**: WebSearch トラフィックで、30%負荷時に3KB未満の短フローの99パーセンタイル FCT スローダウンを11.2→2.38(16.9μs)へ、50%負荷時に53.9→2.70(19.2μs)へ削減(95%削減)。 - **queue size**: 50%負荷時のHPCCの95/99パーセンタイルキューサイズは19.7KB/22.9KBに対し、DCQCNは1.1MB/2.1MB。 - **PFC pauses**: FB_Hadoop + incast シミュレーションでは、大規模PFCポーズはDCQCN・TIMELYでのみ発生し、HPCCでは発生しない。ウィンドウを追加しただけのDCQCN+winでもPFCはほぼゼロになり、inflight bytes 制御が安定性の鍵であることを裏付ける。 - **長フローのスローダウン**: HPCCは5%の帯域ヘッドルームとINTヘッダのオーバーヘッドにより、長フローのスローダウンが他方式より大きい(50%負荷でHPCCは他方式比1.24倍遅い)。これは短フローを優先するトレードオフである。 - **アブレーション**: - **per-ACK vs per-RTT vs HPCC**: 16対1インキャストで、per-ACKのみの反応は速いが過剰反応でスループットがほぼ0まで落ち込み振動する。per-RTTのみの反応は反応が遅くキューが長時間残留する。HPCCの参照ウィンドウ機構は両者の欠点を回避する(Figure 13、本文で言及されるが図表番号のみ参照)。 - **$W_{AI}$のチューニング**: 16並行フローで$W_{AI}$を150bytes以下に保つとキュー長は95パーセンタイルで4KB以内に収まるが、300bytesでは13KBまで悪化する(Figure 14、本文で言及されるが図表番号のみ参照)。$W_{AI}$を大きくしても性能はグレースフルに劣化する。 - **フロー制御方式(PFC/go-back-N/IRN)の組み合わせ**: HPCCではどのフロー制御方式を使っても性能はほぼ変わらないが、DCQCNではフロー制御方式による差が大きく現れる(それでもIRN併用DCQCNはHPCCに及ばない)。CCそのものが鍵であることを確認する。 - **定性評価**: Figure 9〜12・9系列は、いずれもHPCCがDCQCN・TIMELY・DCTCP等に比べ、短フローの低レイテンシ・低スローダウン・近ゼロキュー・低PFCポーズを一貫して達成する傾向を示す。 **Figure 9: 4種のマイクロベンチマークトラフィックでのHPCCとDCQCNのテストベッド比較** ![[_attachments/HPCC---high-precision-congestion-control-/fig09-microbenchmarks.png]] (Figure 9. (a)(b) Long-Short: HPCCは短フロー終了後すぐに長フローのレートを回復するがDCQCNは2ms後も回復しない。(c)(d) Incast: HPCCは1往復でキューを排出するがDCQCNは550KBまで蓄積。(e)(f) Elephant-Mice: HPCCはマウスフローのレイテンシをベースRTT付近(約5.4μs)に保つがDCQCNは35μs超。(g)(h) Fair-Share: 両者ともおおむね公平だがHPCCの方が収束が速い。Source: Adapted from Figure 9.) **Figure 10: WebSearch(30%・50%負荷)でのHPCCとDCQCNのFCTスローダウンとキューサイズ** ![[_attachments/HPCC---high-precision-congestion-control-/fig10-fct-queue-websearch.png]] (Figure 10. (a)(c) FCTスローダウンはHPCCが95/99パーセンタイルで大幅に低い。(b)(d) キュー長CDFはHPCCが99パーセンタイルでもDCQCNの数十分の1(50%負荷で19.7KB/22.9KB vs 1.1MB/2.1MB)。Source: Adapted from Figure 10.) **Figure 11: FB_Hadoop(30%負荷+incast・50%負荷)での95パーセンタイルFCTスローダウン・PFC・レイテンシ** ![[_attachments/HPCC---high-precision-congestion-control-/fig11-fct-pfc-latency-fbhadoop.png]] (Figure 11. (a)(c) 120KB未満の短フローでHPCCが最も低いFCTスローダウンを達成。(b)(d) 大規模PFCポーズはDCQCNとTIMELYでのみ発生しHPCCではゼロ。95パーセンタイルレイテンシはHPCCが最も低い(50%負荷で19.8μs、ベースRTT 12μsに対し8μs未満の追加遅延)。Source: Adapted from Figure 11.) **Figure 12: 異なるフロー制御方式でのFCTスローダウン(GBN=go-back-N)** ![[_attachments/HPCC---high-precision-congestion-control-/fig12-flow-control-comparison.png]] (Figure 12. HPCCではPFC/GBN/IRNのいずれを使っても性能はほぼ同一だが、DCQCNではフロー制御方式による差が大きい(IRN併用でも改善は限定的でHPCCに届かない)。Source: Adapted from Figure 12.) **Figure 13: ACKへの異なる反応方式の比較** ![[_attachments/HPCC---high-precision-congestion-control-/fig13-per-ack-per-rtt-reaction.png]] (Figure 13. per-ACK反応は素早くキューに反応するが過剰反応でスループットが振動する。per-RTT反応は反応が遅くキューが長時間残留する。HPCCの参照ウィンドウ方式は両者の欠点を避けて素早く安定的に収束する。Source: Adapted from Figure 13.) **Figure 14: $W_{AI}$による公平性とキューサイズ** ![[_attachments/HPCC---high-precision-congestion-control-/fig14-wai-fairness-queue.png]] (Figure 14. 16並行フローで、$W_{AI}$が150bytes以下ならキュー長は95パーセンタイルで4KB以内、300bytesでは13KBまで悪化する。$W_{AI}$が大きいほど公平性収束は速いが、性能劣化はグレースフル。Source: Adapted from Figure 14.) ## 考察 HPCCがDCQCN・TIMELYを凌駕する根本理由は、輻輳信号の粒度にある。ECNの1ビットやRTTの変化という間接シグナルではなく、INTによってリンクのキュー長・送信バイトレート・帯域容量という直接測定値が得られるため、送信者は「今どれだけレートを増減すべきか」を推測ではなく計算で決定できる。これにより、DCQCN・TIMELYが抱える「攻撃性(throughput)と安定性のトレードオフ」「レイテンシと帯域のトレードオフ」という根本的なジレンマを、INTという情報粒度の向上によって解消する。一方で、HPCCは5%の帯域ヘッドルームとINTヘッダオーバーヘッドを常に消費するため、長フロー(帯域支配的なフロー)のスループットは他方式よりわずかに劣る。これは短フロー(レイテンシ支配的)を優先する設計判断による意図的なトレードオフである。理論面では、Appendix Aにおいて、単純なモデル(離散時間・同期更新・単一/複数ボトルネック)のもとでHPCCが1RTTでフィージブルなレート割当に到達し、その後Pareto最適配分へ高速収束すること、加算的増加項によって長期的にmax-min公平寄りの配分へ緩やかに収束することが証明されている。また、目標利用率を100%未満に設定することで、$D_i/D/1$待ち行列モデルに基づき、定常状態でのキュー長がごく小さく保たれることも示されている(95%負荷・50送信者で平均キュー長約3パケット)。 ## 強み / 弱点・課題 **強み**: - INTによる直接測定に基づく物理的意味を持つ輻輳信号により、DCQCN(15ノブ)やTIMELY・DCTCPのような多数のヒューリスティックパラメータが不要($\eta$・$maxStage$・$W_{AI}$の3個のみ、いずれも信頼性非依存)。 - inflight bytes直接制御により、フィードバック遅延下でも送信者が過剰送信しない(TCPのウィンドウ機構をデータセンター輻輳制御に応用した点が新規)。 - per-ACK/per-RTTのハイブリッド反応により、過剰反応なしに高速反応を実現。 - 商用NIC(FPGA)・商用スイッチASIC(P4対応)への実装が容易(標準的なINT機能のみに依存し、アーキテクチャ変更ではなく既存RoCE NICパラダイムへの追加ロジックで済む)。 - 理論的に収束性・公平性が保証されている(Appendix A)。 **弱点・課題**: - 長フローのスループットが他方式よりわずかに劣る(5%帯域ヘッドルーム+INTオーバーヘッドによる意図的トレードオフ)。 - Eqn (1)は全フローが同一の既知ベースRTTを持つ前提であり、複数ボトルネックを持つフローに対してはinflight bytesを過小推定するため複数ラウンドの調整が必要になる。 - INTパディングによる帯域オーバーヘッド(最大42バイト、1KBパケットで4.2%)は最悪ケース想定であり、実装によっては最終ホップのみで済む場合もあるとされるが、詳細な感度分析は本文になし。 - IB verbsの完全サポート(RDMA WRITE/READ以外の操作)は将来課題として明記されている。 - FPGAのクロックエンジン速度が並行フロー数のボトルネックであり、ASIC実装での9K並行フロー対応は見積もりに留まり実証されていない。