> [!abstract] 概要(ACM SIGCOMM 2023 abstract の日本語訳) > システムおよびネットワーキングコミュニティにおける従来の通念は、輻輳は主にネットワークファブリック内で発生するというものである。しかし、高帯域アクセスリンクの採用と、ホスト内資源に対する比較的停滞した技術トレンドにより、ホスト輻輳——すなわちNICとCPU/メモリの間でデータ交換を可能にするホストネットワーク内での輻輳——の顕在化が生じている。このようなホスト輻輳は、輻輳制御に関する数十年にわたる研究と実践の中に深く根付いた多くの前提を覆す。 > 我々はhostCCを提示する。これはホストとネットワークファブリック両方の輻輳を扱う輻輳制御アーキテクチャである。hostCCは3つの鍵となるアイデアを体現する。第一に、ネットワークファブリック内部から生じる輻輳シグナルに加えて、hostCCはホスト輻輳の正確な時刻・場所・理由を捉えるホスト輻輳シグナルを収集する。第二に、hostCCはサブRTT粒度のホストローカル輻輳応答を導入し、輻輳シグナルを用いてネットワークトラフィックとホストローカルトラフィックの間でホスト資源を配分する。最後に、hostCCはホストとネットワーク両方の輻輳シグナルを用いてRTT粒度でネットワーク資源配分を実行する。 > 我々はLinuxネットワークスタック内でhostCCを実現した。我々のhostCC実装はアプリケーション、ホストハードウェア、および/またはネットワークハードウェアへの変更を必要としない。さらに、既存の輻輳制御プロトコルと統合してホストとネットワークファブリック両方の輻輳を扱うことができる。hostCCの有無によるLinux DCTCPの評価は、ホスト輻輳が存在する場合、hostCCがホストでのキューイングとパケットドロップを大幅に削減し、ネットワークアプリケーションのスループットとテールレイテンシの面で性能を改善することを示唆する。 ## 論文情報 - タイトル: Host Congestion Control - 著者: Saksham Agarwal([[Cornell University]])、Arvind Krishnamurthy([[Google]] & [[University of Washington]])、Rachit Agarwal([[Cornell University]]) - 媒体・発表年: ACM SIGCOMM 2023(2023年9月10〜14日、New York, NY, USA)、13ページ - DOI: [10.1145/3603269.3604878](https://doi.org/10.1145/3603269.3604878) - コード: [github.com/Terabit-Ethernet/hostCC](https://github.com/Terabit-Ethernet/hostCC)(著者らが公開する実装リポジトリ。`src/`にhostCC実装、`utils/`にベンチマークアプリケーションと計測ツール、`scripts/`にSIGCOMM'23論文の実験再現スクリプトを収める。Intel Cascade Lakeアーキテクチャ向けに設計されたLinuxカーネルモジュールとして動作する) ## 概要 本論文は、高帯域NICと相対的に停滞したホスト内資源(CPU・キャッシュ・メモリ帯域)のギャップから生じる「ホスト輻輳」という新たな輻輳形態を実測で特定し、これに対処する輻輳制御アーキテクチャhostCCを提案する。ホスト輻輳はネットワークファブリックではなくNIC-CPU/メモリ間のプロセッサ・メモリ・周辺機器インターコネクト内で発生し、輻輳点から離れたNICバッファでのキューイングとドロップという、古典的輻輳制御の前提と異なる挙動を示す。hostCCはIIOバッファ占有量というホスト輻輳シグナルを新規に導入し、サブRTT粒度のホストローカル応答とRTT粒度のネットワーク資源配分を組み合わせることで、既存の輻輳制御プロトコル(実装ではLinux DCTCP)を変更せずに統合できる。 ## 問題設定 - **入力**: NICが受信するパケットストリーム、ホスト側の競合トラフィック(CPU-to-メモリトラフィックを生成するホストローカルアプリケーション)、既存のネットワーク輻輳制御プロトコル(DCTCP等)。 - **出力**: ホスト資源(PCIe帯域・メモリ帯域)とネットワーク資源(送信レート/ウィンドウ)の両方について、ネットワークトラフィックとホストローカルトラフィックの間での配分決定。 - **前提**: ホストネットワーク(PCIeインターコネクト・IIO・メモリコントローラ間の経路)はロスレスでクレジットベースのフロー制御を用いる。ホストローカルトラフィック(CPUからメモリへの直接アクセス等)は輻輳制御プロトコルに従わず、輻輳点に近いためサブRTT粒度で急変しうる。 ## 提案手法 ### アーキテクチャ hostCCは(1) ホスト輻輳シグナル生成、(2) サブRTT粒度のホストローカル輻輳応答、(3) RTT粒度のネットワーク資源配分、という3つの技術アイデアで構成される。従来のネットワーク輻輳制御(Classical Network CC)・フロー制御(Classical Network FC)に、送信側・受信側それぞれのホストにHost-local Congestion Responseを追加し、ホスト輻輳シグナルをネットワーク輻輳制御へエコーする構造を取る。 **Figure 5: hostCCアーキテクチャ全体像** ![[_attachments/Host-Congestion-Control/fig05-hostcc-architecture.png]] (Figure 5. 送信ホスト(左)と受信ホスト(右)それぞれで、Host-local Congestion Responseがホスト輻輳シグナルを入力にホストローカル応答レベルを出力する。Classical Network CC/FCは、ホスト輻輳シグナルとネットワーク輻輳シグナルの両方を入力として受け取り、ネットワーク資源配分(送信側)またはフロー制御・エコー(受信側)を行う。Source: Adapted from Figure 5.) ### ホスト輻輳シグナル(§3.1) hostCCは**IIOバッファ占有量**($I_S$)を主要なホスト輻輳シグナルとして用いる。ホストネットワークデータパスは、NICからIIO(Integrated IO Controller)への経路と、IIOからメモリコントローラへの経路の2区間から成る。 **Figure 1: ホストネットワークデータパス(DDIO無効時、Intelアーキテクチャ)** ![[_attachments/Host-Congestion-Control/fig01-host-datapath.png]] (Figure 1. ①NICがパケットをバッファに格納、②NICがディスクリプタを取得してDMA先アドレスを特定、③PCIeがロスレスなクレジットベースフロー制御でDMAを実行(PCIeクレジット消費)、④IIOがPCIeトランザクションを受けてメモリへの書き込みを開始しクレジットを補充する。IIOからメモリコントローラへの経路も同様にロスレスなクレジットベースフロー制御を持つ。Source: Adapted from Figure 1.) PCIeスループットは $P/\max\{\ell_p, \ell_m\}$ で与えられる。ここで $P$ はPCIeが維持できる最大in-flightバイト数、$\ell_p$ はNIC-IIO間の固定レイテンシ、$\ell_m$ はIIO-メモリコントローラ間のレイテンシ(メモリコントローラの書き込みキューサイズ・負荷・DDIOの有無に依存)である。IIOバッファ占有量は $R \times \ell_m$(RはNICがデータを受信するレート)に等しく、ホスト輻輳がない通常時は $\ell_m \approx \ell_m^{min} \ll \ell_p$ でありPCIe利用率は$\ell_p$に律速される。ホスト輻輳時は $\ell_m$ が増大し、IIOバッファ占有量が $R \times \ell_m^{min}$ から $\min\{R \times \ell_m^{max}, \text{PCIeクレジット上限}\}$ まで増加しうる。 IIO占有量をホスト輻輳シグナルに用いる利点は3点ある。(1) メモリコントローラが輻輳した瞬間に増加し輻輳解消時のみ増加が止まるため、時刻・場所・理由の正確性が高い。(2) IIO挿入レート(IIO insertion rate)と組み合わせることで瞬時PCIeスループットやホスト遅延(Little's Lawによる)などの派生指標を計算できる。(3) 既存ハードウェアの2つのレジスタで測定可能で、追加ハードウェア支援を必要としない。また、IIO計測点はNIC-メモリデータパスの外側(プロセッサインターコネクト上)にあるため、ホスト輻輳の影響を受けずに測定できる。 **Figure 7: 輻輳シグナル読み取りレイテンシのCDF** ![[_attachments/Host-Congestion-Control/fig07-signal-read-latency-cdf.png]] (Figure 7. hostCCが生成するホスト輻輳シグナルは、NIC-メモリデータパス上に存在しないため、ホスト輻輳の有無に関わらずサブマイクロ秒スケールで$I_S$(左)・$B_S$(右)を測定できる。Source: Adapted from Figure 7.) **Figure 8: IIO占有量とPCIe帯域利用率の時間変化** ![[_attachments/Host-Congestion-Control/fig08-iio-occupancy-pcie-bw-time.png]] (Figure 8. ホスト輻輳なし時(左)は $B_S \approx 103$Gbps(4K MTUを含むライン速度)、$I_S \approx 65$(ハードウェア固有のIIO-DRAM帯域遅延積に相当)。3倍のホスト輻輳時(右)は $I_S$ が最大約93まで増加し、$B_S$ の低下・NICでのキューイングとパケットドロップ・ネットワーク輻輳制御によるレート低下を招く。Source: Adapted from Figure 8.) ### ホストローカル輻輳応答(§3.2) hostCCの実装は、ホスト輻輳シグナル $I_S$(閾値$I_T$との比較)とPCIe帯域利用率 $B_S$、目標ネットワーク帯域 $B_T$ を入力に、4つの操作レジームでホストローカルトラフィックへの資源配分を決定する。 **Figure 6: hostCCの資源配分決定** ![[_attachments/Host-Congestion-Control/fig06-resource-allocation-regimes.png]] (Figure 6. ① ホスト輻輳なし・目標帯域達成済み: ホストローカルトラフィックへの資源配分を増加。② ホスト輻輳あり・目標帯域達成済み: ネットワーク輻輳制御へシグナルをエコーしてネットワークトラフィックのレートを削減。③ ホスト輻輳あり・目標帯域未達成: ホストローカルトラフィックへの資源配分をまず削減。④ ホスト輻輳なし・目標帯域未達成: ホストローカルトラフィックへの資源配分は増やさずAIMD機構に委ねる。Source: Adapted from Figure 6.) 実装ではIntel Memory Bandwidth Allocation(MBA)を用いてホストローカルトラフィックへのバックプレッシャーを実現する。MBAはCPUコアのL2キャッシュミス時に追加レイテンシを導入することでメモリトラフィックのレートを抑制する仕組みで、hostCCの実装は5段階の応答レベル($\ell=0,1,2,3,4$、レベル4はSIGSTOP/SIGCONTによるプロセス一時停止で実現)を用いる。 **Figure 9: MBAの有効性評価** ![[_attachments/Host-Congestion-Control/fig09-mba-efficacy.png]] (Figure 9. ホストローカル応答レベルを上げる(MApp=ホストローカルトラフィックへのバックプレッシャーを強める)ほど、NetApp-Tはより多くのホスト資源を獲得し、スループット(左)とメモリ帯域の取り分(右)が増加する。レベル0の43Gbpsからレベル4の約100Gbpsまでスループットが向上する。Source: Adapted from Figure 9.) ### ネットワーク資源配分(§3.3) ホスト輻輳がありネットワークトラフィックが目標帯域を超えて送信している場合、hostCCのホストローカル輻輳応答は何もアクションを取らず、代わりにホスト輻輳シグナルをネットワーク輻輳制御プロトコルへエコーする。これにより(1) ホストローカル輻輳応答がサブRTT粒度のホスト輻輳を扱い、ネットワーク輻輳制御がRTT粒度のネットワーク輻輳を扱うという関心の分離が実現し、(2) hostCCは任意のネットワーク輻輳制御プロトコルと統合できる(プロトコルはホストとネットワーク両方の輻輳シグナルを資源配分に用いるだけでよい)。 ### 実装(§4) hostCCはLinuxのロード可能なカーネルモジュールとして約800LOCで実装され、Intel Cascade Lakeアーキテクチャで検証された(AMDアーキテクチャも概念的に類似)。IIO占有量のモデル固有レジスタ(MSR)をTSCレジスタとインラインアセンブラで読み取り、EWMA(重み$1/8$、$B_S$は$1/256$)で平滑化する。ネットワーク資源配分についてはECNベースのプロトコルに焦点を当て、`ip_recv`フックとNetFilterモジュールを利用してIPレイヤでDSCPの2ビット(RFC 3168準拠)にECNマーキングを行い、ACKに乗せて送信側へエコーする。 ## 新規性 古典的輻輳制御研究は「end-to-end」の終端をNICと解釈し、NIC-CPU/メモリ間のホストネットワークを不可視の領域として扱ってきた。既存のネットワーク輻輳制御プロトコル(TIMELY・DCTCP・HPCC等)やホストスタック最適化研究(Snap・TASなど)は、それぞれネットワークファブリック輻輳か非効率なソフトウェアによる計算ボトルネックのいずれかのみを対象とし、ホスト輻輳を扱う設計を持たない。本論文が参照するGoogleの実測研究(Agarwal+, HotNets 2022, "Understanding Host Interconnect Congestion")は、最先端の輻輳制御プロトコルSwiftとユーザ空間ネットワークスタックSnapを用いてもなお、本番クラスタでホスト輻輳による顕著なキューイング・パケットドロップ・スループット劣化・テールレイテンシ増大が生じることを示した(この論文自体はwiki未収載。関連する後続研究として[[@2024__SIGCOMM__Understanding the Host Network]]がホストネットワーク内競合の抽象化を提示している)。hostCCはこの現象に初めて体系的に対処する輻輳制御アーキテクチャであり、「ホストとネットワーク両方の資源を輻輳点で競合するエンティティ間に配分する」という、古典的輻輳制御の概念的解釈をホストネットワークへ拡張した点が新規性である。 ## 実験設定 - **ハードウェア**: 4ソケット(NUMAノード)サーバー、ソケットあたりIntel Cascade Lake CPUコア8個、100Gbps Mellanox CX5 NIC(128Gbps PCIe 3.0で1ソケットに接続)、DDR4 DIMM(2メモリチャネル、理論最大容量375Gbps=46.9GBps)。Linuxカーネル5.4.0、4K MTU、TSO/GRO等の最適化を有効化。 - **アプリケーション**: NetApp-T(4本の長フロー、iperfで生成、100Gbps NIC飽和にはDCTCPで最低4コア必要)、NetApp-L(128B〜32KBのレイテンシ重視RPC、netperfで生成)、MApp(1:1読み書き比・逐次アクセスパターンのCPU-メモリトラフィック、MLCで生成、1×〜3×のコア数でメモリインターコネクトへの負荷を増加)。 - **比較対象**: DCTCP単体 vs DCTCP+hostCC。DDIO有効/無効の両方で評価。 - **評価指標**: ネットワークスループット(Gbps)、パケットドロップ率(%)、メモリ帯域利用率、テールレイテンシ({P50, P90, P99, P99.9, P99.99})。 ## 実験結果 **ホスト輻輳の基礎的影響(§2.2)** **Figure 2: ホスト輻輳による性能劣化** ![[_attachments/Host-Congestion-Control/fig02-host-congestion-degradation.png]] (Figure 2. (左)ホスト輻輳はパケットドロップ率とスループットの両面で顕著な性能劣化を招く(ネットワーク輻輳がなくても)。DDIOは多少緩和するが同様の劣化を示す。(右)MApp(ホストローカルトラフィック)がメモリ帯域の大部分を占有し、NetApp-Tに残る帯域はわずかになる。3倍のホスト輻輳下でも0.3%のドロップを観測。Source: Adapted from Figure 2.) **Figure 3: MTUサイズ・フロー数による悪化** ![[_attachments/Host-Congestion-Control/fig03-mtu-flows-impact.png]] (Figure 3. 3倍のホスト輻輳下で、大きなMTUサイズと多数のフローはドロップ率をさらに悪化させる。DDIO有効時はDDIO無効時よりも悪化が顕著(キャッシュエビクション率の増加が原因)。Source: Adapted from Figure 3.) **Figure 4: 桁違いのテールレイテンシ劣化** ![[_attachments/Host-Congestion-Control/fig04-tail-latency-inflation.png]] (Figure 4. NetApp-T・NetApp-L・MAppを同時実行(DDIO無効・3倍のホスト輻輳)した際、NetApp-LのP99レイテンシはNICキューイング遅延とCPU処理遅延の増加で60〜100µs増、P99.9レイテンシは再送タイムアウト(デフォルトLinux最小RTO=200ms)で大幅に悪化する。RPCサイズが小さいほどタイムアウトの影響を受けやすく、大きいRPCではTail Loss Probe(TLP)機構が有効に働く。Source: Adapted from Figure 4.) **hostCCの効果(§5.1)** **Figure 10: hostCCによる目標帯域達成とドロップ削減** ![[_attachments/Host-Congestion-Control/fig10-hostcc-throughput-drops.png]] (Figure 10. (左)hostCCは高いホスト輻輳下でも目標ネットワーク帯域$B_T=80$Gbpsを達成しつつパケットドロップ率を桁違いに削減する。(右)hostCCを用いるとMAppはホスト輻輳が高くてもメモリ帯域の大部分を独占しなくなる。Source: Adapted from Figure 10.) **Figure 11: MTU・フロー数を通じた一貫性** ![[_attachments/Host-Congestion-Control/fig11-mtu-flows-hostcc.png]] (Figure 11. 3倍のホスト輻輳下でも、hostCCは評価した全てのMTUサイズ・フロー数にわたって一貫した恩恵を維持する。Source: Adapted from Figure 11.) **Figure 12: 最小限のテールレイテンシ劣化** ![[_attachments/Host-Congestion-Control/fig12-hostcc-tail-latency.png]] (Figure 12. 3倍のホスト輻輳下でも、hostCCはホスト輻輳なし時と比べて最小限のレイテンシ劣化に抑え、全RPCサイズでテールレイテンシを大幅に改善する。128B RPCでは13µsという僅かな劣化に留まる(P99.9でもタイムアウトが観測されない)。Source: Adapted from Figure 12.) **ネットワーク輻輳との共存(§5.1)** **Figure 13: ネットワーク輻輳・ホスト輻輳双方の下での性能** ![[_attachments/Host-Congestion-Control/fig13-network-and-host-congestion.png]] (Figure 13. (左)ネットワーク輻輳のみ・ホスト輻輳なしの場合、hostCCはネットワーク輻輳制御単体とほぼ同等の性能を示しオーバーヘッドが最小限であることを示す。(右)ホスト輻輳とネットワーク輻輳が両方存在する場合、hostCCはFigure 10と同様の恩恵を一貫して提供する。Source: Adapted from Figure 13.) **DDIO有効時の結果(§5.2)** **Figure 14: DDIO有効時のスループット改善** ![[_attachments/Host-Congestion-Control/fig14-ddio-enabled-throughput.png]] (Figure 14. DDIO有効時もFigure 10のDDIO無効時と同様の恩恵を提供する。ただし高いホスト輻輳下ではhostCCの絶対的なドロップ率がDDIO無効時よりやや高い(それでもhostCCなしと比べ約37倍の削減)。Source: Adapted from Figure 14.) **Figure 15: DDIO有効時のレイテンシ改善** ![[_attachments/Host-Congestion-Control/fig15-ddio-enabled-latency.png]] (Figure 15. DDIO有効時のレイテンシ改善はFigure 12のDDIO無効時とほぼ同一。両ケースとも3倍のホスト輻輳下で同程度のドロップ率を観測するため。Source: Adapted from Figure 15.) **感度分析(§5.3)** **Figure 16: 目標帯域$B_T$への感度** ![[_attachments/Host-Congestion-Control/fig16-target-bandwidth-sensitivity.png]] (Figure 16. hostCCは$B_T$の全評価値にわたって目標帯域達成と最小限のドロップ率という恩恵を一貫して維持する。小さい$B_T$ではNIC到着レートがPCIe帯域利用率を下回るためドロップが特に低く、大きい$B_T$では$R-B_T$が小さくNICバッファが埋まるまでの時間的猶予が大きいためドロップが低い。Source: Adapted from Figure 16.) **Figure 17: 閾値$I_T$への感度** ![[_attachments/Host-Congestion-Control/fig17-iio-threshold-sensitivity.png]] (Figure 17. (左)$I_T$を大きくすると輻輳発生への反応が遅れ、ドロップ率が増加する。(右)$I_T$を大きくするとMAppはより大きなメモリ帯域を獲得する(バックプレッシャーが緩やかになるため)。Source: Adapted from Figure 17.) **3つのアイデアの必要性検証(§5.4)** **Figure 18: hostCCの3つの技術アイデアの必要性** ![[_attachments/Host-Congestion-Control/fig18-necessity-of-three-ideas.png]] (Figure 18. ホストローカル輻輳応答を用いない場合、パケットドロップ率は最小化できるがスループットは約28Gbpsに劣化する((a) Necessity)。(b) エコーのみでは輻輳シグナルへの反応が遅くPCIe帯域が目標に届かない。(c) ホストローカル応答のみではNICバッファの蓄積を防げない。(d) 両方を併用した既定のhostCCの挙動が、PCIe帯域を目標に近づけつつIIO占有量を閾値未満に保つ。Source: Adapted from Figure 18.) **Figure 19: 定常状態でのhostCC挙動** ![[_attachments/Host-Congestion-Control/fig19-steady-state-behavior.png]] (Figure 19. 250µsの時間軸でのスナップショット。(a) PCIe書き込み帯域は$B_T=80$Gbps(PCIeレベルオーバーヘッドを含めると84Gbps、緑線)付近を維持する。(b) ホストローカル応答レベルはレベル3(約77Gbps)とレベル4(約100Gbps)の間を振動する。(c) IIO占有量は§3.2のロジックに従い閾値$I_T$(赤線)付近で切り替わる。Source: Adapted from Figure 19.) ## 考察 hostCCは、ホスト輻輳という新しい輻輳形態に対し、既存のネットワーク輻輳制御プロトコルへの変更を最小限に留めながら統合可能な設計を実現した。3つの技術アイデア(サブマイクロ秒粒度のホスト輻輳シグナル、サブRTT粒度のホストローカル応答、RTT粒度のネットワーク資源配分)がそれぞれ独立して必要であることをFigure 18で実証しており、単一の応答機構だけでは高スループットと低ドロップ率を同時に達成できない。 著者らは既存のホスト資源配分ツール(Intel MBA)の限界を指摘する。MBA MSRレジスタへの書き込みには約22µsを要し(ネットワークRTTの半分程度)、より細粒度の応答を妨げる。また応答レベルの効果が非線形かつ粗粒度であり、Figure 9で見たように、レベル3から4への切り替えでNetApp-Tが得る5.2GBpsの帯域増加に対しMAppは13.8GBpsもの帯域を失うという過剰なバックプレッシャーが生じる。 新技術(RDMA・CXL)による解決可能性についても議論している。RDMA自体はホスト輻輳を扱わない(本論文が参照するLi+ 2022, "From RDMA to RDCA"の指摘)。CXLについては、PCIe-IIO間レイテンシ($\ell_p$)の削減はメモリインターコネクト輻輳($\ell_m$、本質的な問題)を緩和しないため効果が不明瞭であり、CXLメモリ拡張の利用可能性は将来課題として残す。IOMMUに起因するホスト輻輳(メモリ保護のためのハードウェア構成要素のボトルネック)についても、ATSのような新技術が役立つ可能性はあるが、さらなる研究が必要と述べる。 ## 強み / 弱点・課題 **強み** - 実測(§2)により「ホスト輻輳」という新現象を明確に定義し、既存の輻輳制御研究の暗黙の前提(輻輳点でドロップが起きる、競合トラフィックは輻輳制御プロトコルに従う)がホスト輻輳下で崩れることを具体的に示した。 - アプリケーション・ホストハードウェア・ネットワークハードウェアいずれの変更も不要という実装上の制約を満たしながら、既存の輻輳制御プロトコル(DCTCP)に統合可能な設計を実現した。 - Figure 18のアブレーションにより、3つの技術アイデアそれぞれの必要性を個別に実証している。 **弱点・限界** - ホスト資源配分に用いるIntel MBAツールの書き込みレイテンシ(約22µs)と非線形・粗粒度な応答特性が、hostCCの応答速度と精度の上限を制約している。著者ら自身がこれを§6で明記する。 - 高いホスト輻輳下でのDDIO有効時のパケットドロップ率がDDIO無効時よりわずかに高い理由について、DDIO関連ハードウェア動作(キャッシュエビクションポリシー等)への可視性不足のため未解明のまま残されている。 - 評価はIntel Cascade Lakeサーバー・単一スイッチ接続の2台構成という限定的なハードウェア・トポロジで行われており、著者らが述べる「PCIe 4.0・4倍コア数・4倍メモリ帯域」を持つ最新世代サーバーやマルチホップトポロジでの検証は将来課題として残る。 - IOMMU起因のホスト輻輳(PCIeのメモリ保護ハードウェアによる過小利用)は本論文の主要な評価対象に含まれておらず、追加の輻輳シグナルが必要と明記されている。