> [!abstract] 概要(IEEE Transactions on Networking 2025 abstract の日本語訳) > RDMAは商用データセンターに広く展開されている。従来の通念では、ホスト内ネットワークは安定した高性能を提供すると考えられてきた。しかし、進化を続けるRDMA NIC(RNIC)と比較して、ホスト内資源は技術トレンドとして相対的に停滞している。そのため、RNICトラフィックがCPU-to-メモリトラフィックと競合する際に十分なホスト内資源を得られないことがある。大規模商用データセンター事業者による一連の最近の研究は、ホスト内輻輳とそれに伴う性能崩壊の出現を示しており、これはホスト内輻輳制御の実践を再考することを我々に迫る。しかし、RDMAホスト内ネットワークを効率的に制御する能力は、ホスト間ネットワークほど成熟していない。これは輻輳の監視、ホスト内資源配分、RNICトラフィック調整において課題をもたらす。本論文では、サブRTT粒度のホスト内トラフィック輻輳回避と能動的なRNICトラフィック調整を組み合わせるRDMA intra-Host Congestion Control(RHCC)を提案する。我々はRHCCを商用サーバとRNIC上に実装し、性能を評価する実験を行った。結果は、RHCCがネットワークスループット/レイテンシをそれぞれ最大2倍/1.4倍増加/減少させられることを示す。 ## 論文情報 - タイトル: RHCC: Revisiting Intra-Host Congestion Control in RDMA Networks - 著者: Zirui Wan([[BUPT]]、Graduate Student Member IEEE)、Jiao Zhang([[BUPT]] / [[Purple Mountain Laboratories]]、Senior Member IEEE、責任著者)、Yuxiang Wang([[BUPT]])、Kefei Liu([[BUPT]])、Haoyu Pan([[BUPT]])、Yongchen Pan([[BUPT]])、Tao Huang([[BUPT]] / [[Purple Mountain Laboratories]]、Senior Member IEEE)。Zirui Wan・Yuxiang Wang・Kefei Liu・Haoyu Pan・Yongchen Pan は State Key Laboratory of Networking and Switching Technology, BUPT に所属。Jiao Zhang と Tao Huang は同研究室に加え Purple Mountain Laboratories(南京)にも所属する。 - 媒体・発表年: IEEE Transactions on Networking, Vol. 33, No. 3, June 2025(pp. 1189–1201)。2024年7月30日投稿、2024年12月23日採択、2025年1月7日オンライン公開。 - DOI: [10.1109/TON.2024.3524247](https://doi.org/10.1109/TON.2024.3524247) - 資金提供: 中国国家重点研究開発計画(Grant 2022YFB2901700)、国家自然科学基金(NSFC、Grant 62132022)、山東省自然科学基金(Grant ZR2023LZH011)、BUPT青年イノベーション研究チームプログラム(Grant 2024YQTD02)。 - 本論文は APNet 2024 の会議論文 [[@2024__APNet__Rethinking Intra-host Congestion Control in RDMA Networks]] の拡張ジャーナル版である。共通の中核設計(RHCCフレームワーク、CPU-to-メモリトラフィック輻輳応答、RNICトラフィック輻輳応答)を保ちつつ、著者に Yongchen Pan が加わり、§II-Bのcross-NUMA実測拡充・§III-Cの収束性解析(Convergence analysis)・§III-DのhostCCに対する体系的な優位性比較・§IV-CのRHCC感度分析(Ithr・Dthr)・§Vの考察(Discussion and Future Work)が新たに追加されている。両バージョンの詳細な差分は本ページ末尾の「APNet 2024版との関係」節を参照。 ## 概要 RDMAの線速がRNIC世代を追うごとに急伸する一方、PCIe帯域・メモリ帯域といったホスト内資源は相対的に停滞しており、RNICトラフィックがCPU-to-メモリトラフィックと競合するとホスト内輻輳が生じ、深刻な性能崩壊を招く。本論文は、この現象を自前のテストベッド実測で定量化したうえで、サブRTT粒度のCPU-to-メモリトラフィック輻輳回避と、能動的なRNICトラフィック調整を組み合わせるRHCC(RDMA intra-Host Congestion Control)を提案する。RHCCは商用サーバ・RNIC上に実装可能で、既存のホスト間輻輳制御プロトコル(DCQCN等)と共存しながらネットワークスループットを最大2倍、レイテンシを最大1.4倍改善する。 ## 問題設定 - **入力**: RDMAネットワークにおける受信側のホスト内輻輳シグナル(IIOバッファ占有量)、送信側から受信側への周期的なプローブパケットとそのACKに付与されるハードウェアタイムスタンプ。 - **出力**: 受信側でのCPU-to-メモリトラフィックに対するメモリ帯域配分レベル(5段階)、送信側でのRNICトラフィック送信レート。 - **前提条件**: 商用Intel/AMDサーバ(Intel MBA相当のメモリ帯域配分ツールを備える)、Mellanox ConnectX-6 DX以降のProgrammable Congestion Control(PCC)対応RNIC。RDMA受信側カーネルモジュールはデータパケットを直接改変できないという制約(hostCCのECN-bitマーキング方式がRDMAへ移植できない根本理由)。 ## 提案手法 ### アーキテクチャ **Figure 7: RHCCフレームワークの全体像** ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig07-rhcc-framework-overview.png]] (Figure 7. RHCCは受信側の「①監視」「②資源配分」(CPU-to-メモリトラフィック輻輳応答)と、送信側の「①プローブ送出」「②レート更新」(RNICトラフィック輻輳応答)を組み合わせる。受信側はIIOバッファ占有量をサブRTT粒度で継続監視しCPU-to-メモリトラフィックへ資源(メモリ帯域)を配分する。送信側は周期的にプローブパケットを送り、受信側がタイムスタンプ付きACKを返す往復から受信処理遅延を測定し、送信レートを更新する。Source: Adapted from Figure 7.) RHCCは2つの独立した輻輳応答ループから構成される。受信側で完結する「CPU-to-メモリトラフィック輻輳応答」(§III-B)と、送信側・受信側間のプローブ往復で完結する「RNICトラフィック輻輳応答」(§III-C)であり、両者は互いに独立に動作しつつ、最終的な送信レート計算(式(4))で統合される。 ### アルゴリズム/手法の詳細 **CPU-to-メモリトラフィック輻輳応答(Rationale #1・#2)** - **輻輳シグナル**: RHCCはIIOバッファ占有量を輻輳シグナルに選ぶ。理由は三つ:(1) メモリインターコネクト輻輳が起きたときに限り、かつ即座に増加する、(2) Intel CPUのモデル固有レジスタ(MSR)で追加ハードウェア支援なしにサブマイクロ秒粒度で監視できる、(3) 監視プロセスがRNICトラフィックのデータパスと独立しており輻輳自体に影響しない。瞬時IIO占有量$I_{cur}$は式(1)のEWMA(指数加重移動平均、重み$\gamma_{IIO}=0.25$)で算出する。 **Figure 8: MSR読み出しレイテンシの安定性** ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig08-msr-read-latency.png]] (Figure 8. 輻輳の有無にかかわらずMSR読み出しレイテンシは約400nsで安定しており、IIOバッファ占有量をホスト内輻輳から独立してサブRTT粒度で測定できることを示す。Source: Adapted from Figure 8.) **Figure 9: IIOバッファ占有量の変動** ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig09-iio-buffer-occupancy.png]] (Figure 9. 1msの時間窓でIIOバッファ占有量$I_{cur}$を測定すると、輻輳なしでは約20、1倍のホスト内輻輳下では約44まで増加する。2倍・3倍ではそれぞれ約68・94まで増加すると評価している。Source: Adapted from Figure 9.) - **輻輳検知**: 目標IIO占有量閾値$I_{thr}$を定め、$I_{cur} > I_{thr}$のとき輻輳が生じているとみなす単純な閾値判定を用いる。理由は、閾値ベースの機構がSwift・DCQCN・TIMELYなど古典的輻輳制御プロトコルで実績があり、かつ配分ポリシーとの組み合わせが容易なため。 - **資源配分**: Intel MLCで測定した総メモリ帯域33.2GBpsを基準に、CPU-to-メモリトラフィック向けに5段階(レベル1〜5=100%/80%/60%/40%/20%、実測33.2/26.5/20.0/15.0/10.0GBps)の粗粒度配分を設ける。理由は二つ:(1) MSR読み出し(約400ns)というナノ秒スケールの信号に対し複雑な配分計算をカーネルモジュール内で行うのは非現実的、(2) 商用のメモリ帯域配分ツール(Intel MBA)はそもそも1割刻み程度の粗粒度配分しかサポートしない。実際にMBAで精密なMB/s単位の割り当てを指定しても、応答は非線形かつ粗粒度なステップ状になることを実測で確認している。 **Figure 10: 輻輳応答レベルごとの効率** ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig10-congestion-response-efficiency.png]] (Figure 10. 3倍のホスト内輻輳下でレベル1→5と応答レベルを上げるにつれ、RNICトラフィックスループットは期待どおり段階的に増加し、CPU-to-メモリトラフィックは段階的に制限される。レベル4でRNICトラフィックは既に全速に達するが、より大きい総メモリ帯域や複数RNICを持つ商用サーバに備えレベル5も維持する。Source: Adapted from Figure 10.) **Figure 11: MBAの実際の割り当て挙動の非線形性** ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig11-mba-allocation-nonlinearity.png]] (Figure 11. Intel MBAでMB/s単位の精密な割り当てを指定しても、実際に得られる利用可能帯域は非線形かつ階段状(coarse-grained)にしか変化せず、RHCCの5段階配分方式と類似した挙動になる。DDR5 DIMM搭載機でも同様の結果を確認しており、この挙動がRAM世代に依存しないプラットフォーム固有の粒度制約であることを示す。Source: Adapted from Figure 11.) 実装は、Intel Resource Director Technology(RDT)のMemory Bandwidth Allocation(MBA)ツールを使い、CPUコアへの追加アクセスレイテンシを導入することでメモリ帯域を間接的に制限する。MBAは最大8個のMSRレジスタでCOS(Class-of-Service)グループを構成でき、local-NUMAコアとdistal-NUMAコアそれぞれに独立した5段階を設定する。輻輳が起きるとRHCCはまずcross-NUMAトラフィックの帯域をレベル4まで直接制限し(cross-NUMAトラフィックはキャッシュコヒーレンシコストが大きく輻輳を悪化させやすいため)、その後周期的にlocal-NUMAトラフィックの帯域を段階的に絞り込む「カスケード調整」を行う。輻輳が解消($I_{cur} \le I_{thr}$)すれば段階的に帯域を戻す。 **RNICトラフィック輻輳応答(Rationale #3)** - **輻輳シグナル**: RHCCはプローブ機構でRNICトラフィックを調整する。理由は四つ:(1) ハードウェアベースの正確なタイムスタンプが得られる、(2) 受信側RNICデータパス全体(RNIC PCIe輻輳・メモリインターコネクト輻輳の両方)にわたる背圧の規模を反映できる、(3) データパケット自体を改変しないため上位アプリケーションに透過的、(4) PCCは自己定義の輻輳制御ロジックを柔軟に実装でき、CX6/CX7・BlueField-2/3など新世代RNIC/DPUへの展開が進んでいる。 **Figure 12: 受信処理遅延の変動** ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig12-receiver-processing-delay.png]] (Figure 12. 100µsの時間窓で受信処理遅延$D_{cur}$を測定すると、輻輳なしでは約120ns、3倍のホスト内輻輳下では約900nsまで増加する。1倍・2倍ではそれぞれ約190ns・510nsまで増加する。Source: Adapted from Figure 12.) 送信側は新たなプローブACKを受け取るたびに、プローブ送出時刻$t_1$とACK生成時刻$t_2$の差から受信処理遅延$D_{cur}$を式(2)(EWMA、重み$\gamma_{probe}=0.75$)で算出する。目標遅延閾値$D_{thr}$を定め$D_{cur} > D_{thr}$のとき輻輳とみなす。送信側は受信可能レート$R_{rev}$を式(3)のPID(比例・積分・微分)ベース調整で更新する($\alpha$: 比例項、$\beta$: 微分項の重み)。パラメータ固定のAIMD方式と比べ、誤差ベースの較正と微分による調整項を持つPID方式は受信側の実時間状態に応じて適応的にレートを調整でき、ホスト内資源を効率的に利用できるとしている。 最終的な送信レートは式(4)の $R_{sending} = \min(R_{rev}, R_{cc})$ として、既存のホスト間輻輳制御アルゴリズム(DCQCN等)が計算する送信レート$R_{cc}$との小さい方を採る。これにより任意のホスト間輻輳制御方式と組み合わせ可能になり、最も輻輳が深刻な地点の制約を満たすようにレートが決まるため、RNICトラフィック間でmax-min公平性を達成する。 **収束性解析(Convergence analysis、§III-C)** PIDコントローラの一般的な理論([46])によれば、PID制御はSISO ARMAX(Single-Input-Single-Output AutoRegressive Moving Average with eXtra input)モデル(式(5))で特徴づけられ、一般化最小分散目的関数(式(6))による最適化を通じてグローバル収束性(式(7)、初期条件によらず一意の点へ収束する強い性質)を持つことが示されている。RHCCの誤差信号$e(t) = D_{cur} - D_{thr}$は、任意の目標値$D_{thr}$に対し収束条件(式(7))を満たすパラメータ組が常に存在するため、最終的に一定値へ収束する。証明の詳細は先行研究([46])に譲る。 **オーバーヘッドとスケーラビリティ** プローブパケットは約60バイトで32KBデータごとに1個生成されるため、ネットワーク帯域オーバーヘッドは0.2%に留まる。PCCフレームワーク全体はRNICハードウェア上で実行されファームウェアベースのプローブがハードウェアタイムスタンプを取得する。RHCCの制御ロジックはシンプルで、QP接続ごとに16バイト(受信可能レート4バイト・プローブ送出時刻4バイト・前回受信処理遅延4バイト・目標遅延閾値4バイト)の状態のみを保持する。 **Figure 13: スケーラビリティと利点の分析** ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig13-scalability-benefits.png]] (Figure 13(a). QP数を1から256まで変化させても、RHCCは大規模QP接続下で一貫して高いRNICトラフィックスループットを維持する。Figure 13(b). hostCCをRHCCの枠組み上でエミュレートし比較すると、hostCCではRNICトラフィックスループットがわずか27Gbpsまで低下しCPU-to-メモリトラフィックが208Gbpsに達する一方、RHCCはより高いRNICトラフィックスループットを維持する。これはhostCCがホスト内輻輳とホスト間輻輳を区別しないため、RNICトラフィックが帯域を確保するのにDCQCNの300µsレート増加間隔を要し、CPU-to-メモリトラフィックに比べて著しく不利になるためである。Source: Adapted from Figure 13.) ### 実装上の工夫 - 受信側RHCCは、hostCCのオープンソースコード([49])を基にした約500行のCコードによるロード可能Linuxカーネルモジュールとして実装する。 - 送信側RHCCはPCCフレームワーク上に実装し、DCQCNと組み合わせる。 - システムパラメータ: プローブパケットは32KBデータごとに1個生成(オーバーヘッドと制御粒度のトレードオフ)。$I_{thr} = 45$(CPU-to-メモリトラフィックを保護する設定)、$D_{thr} = 200$ns、$\alpha = 0.0005$、$\beta = 0.0005$(測定単位はナノ秒)、EWMA重み$\gamma_{IIO} = 0.25$、$\gamma_{probe} = 0.75$。ホスト間輻輳制御はベンダー既定パラメータのDCQCNを用いる。 ## 新規性 **RHCCのhostCCに対する優位性(§III-D)** RHCC は hostCC(SIGCOMM 2023)の設計思想を継承しつつRDMAネットワークへ拡張したものであり、両者の関係を著者ら自身が体系的に整理している: 1. **RDMAでの実装可能性**: hostCCは受信側でECN-bitをマーキングする方式を取るが、RDMAは輻輳制御ロジックをすべてRNICハードウェア内で実装しており、商用RNICはカーネルモジュールがパケットを能動的に改変するインターフェースを提供しない。RNICバッファのマーキング閾値を調整する([25])やアプリケーションがCNPを偽造する([47])といった代替策もあるが、前者は動作が遅く日常運用では稀にしか取られない対応、後者はQPコンテキストの記録とカーネル監視モジュールとの連携が必要で展開が複雑になる。RHCCはプローブ機構で受信処理遅延を取得するためこの制約を回避する。 2. **異なるホスト間輻輳制御方式との協調**: hostCCの受信側駆動の輻輳シグナル生成方式は、スイッチで収集される輻輳シグナル(HPCCのINT等)に依存する方式と協調できない。RHCCは自己定義の制御ロジックでRNICトラフィック調整を行い、ホスト内・ホスト間のトラフィック調整を分離するため、任意のホスト間輻輳制御方式に適応できる。 3. **ホスト内輻輳とホスト間輻輳のパラメータ分離**: hostCCはNICトラフィックに対しホスト内輻輳向けとホスト間輻輳向けの調整を区別しない。例えばDCQCNの既定のレート増加タイマー($T_i=300$µs)はホスト間ネットワーク向けには適切だが、サブマイクロ秒スケールのホスト内ネットワークには不適切である。 4. **純粋なPCIe輻輳への対応**: hostCCはIIOバッファ占有量が閾値を超えない純粋なPCIe輻輳の場合、輻輳なしと誤判定してNICトラフィックレートを増加させ、かえってPCIe輻輳を悪化させる。RHCCはプローブ機構でRNIC受信データパス全体の背圧を捉えるためこの誤判定を避けられる。 5. **cross-NUMAトラフィックへの対応**: hostCCはcross-NUMAメモリアクセストラフィックの影響を考慮しない。RHCCはcross-NUMAトラフィックの帯域をレベル4まで直接制限するカスケード調整を持つ。 ## 実験設定 - **ハードウェア/ソフトウェア環境**: §II-Bの基本実験は Dell R740 サーバ2台を単一スイッチで接続したテストベッド。各サーバはデュアル Intel Xeon 6240 CPU、Mellanox ConnectX-6 DX 100Gbps RNIC(128Gbps PCIe 3.0 x16経由)、2メモリチャネルのDDR4 DIMM、4MBキャッシュウェイのDDIO有効を備える。§IVの評価では3台構成に拡張し、ホスト間・ホスト内輻輳の併存シナリオを追加検証する。 - **輻輳生成手法**: Intel Memory Latency Checker(MLC)で1:1 read/writeのCPU-to-メモリトラフィックを生成し、アクティブCPUコア数を段階的に増やして1倍〜3倍(実測19.0/25.3/30.3GBps)のホスト内輻輳を模擬する。標準ベンチマークツール Mellanox Perftest でRNICトラフィックを生成し、メッセージサイズ(64KB〜1MB)・QP数(1〜8)を変化させる。 - **計測ツール**: Intel Performance Counter Monitor(PCM)でメモリ帯域利用率とPCIe write hit/miss数(DDIO有効性の指標)を測定。NVIDIA Neohost でPCIe outbound stalled write requests数(RNICへのPCIe背圧の指標)を測定。 - **比較対象**: 素のDCQCN(RHCCなし)。hostCCはRDMAネットワークに技術的に展開不能なため、RHCCの枠組み上に300µsのレート増加間隔を追加する形でエミュレートして比較する(§III-D)。 - **評価指標**: (i) ホスト間トラフィックスループット、(ii) ホスト内メモリ帯域、(iii) ネットワークレイテンシ、(iv) 正規化PFC一時停止時間/CNP数、(v) 正規化PCIe背圧(outbound stalled write requestsの正規化値)。 ## 実験結果 **Figure 1・2: ホスト内ネットワークアーキテクチャと輻輳の全体像** **Figure 1: 商用Intelサーバのホスト内ネットワークアーキテクチャ** ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig01-intra-host-network-architecture.png]] (Figure 1. Intel CPUソケットはCoreとUncoreサブシステムがmeshインターコネクトで接続され、Uncoreはメモリコントローラ・LLC/CHA・IIO(統合IOコントローラ)・UPI(ソケット間インターコネクト)から構成される。RNIC・GPU・NVMe SSDなどのアクセラレータはIIO経由でPCIeドメインに接続される(AMDも同様のアーキテクチャを持つ)。Source: Adapted from Figure 1.) **Figure 2: RDMAホスト内輻輳の概要** ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig02-intra-host-congestion-overview.png]] (Figure 2. RNICトラフィック(青矢印)はRNIC→IIO→メモリコントローラの経路をロスレスかつクレジットベースのフロー制御で流れる。CPU-to-メモリトラフィック(緑矢印)との競合でメモリコントローラへのクレジット補充が遅延すると、IIOバッファでのキューイングとRNICへのPCIe背圧が生じ、最終的にRNICがPFC一時停止フレームまたはCNPを生成する。Source: Adapted from Figure 2.) **[Figure 3] ホスト内輻輳は受信側スループットの大幅な低下とネットワークレイテンシの増加を招く** **Figure 3: 輻輳度合いごとのネットワーク性能** ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig03-network-perf-vs-congestion-level.png]] (Figure 3. (a)受信スループット (b)平均レイテンシ (c)99パーセンタイルレイテンシ (d)PFC一時停止/CNP数。輻輳なし(0倍)が最良の性能を示し、輻輳度の増加とともにスループットが低下・レイテンシが増加する。3倍の輻輳下では、PFC有効/PFC-freeそれぞれでスループットが62%/68%低下、平均レイテンシが2.4倍/2.6倍に増加する。RNICトラフィックスループットの低下幅は、事前に測定したCPU-to-メモリトラフィックのメモリ帯域消費量の増加幅より大きい。これはDDIOスキームがRNICとCPU-to-メモリトラフィック間のLLC競合を増大させ、CPU-to-メモリトラフィックがより多くのメモリ帯域を消費するようになるためである。Source: Adapted from Figure 3.) **[Figure 4] ホスト内輻輳は深刻なPCIe背圧と高いDDIOミス率を招く** **Figure 4: PCIe背圧とDDIOミス率** ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig04-pcie-backpressure-ddio-miss.png]] (Figure 4. (a)正規化PCIeアウトバウンドスタール書き込み要求は輻輳度の増加とともに大きく増加し、観測された性能劣化(Figure 3)の根本原因が高いメモリ帯域競合であることを示す。(b)DDIOミス率も輻輳度の増加とともに増加する。これはキャッシュライン退避に十分なメモリ帯域を要するメモリ書き戻し操作が、高レベルのホスト内輻輳下で減速するためである。Source: Adapted from Figure 4.) **[Figure 5] メッセージサイズ・QP数の増加はホスト内輻輳の影響をわずかに緩和する** **Figure 5: メッセージサイズ・QP数ごとの受信スループット** ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig05-throughput-msgsize-qpnum.png]] (Figure 5. 3倍のホスト内輻輳下でメッセージサイズ(64KB〜1MB)・QP数(1〜8)を変化させると、スループットはわずかに増加する。これはより大きなメッセージサイズ・QP数がより多くのin-flightパケットをもたらし、メモリ帯域競合を高める一方でRNICトラフィックの帯域消費も増やすためだが、効果はわずかであり、より大きなメッセージサイズはDDIO割り当てキャッシュにより多くの空間を要求してleaky DMA問題を悪化させる。Source: Adapted from Figure 5.) **[Figure 6] ホスト内cross-NUMAメモリアクセストラフィックはホスト内輻輳をさらに悪化させる** **Figure 6: cross-NUMAメモリアクセストラフィックを伴うネットワーク性能** ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig06-cross-numa-network-perf.png]] (Figure 6. cross-NUMAトラフィックはlocal-NUMAトラフィックと比べスループットを最大24%低下させ、PFC一時停止も増加する。これはcross-NUMAトラフィックがより複雑でレイテンシの大きいcross-NUMAキャッシュコヒーレンシを要するため。local-NUMAとcross-NUMAを同数のアクティブCPUコアで混在させたhybridトラフィックはさらに悪化し、local-NUMAトラフィック比で最大40%のスループット低下を示す。これは双方向cross-NUMAキャッシュコヒーレンシがUPIリンク帯域に圧力をかけ、より多くのメモリ帯域を消費するため。PFC-freeシナリオでも同様の傾向を確認している。Source: Adapted from Figure 6.) **RHCCの効果(§IV-B)** **[Figure 14] RHCCはPCIe背圧を大幅に削減し、高いホスト内輻輳下でもスループットを改善する** **Figure 14: RHCC適用時のPCIe背圧削減とスループット改善** ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig14-rhcc-pcie-backpressure-throughput.png]] (Figure 14. Figure 3と同一実験にRHCCを適用した結果(PFC有効シナリオ)。(d)PCIeスタール書き込み要求はCPU-to-メモリトラフィック輻輳応答により1倍・2倍・3倍の輻輳下でそれぞれ80%・93%・97%削減される。これによりRNICトラフィックが十分なホスト内資源を獲得しホスト間輻輳制御の発動を抑制できる。(c)PFC一時停止時間は3倍輻輳下で最大64%削減され、(a)(b)アプリケーションレベルのネットワークスループット/平均レイテンシがそれぞれ最大2倍/1.4倍改善する。PFC-freeシナリオでも同様の改善を確認している。Source: Adapted from Figure 14.) **[Figure 15] RHCCはcross-NUMAトラフィック起因のホスト内輻輳を大幅に緩和する** **Figure 15: cross-NUMAトラフィックに対するRHCCの緩和効果** ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig15-rhcc-cross-numa-mitigation.png]] (Figure 15. Figure 6のcross-NUMA実験にRHCCを適用した結果。cross-NUMAシナリオでスループットは最大3.1倍改善し、高い輻輳度でもほぼ全速のスループットを達成する。これはRHCCがcross-NUMAトラフィックの利用可能メモリ帯域をレベル4まで直接制限するためで、PFC一時停止時間は3倍輻輳下で最大92%削減される。hybridトラフィックのシナリオでもスループットは最大3.5倍改善するが、純粋なcross-NUMAシナリオより平均スループットは低い。これはlocal-NUMAトラフィックの利用可能帯域も段階的に削減する必要があり、双方向キャッシュコヒーレンシの課題が残るため。cross-NUMAトラフィックとRNICトラフィックの間のメモリ帯域配分にはトレードオフがあり、RHCCはcross-NUMAトラフィックへの直接制限を優先する。Source: Adapted from Figure 15.) **[Figure 16] RHCCは高速な輻輳回避を維持しつつメモリ帯域利用率を保護する** **Figure 16: 基本シナリオ・hybrid-NUMAシナリオでのメモリ帯域消費** ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig16-memory-bandwidth-consumption.png]] (Figure 16. Figure 14・15と同一実験でのメモリ帯域消費量。RHCCはCPU-to-メモリトラフィックへの配分を削減しRNICトラフィック向けに帯域を確保する一方、総メモリ帯域消費量はネイティブシナリオと同水準を維持し高いホスト内資源利用率を確保する。hybrid-NUMAシナリオではRHCCがcross-NUMAトラフィック向け資源を直接制限しキャッシュコヒーレンシ問題を緩和するため、総メモリ帯域利用率がわずかに高くなる。Source: Adapted from Figure 16.) **[Figure 17] RHCCはホスト間輻輳とホスト内輻輳が併存する場合も効果を維持する** **Figure 17: ホスト間輻輳単独・ホスト間+ホスト内輻輳併存下のRHCC性能** ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig17-rhcc-with-inter-host-congestion.png]] (Figure 17. 2〜8のQP数でIncastトラフィックを生成しホスト間輻輳を発生させた実験。(a)(c)純粋なホスト間輻輳シナリオではRHCCの性能はDCQCNと同等でPFC一時停止も発生せず、RHCCがホスト間輻輳制御方式と互換性を持ちオーバーヘッドが最小限であることを示す。(b)(d)3倍のCPU-to-メモリトラフィックを追加すると素のDCQCNは大きなPFC一時停止と深刻な性能劣化を示す一方、RHCCはサブマイクロ秒粒度のCPU-to-メモリトラフィック応答とホスト間輻輳制御を組み合わせることでPFC一時停止を最大2.9倍削減しネットワークスループットを最大1.85倍改善する。Source: Adapted from Figure 17.) **[Figure 18] RHCCは純粋なPCIe輻輳シナリオでも有効だが改善幅は他のシナリオほど大きくない** **Figure 18: PCIe輻輳シナリオでのRHCCの効果** ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig18-pcie-congestion-scenario.png]] (Figure 18. 受信側RNICを別の2台のサーバに直接接続し標準ベンチマークツールiPerfでTCPトラフィック(1〜4本、37/71/95Gbps)を生成しPCIe輻輳を模擬、RDMAトラフィックにはPFCのみ有効化した実験。RHCCの能動的なRDMAトラフィック調整によりPCIe背圧を最大50%削減し、PFC一時停止を最大47%、TCPトラフィックドロップ率を58%削減する。ただし改善幅は他のホスト内輻輳シナリオほど大きくない。理由は二つ:(1) RDMA/TCPトラフィックの競合はPCIeバス上でのみ生じIIOバッファ占有量に影響しないため、他サーバから生成されるTCPトラフィックを受信側が直接配分できずRHCCの受信側資源配分が機能しない、(2) TCPトラフィック自体の損失によりTCP側の送信レートが下がりPCIe背圧が自然に緩和される。hostCCはこの純粋なPCIe輻輳シナリオでは、IIOバッファ占有量が閾値を超えないため無輻輳と誤判定しむしろホスト間トラフィックレートを増加させPCIe輻輳を悪化させる。Source: Adapted from Figure 18.) **RHCC感度分析(§IV-C、APNet版から新規追加)** **Figure 19: $I_{thr}$感度分析** ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig19-ithr-sensitivity.png]] (Figure 19. 3倍輻輳下で$I_{thr}$を変化させると、$I_{thr}$の増加はCPU-to-メモリトラフィック輻輳応答をより非積極的にしPFC一時停止を増加させる。$I_{thr}=30$または$35$では輻輳応答が頻繁にレベル4まで低下しCPU-to-メモリトラフィックのメモリ消費が130Gbpsに留まる。CPU-to-メモリトラフィックを保護するため本論文は$I_{thr}=45$を採用し、この場合CPU-to-メモリトラフィックのメモリ消費は170Gbps、RNICトラフィックスループットは72Gbpsとなる。Source: Adapted from Figure 19.) **Figure 20: $D_{thr}$感度分析** ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig20-dthr-sensitivity.png]] (Figure 20. 3倍輻輳下で$D_{thr}$を変化させると、$D_{thr}$の増加はRNICトラフィック輻輳応答をより非積極的にしPFC一時停止を増加させる一方、CPU-to-メモリトラフィック応答がより頻繁に発動し$D_{thr}=800$では約132Gbpsのメモリ帯域消費となる。本論文はホスト内・RNICトラフィック間の資源配分トレードオフのバランスを取るため$D_{thr}=200$を採用する。Source: Adapted from Figure 20.) **[Figure 21] 2つの輻輳応答はいずれもRHCCの性能に有意に寄与する** **Figure 21: 2つの主要設計選択の必要性の検証** ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig21-necessity-two-design-choices.png]] (Figure 21. (a)RNICトラフィック応答のみの場合、RNICトラフィックスループットはわずか18Gbpsに低下しCPU-to-メモリトラフィックが228Gbpsに達する。これはRNICトラフィックがホスト内輻輳へ継続的に反応しレートを下げ続けるためで、Swift・On-rampのようなホスト間トラフィック応答のみの手法はホスト間アプリケーション性能を損なうことを示唆する。CPU-to-メモリトラフィック応答のみの場合、RNICトラフィックは90Gbpsに達するがCPU-to-メモリトラフィックは130Gbpsに劣化する。これはIIOバッファ占有量が頻繁に閾値を超え、より高レベルのホスト内資源制限が発生し続けるため。(b)(c)(d)IIOバッファ占有量と応答レベルの時系列変動を、RNICトラフィック応答のみ・CPU-to-メモリトラフィック応答のみ・RHCCの両方併用の3条件で比較すると、両方を併用するRHCCが最も高速な輻輳回避と合理的な資源配分のトレードオフを実現する。Source: Adapted from Figure 21.) ## 考察 論文はSection Vで、RHCCの設計が今後どのように発展しうるかを3つの方向で議論している(§V、APNet版から新規追加): - **新しいホスト内アーキテクチャ**: Compute Express Link(CXL)は新興のインコネクト規格で、CPUコアとCXLデバイス間に統一されたコヒーレントメモリ空間を提供する。ただし既存の商用サーバへの大幅な追加改修を要し、ホスト内輻輳緩和への具体的な利点は今後の研究課題として残る。また商用RNICのオンチップSRAM容量制約によりキャッシュできるQP数が限られ、QP数が閾値を超えるとInterconnect Context Memory(ICM)キャッシュミスと追加のPCIe帯域消費が発生し性能崩壊を招くという別種のホスト内輻輳が観測されている([11])。SRNIC([18])のキャッシュフリーQPスケジューラはこの問題を緩和する直交的・補完的なアプローチである。 - **新しい資源配分ポリシー**: ホスト内資源配分機構は、重み付きmax-min公平性や優先度スケジューリングなど異なる基盤ポリシーをサポートすべきである。RHCCは現在RNICトラフィック間のmax-min公平性とCPU-to-メモリトラフィックへの保証のみをサポートしており、他のポリシーの組み込みは今後の課題としている。 - **新しいプログラマブルなホスト内ネットワーク**: ホスト間ネットワークと対照的に、ホスト内ネットワークは十分なプログラマビリティを欠く。例えばIntel MBAのような資源配分ツールでは複雑な調整関数の実装が難しく、商用RNICは送受信パケットカウンタ(Port/HWカウンタ)程度の単純な診断カウンタしか提供しないため、RNICバッファ占有量のようなメトリクスの取得にはベンダーの支援を要することが多い。次世代ホスト内ネットワークにこれらの課題を解決するプログラマビリティが備わることを期待するとしている。 RHCCは商用サーバ・RNIC上でオーバーヘッド(ネットワーク帯域0.2%、状態16バイト/QP)を抑えつつ、既存のホスト間輻輳制御プロトコルと非侵襲的に共存できる点が実装可能性の根拠となっている。PIDベースの調整によりAIMD方式より適応的な収束を実現し、収束性は先行の制御理論研究に基づき理論的にも裏付けられている。 ## 強み / 弱点・課題 **強み** - RDMA受信側カーネルモジュールがデータパケットを直接改変できないという制約に対し、hostCCのECN-bitマーキング方式ではなくPCCのプローブ機構を用いることで、RDMA環境に実際に実装・展開可能な設計を提示した。 - ホスト内輻輳応答(サブRTT粒度)とホスト間輻輳応答(RTT粒度)を明確に分離した二層構造により、既存のホスト間輻輳制御プロトコル(DCQCN)を一切変更せずに統合できる。 - IIOバッファ占有量・受信処理遅延という2つの独立した輻輳シグナルをMSR・PCCという既存の商用ハードウェア機構だけで取得しており、追加のハードウェア支援を必要としない。 - Ithr・Dthrの感度分析、二つの輻輳応答の必要性検証(Figure 21)、収束性の理論的裏付け(§III-C)など、APNet版に対しRHCCの設計選択の妥当性を裏付ける実験・理論的根拠が拡充されている。 **弱点・課題** - 純粋なPCIe輻輳シナリオ(Figure 18)では、RDMA/TCPトラフィックの競合がIIOバッファ占有量に現れずかつ加害トラフィック(TCP)が他サーバ由来のため受信側が直接配分できず、改善幅が他のシナリオより小さい。 - RHCCは単一のホスト間輻輳制御(DCQCN)との組み合わせでのみ評価されており、他のプロトコル(TIMELY・HPCC等)との組み合わせは示されていない。 - Intel MBAの粗粒度な5段階配分への依存という制約はhostCCから引き継がれており、根本的な解決には至っていない。 - RHCCは現時点でRNICトラフィック間のmax-min公平性とCPU-to-メモリトラフィックへの保証という単一の資源配分ポリシーのみをサポートし、重み付き公平性や優先度スケジューリングなど他のポリシーは将来課題として残されている。 - ICMキャッシュミスに起因するホスト内輻輳(RNICのオンチップSRAM制約による)は、RHCCが用いるIIOバッファ占有量・受信処理遅延という輻輳シグナルの対象範囲外であり、別途SRNICのような機構が必要になる。 ## APNet 2024版との関係 本論文は [[@2024__APNet__Rethinking Intra-host Congestion Control in RDMA Networks]](APNet 2024、7ページ)の拡張ジャーナル版であり、内容に矛盾はない。中核となるRHCCフレームワーク・CPU-to-メモリトラフィック輻輳応答・RNICトラフィック輻輳応答・実験の主要数値(3倍輻輳下でスループット62%/68%低下、レイテンシ2.4倍/2.6倍増加、PCIeスタール書き込み要求80〜97%削減、スループット/レイテンシ最大2倍/1.4倍改善等)は両版で一致する。ToN版で拡充された主な要素は次のとおり: - 著者にYongchen Panが追加された(APNet版は6名、ToN版は7名)。 - §II-Bのcross-NUMA実測(Figure 6)がAPNet版から拡充され、hybridトラフィックのスループット低下(最大40%)など追加の観察が加わった。 - §III-Cに収束性解析(Convergence analysis)が新設され、PIDコントローラのグローバル収束性を先行研究の制御理論(SISO ARMAXモデル・一般化最小分散目的関数)を援用して理論的に裏付けた。 - §III-DにRHCCのhostCCに対する体系的な優位性比較(5点の観点)が新設された。 - §IV-CにRHCC感度分析(Ithr・Dthr、Figure 19・20)が新設された。 - §Vに考察(Discussion and Future Work: CXL、新しい資源配分ポリシー、プログラマブルなホスト内ネットワーク)が新設された。 APNet版の実装先はDell R740サーバ2台の基本テストベッドのみだったのに対し、ToN版はホスト間・ホスト内輻輳併存シナリオ評価のため3台構成のテストベッドへ拡張している点も差分である。