> [!abstract] 概要(APNet 2024 abstract の日本語訳) > RDMAは商用データセンターに広く展開されている。従来の通念では、ホスト内ネットワークは安定した高性能を提供すると考えられてきた。しかし、進化を続けるRDMA NIC(RNIC)と比較して、ホスト内資源は技術トレンドとして相対的に停滞している。そのため、RNICトラフィックがホスト内トラフィックと競合する際に十分なホスト内資源を得られないことがある。大規模商用データセンター事業者による一連の最近の研究は、ホスト内輻輳とそれに伴う性能崩壊の出現を示しており、これはホスト内輻輳制御の実践を再考することを我々に迫る。しかし、RDMAホスト内ネットワークを効率的に制御する能力は、ホスト間ネットワークほど成熟していない。これは輻輳の監視、ホスト内資源配分、RNICトラフィック調整において課題をもたらす。本論文では、RDMA intra-Host Congestion Control(RHCC)を提案する。これはサブRTT粒度のホスト内トラフィック輻輳回避と、能動的なRNICトラフィック調整を組み合わせるものである。我々はRHCCを商用サーバとRNIC上に実装し、性能を評価する実験を行った。結果は、RHCCがネットワークスループット/レイテンシをそれぞれ最大2倍/1.4倍増加/減少させられることを示す。 ## 論文情報 - タイトル: Rethinking Intra-host Congestion Control in RDMA Networks - 著者: Zirui Wan([[BUPT]] / [[China Mobile (Suzhou) Software Technology]])、Jiao Zhang([[BUPT]] / [[Purple Mountain Laboratories]]、責任著者)、Yuxiang Wang([[BUPT]])、Kefei Liu([[BUPT]])、Haoyu Pan([[BUPT]])、Tao Huang([[BUPT]] / [[Purple Mountain Laboratories]])。全員 State Key Laboratory of Networking and Switching Technology, BUPT に所属。 - 媒体・発表年: The 8th Asia-Pacific Workshop on Networking(APNet 2024)、2024年8月3〜4日、Sydney, Australia。ACM刊、全7ページ(pp. 31-37)。 - DOI: [10.1145/3663408.3663413](https://doi.org/10.1145/3663408.3663413) - ISBN: 979-8-4007-1758-1/24/08 - 資金提供: 中国国家重点研究開発計画(Grant No. 2022YFB2901700)、山東省自然科学基金(Grant No. ZR2023LZH011)、国家自然科学基金(NSFC、Grant No. 62132022, 62372053) ## 概要 本論文は、進化の速いRNIC線速(25Gbps→200Gbps)と相対的に停滞するホスト内資源(PCIe帯域: 63Gbps→256Gbps、メモリ帯域)とのギャップから生じる「ホスト内輻輳」がRDMAネットワークの性能を大きく損なうことを実測で確認し、これに対処するRHCC(RDMA intra-Host Congestion Control)を提案する。RHCCは、受信側がIIOバッファ占有量をサブRTT粒度で監視しIntel MBAでホスト内資源を配分する仕組みと、送信側がMellanoxのProgrammable Congestion Control(PCC)によるプローブ機構で受信処理遅延を測定しRNICトラフィックの送信レートを能動的に調整する仕組みを組み合わせる。[[@2023__SIGCOMM__Host Congestion Control]](hostCC、TCPネットワーク向け)の設計思想をRDMAネットワークへ拡張したものであり、RDMAの受信側カーネルモジュールがデータパケットを直接改変できないという制約に対し、PCCのプローブ機構で代替する点が新規性である。 > [!note] 拡張ジャーナル版 > 本論文には IEEE Transactions on Networking 2025 掲載の拡張ジャーナル版 [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]] が存在する。中核設計・主要実験数値に矛盾はなく、著者にYongchen Panが追加され、cross-NUMA実測の拡充・収束性の理論的解析(§III-C)・hostCCとの体系的な優位性比較(§III-D)・パラメータ感度分析(§IV-C)・考察(§V)が新たに加わっている。詳細な差分は ToN 版ページ末尾の「APNet 2024版との関係」節を参照。 ## 問題設定 - **入力**: RNICが受信するRDMAトラフィック(ホスト間ネットワークを経由)、ホスト内で競合するCPU-to-メモリトラフィック(他のRNIC・GPU・SSDなどのPCIeデバイスが生成)、既定のホスト間輻輳制御アルゴリズム(本実装ではDCQCN)。 - **出力**: (1) 受信側でのホスト内資源(メモリ帯域)配分ポリシー、(2) 送信側でのRNICトラフィック送信レート。 - **前提**: ホスト内ネットワーク(RNIC-to-IIO、IIO-to-メモリコントローラ間の相互接続)はクレジットベースのフロー制御を用いるロスレスなファブリックである。商用RNIC(Mellanox ConnectX-6 DX以降)はDPU(BlueField-2/3)にも拡張されたPCCプログラマビリティを持ち、受信側でパケットを受信した時刻のハードウェアタイムスタンプを取得できる。RDMAの受信側カーネルモジュールはデータパケットを直接改変できない(ECNビットのマーキングなどが不可能)という制約がある。 ## 提案手法 ### アーキテクチャ **Figure 5: RHCCフレームワークの概要** ![[_attachments/Rethinking-Intra-host-Congestion-Control-in-RDMA-Network/fig05-rhcc-framework.png]] (Figure 5. 受信側(Receiver)のCPUソケットは①監視(Monitoring)でIIOバッファ占有量を、②資源配分(Allocating Resources)でIntel MBAによるホスト内資源配分を行う。送信側(Sender)は❶プローブパケット(probe)を送出し受信側でタイムスタンプ(ts)を付与されたACKを受け取り、❷そのタイムスタンプ差分から受信処理遅延を計算してレートを更新(Updating Rate)する。Source: Adapted from Figure 5.) RHCCは「サブRTT粒度のホスト内トラフィック輻輳回避」と「能動的なRNICトラフィック調整」の2つの機構を組み合わせる。受信側はIIOバッファ占有量というホスト内輻輳シグナルを常時監視し、ホスト内トラフィックへの資源配分を調整する。同時に送信側は32KBデータパケットごとにプローブパケットを送出し、受信側がプローブパケットを受信した時刻のタイムスタンプ(ts)を取得してACKで送信側に返す。送信側はこのタイムスタンプから受信処理遅延を計算し、送信レートを更新する。 ### アルゴリズム/手法の詳細: ホスト内トラフィック輻輳応答 [[@2023__SIGCOMM__Host Congestion Control]](hostCC)に着想を得て、RHCCもIIO(Integrated I/O Controller)バッファ占有量をホスト内輻輳シグナルとして用いる。理由は3点: (1) メモリインターコネクト輻輳が発生した瞬間にのみIIOバッファ占有量が増加するため、根本原因と規模を正確かつ即時に示す。(2) 商用Intel CPUのハードウェアレジスタでサブRTT粒度で監視でき、追加のハードウェア変更が不要(RNICバッファ占有量など他の輻輳シグナルの取得はRNICベンダーの協力を要し困難)。(3) 監視プロセスはRNICトラフィックのデータパスから独立しているため、ホスト内輻輳自体に影響を与えない(著者らのサーバでの実測では監視レイテンシは輻輳の有無にかかわらず約400ns)。 RHCCはIntel Model Specific Registers(MSR)を用いてIIO占有量の累積値を読み取り、瞬時占有量$I_{cur}$を2回の読み取り値の差分として計算し、目標閾値$I_{thr}$と比較する($I_{cur} > I_{thr}$で輻輳と判定)。ホスト内資源配分ツールの制約から、RHCCもhostCCに倣い粗粒度な多段階配分ポリシーを用いる。著者らのサーバではIntel MLCで計測した総メモリ帯域33.2GBpsを基準に、33.2/26.5/20.0/15.0/10.0GBpsの5段階を設定し、第3レベル(20GBps)がRNICトラフィックに十分な残余メモリ帯域を提供するとした。輻輳時はレベルを下げて帯域浪費を防ぐ。資源配分の実施にはIntel Resource Director Technology(RDT)のMemory Bandwidth Allocation(MBA)ツールを用いる。 ### アルゴリズム/手法の詳細: RNICトラフィック輻輳応答 RDMA受信側カーネルモジュールがデータパケットを直接改変できない(既存機構hostCCが受信側でECNビットをマークしようとしても展開不能)という制約(Challenge #3)に対し、RHCCはMellanoxが提供するProgrammable Congestion Control(PCC)のプローブ機構を利用する。PCCを選ぶ理由は3点: (1) 受信側RNICデータパス全体にわたるホスト内バックプレッシャーの規模を反映でき、RNIC PCIe輻輳とメモリインターコネクト輻輳の両方を扱える。(2) プローブ機構はデータパケットを改変しないため上位アプリケーションに透過的。(3) PCCは自己定義の輻輳制御ロジックを許すため、商用データセンターで採用されている多様なホスト間輻輳制御機構に適応できる。 新しく受信したプローブACKごとに、送信側は受信処理遅延$D_{cur}$を測定する。ホスト内トラフィック輻輳応答と同様に目標遅延$D_{thr}$を計算し($D_{cur} > D_{thr}$で輻輳と判定)、受信プロセスに適用可能なレート$R_{rev}$を次式で計算する。 $R_{rev} = R_{rev} \times [1 - \alpha \times (D_{cur} - D_{thr}) - \beta \times (D_{cur} - D_{old})] \quad (1)$ ここで$D_{old}$は前回ラウンドの受信遅延であり、$R_{rev} \geq 0$を保証する。RHCCはこの調整にAIMD(パラメータ固定)ではなくPID(Proportional Integral Derivative)ベースの調整を用い、誤差に基づく較正と微分による規制項によって受信側の実時間状態に応じて動的に適応する。 さらにRHCCは受信プロセスレートを、既存のホスト間輻輳制御手法が計算する送信レートと組み合わせ、実際の送信レート$R_{trans}$を次式で決定する。 $R_{trans} = \min(R_{rev}, R_{cc}) \quad (2)$ ここで$R_{cc}$はデプロイされたホスト間輻輳制御アルゴリズムが計算するレートである。これによりRHCCはホスト間ネットワーク輻輳を扱いつつ、異なるホスト間制御手法とともにデプロイでき、RNICトラフィック間でmax-min公平性を達成する。 ### 実装上の工夫 受信側RHCCは、[[@2023__SIGCOMM__Host Congestion Control]]のオープンソース実装(hostCC)をベースにした約500行のCコードで書かれたロード可能なLinuxカーネルモジュールとして実装した。送信側RHCCはMellanoxのPCCフレームワーク上に実装し、DCQCNと組み合わせた。RHCCは32KBデータパケットごとに1つのプローブパケットを生成し(ネットワークオーバーヘッドと制御粒度のトレードオフ)、輻輳が無い場合の受信処理遅延120ns、輻輳時は約900nsという実測に基づき、$D_{thr}=200ns$、$\alpha=0.0005$、$\beta=0.0005$(単位はナノ秒)を設定した。ホスト間輻輳制御にはデフォルトのDCQCNを用いた。 ## 新規性 既存のホスト内輻輳研究([[@2023__SIGCOMM__Host Congestion Control]]、Alibaba・ByteDanceの実測研究)は主にTCPネットワークまたは診断([[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]]など)を対象とし、RDMAネットワーク向けの能動的な制御機構は未確立だった。RHCCの新規性は3点。第一に、Challenge #1(古典的輻輳シグナルが実際の輻輳点から離れている——ロスレスファブリックであるため)に対し、hostCCと同じIIOバッファ占有量シグナルをRDMAコンテキストへ転用した。第二に、Challenge #2(標準的なホスト内資源配分ツールが複雑な配分関数をサポートしない)に対し、hostCCと同じくIntel MBAの多段階粗粒度配分を採用した。第三に、Challenge #3(RDMA受信側カーネルモジュールがデータパケットを直接改変できないため既存機構hostCCのECNマーキング方式が展開不能)に対しては、hostCCにない新しい解決策として、商用RNIC(ConnectX-6 DX)とDPU(BlueField-2/3)が提供するPCCプログラマビリティを利用したプローブベースの遅延測定機構を導入した。この点がhostCCからの本質的な拡張であり、RDMA特有の制約に対する解と言える。 ## 実験設定 - **ハードウェア環境**: Dell R740サーバ2台を1台のスイッチで接続。各サーバはデュアルIntel Xeon 6240 CPU、Mellanox ConnectX-6 DX 100Gbps RNIC(128Gbps PCIe 3.0 x16接続)、DDR4メモリチャネル2本、DDIO有効(4MBキャッシュウェイ)を搭載。著者らはこの構成が最新商用サーバと同一のホスト内資源比率を持つとし、スケーリング(例: 256Gbps PCIe 4.0サーバなら2倍のRNIC帯域を持つ)によりByteDanceのCollie論文が記述する構成とも対応づけられるとする。 - **測定ツール**: 標準ベンチマークツールMellanox Perftestでデータ転送しスループット・レイテンシを測定。Intel Memory Latency Checker(MLC)で1:1読み書き比のCPU-to-メモリトラフィックを生成しメモリ帯域消費を1倍〜3倍(19.0GBps・25.3GBps・30.3GBps)に変化させる。Intel Performance Counter Monitor(PCM)でメモリ帯域利用率とPCIe write hit/miss数(DDIOの有効性指標)を測定。NVIDIA NEO-HostツールでPCieのoutbound stalled write requests数(PCIeからRNICへのバックプレッシャー)を測定。 - **比較対象**: PFC-enabled環境とPFC-free環境それぞれで、w/o RHCC(既定のDCQCNのみ)とw/ RHCCを比較。 - **評価指標**: (i) ホスト間トラフィックスループット、(ii) ホスト間トラフィックレイテンシ、(iii) 正規化PFC一時停止時間、(iv) 正規化PCIeバックプレッシャー(outbound stalled write requests)。 ## 実験結果 ### ホスト内輻輳の基礎的影響(§2.2) **Figure 1: ホスト内ネットワークのアーキテクチャ** ![[_attachments/Rethinking-Intra-host-Congestion-Control-in-RDMA-Network/fig01-architecture.png]] (Figure 1. コモディティIntelサーバのホスト内ネットワーク例。CPUソケット内のCore・LLC/CHAはメッシュ相互接続で結ばれ、UPIがソケット間相互接続、Memory Controllerがメモリアクセスを、Integrated IO(IIO)がRNIC/GPU/SSDなどのPCIeデバイスからのトラフィックを管理する。SSD・RNIC・GPUはPCIeドメインに接続され、RNICはInter-host Networkへつながる(AMDも類似構成)。Source: Adapted from Figure 1.) **Figure 2: 異なるホスト内輻輳度合いでのネットワーク性能** ![[_attachments/Rethinking-Intra-host-Congestion-Control-in-RDMA-Network/fig02-congestion-perf.png]] (Figure 2. (a)受信スループット・(b)ネットワーク平均レイテンシ・(c)ネットワーク99パーセンタイルレイテンシ・(d)平均PFCおよびCNP数を、輻輳度合い0x〜3xで測定。0xが最良の性能を示し、輻輳度合いの増加とともにスループットが低下・レイテンシが増加する。3xケースでは、PFC有効/PFC-free環境でそれぞれスループットが62%/68%低下し、平均レイテンシが2.4倍/2.6倍に増加した。PFC一時停止時間・CNP数も輻輳度合いの増加とともに著しく増加した。Source: Adapted from Figure 2.) **Figure 3: PCIeバックプレッシャーとDDIOミス率** ![[_attachments/Rethinking-Intra-host-Congestion-Control-in-RDMA-Network/fig03-pcie-backpressure-ddio.png]] (Figure 3. (a)正規化PCIe outbound stalled write requestsは輻輳度合いの増加とともに著しく増加し、観測された性能劣化の根本原因が高いメモリ帯域競合(RNICが十分なホスト内資源を獲得できない)であることを示す。(b)DDIOミス率も輻輳度合いの増加とともに上昇する。キャッシュラインエビクションにはメモリ書き戻しのための十分なメモリ帯域が必要であり、高レベルのホスト内輻輳下ではDDIOの書き込み割り当てが減速するためである。Source: Adapted from Figure 3.) **Figure 4: メッセージサイズ・QP数によるスループット変化** ![[_attachments/Rethinking-Intra-host-Congestion-Control-in-RDMA-Network/fig04-throughput-msgsize-qp.png]] (Figure 4. 3倍のホスト内輻輳下で、(a)メッセージサイズ(64KB〜1MB)・(b)QP数(1〜8)を変化させるとスループットはわずかに増加する。大きなメッセージサイズ・QP数はin-flightパケット数を増やしRNICトラフィックへのメモリ帯域消費を高めるためだが、その恩恵はわずかであり、大きなメッセージサイズはDDIO割り当てキャッシュ内でより大きな空間を要求するため、leaky DMA問題を悪化させる。Source: Adapted from Figure 4.) ### RHCCの効果(§4) **Figure 6: RHCCの効果(PFC-enabled環境)** ![[_attachments/Rethinking-Intra-host-Congestion-Control-in-RDMA-Network/fig06-rhcc-results.png]] (Figure 6. PFC-enabled環境において、(a)受信スループット・(b)ネットワーク平均レイテンシ・(c)平均PFC一時停止時間・(d)正規化PCIeバックプレッシャーを輻輳度合い0x〜3xでw/o RHCCとw/ RHCCで比較。RHCCはPCIeスタール書き込み要求を1x/2x/3xの輻輳ケースでそれぞれ80%/93%/97%削減し、RNICトラフィックが十分なホスト内資源を獲得できるようにしてホスト間輻輳制御機構の発動を緩和する。PFC一時停止時間は3x輻輳ケースで最大64%削減され、その結果ネットワークスループット/平均レイテンシは3x輻輳ケースで最大2倍/1.4倍改善する。PFC-free環境でも同様の傾向が確認されたため省略している。Source: Adapted from Figure 6.) ## 考察 RHCCはhostCCの設計思想(IIOバッファ占有量による輻輳検知とサブRTT粒度のホストローカル応答)をRDMAという異なるプロトコル環境へ移植する際に生じる制約——RDMA受信側カーネルモジュールがデータパケットを直接改変できないこと——を、商用RNICのPCCプログラマビリティを利用したプローブ機構で解決した点に工学的な独自性がある。実験結果は、ホスト内輻輳への対処がRNIC PCIeバックプレッシャーを大幅に削減するだけでなく、副次的にホスト間輻輳制御(PFC発動)の頻度も緩和することを示しており、ホスト内輻輳とホスト間輻輳が独立ではなく連鎖的に発生することを裏付けている。 一方で、著者らは§5(Discussion and Future Work)で複数の未解決課題を挙げている。RHCCが依拠するIntel MBAは複雑な配分関数をサポートせず粗粒度な多段階制御にとどまる。RNIC自体のオンチップSRAM制約によるICMキャッシュミス(QP数がスケールした際に生じる別種のホスト内輻輳、[[SRNIC]]が対処)はRHCCの対象外であり相補的な関係にあるとする。DDIOのleaky DMA問題への新たな最適化機構や、CXLによる新しいホスト内アーキテクチャがホスト内輻輳制御に与える影響は未検証のまま将来課題として残されている。 ## 強み / 弱点・課題 **強み** - RDMAネットワークにおけるホスト内輻輳の実測(§2.2)により、PFC有効/PFC-free双方の環境で最大68%のスループット低下・2.6倍のレイテンシ増加という定量的な性能崩壊を確認し、既存のTCP向けhostCC研究をRDMAコンテキストへ拡張する動機を明確に示した。 - Challenge #3(RDMA受信側カーネルモジュールがデータパケットを直接改変できない)という、RDMA特有の制約に対しPCCプローブ機構という具体的な工学的解決策を提示した。 - 商用サーバ・商用RNIC(Mellanox ConnectX-6 DX)上への実装(受信側約500行・送信側PCCフレームワーク上)により実用性を示し、追加のハードウェア変更なしで既存のホスト間輻輳制御プロトコル(DCQCN)と共存可能な設計を実現した。 **弱点・限界** - ワークショップ論文(APNet、7ページ)のため、評価は2台構成のテストベッド・単一のRNIC世代(ConnectX-6 DX、100Gbps)に限定されており、[[@2023__SIGCOMM__Host Congestion Control]]のような多角的な感度分析(目標帯域・閾値への感度、3つの技術要素の必要性のアブレーション実験など)は行われていない。 - Intel MBAの粗粒度な資源配分という限界(5段階のみ)は著者ら自身が認めており、より細粒度なホスト内資源配分ハードウェア支援が実現するまでRHCCの応答精度には上限がある。 - 評価はDCQCNとの組み合わせのみで報告されており、HPCC・TIMELYなど他のホスト間輻輳制御アルゴリズムとの組み合わせでの実測は示されていない(設計上は対応可能とされるが実証はない)。 - PFC-free環境での結果は「PFC有効環境と同様の傾向」とのみ述べられ、具体的な数値・図表は示されていない(§4本文で明示的に省略)。