ホスト内ネットワークボトルネック

# ホスト内ネットワークボトルネック ## 定義ホスト内ネットワークボトルネックとは、RDMA サーバのホスト**内部**(RNIC とエンドポイント(GPU・メモリノード)の間の PCIe リンク・PCIe スイッチ・メモリチャネル・CPU ソケット間バス(UPI/QPI/xGMI))で発生する性能劣化のことである。スイッチやケーブルなどホスト**間**(inter-host)のネットワーク障害とは区別される概念で、[[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]] が「ホスト内ボトルネック」と「ネットワークボトルネック(スイッチ・ケーブル)」を明確に切り分けて定義している。 ## 横断的知見 - **RNIC 線速の急増がホストを新たなボトルネック源に変える**: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]] は、RNIC 線速が 25Gb/s→200Gb/s へ急増する一方、PCIe 帯域は世代交代のペースがそれに追いつかない(PCIe Gen3 x8 の約63Gb/s→Gen4/5世代で約252Gb/s)ため、かつて「十分な余剰帯域を持ち通信のボトルネックにならなかった」ホスト内ネットワークが、RNIC の実効スループットを制限する側に転じつつあると報告する。ネットワーク性能問題の原因の所在が、スイッチ・ケーブル(ネットワーク側)からサーバ内部(ホスト側)へ拡大している。(Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]]) - **症状は「帯域劣化」と「レイテンシ増加」の2種類に収斂する**: 根本原因(リンク障害・トラフィック輻輳・誤設定)は多様でも、観測可能な症状はホスト内帯域の劣化とホスト内レイテンシの増加の2つに集約されるという知見が Hostping の診断設計の出発点になっている。これにより、ベンダー固有の多数のメトリクスではなく、RNIC-エンドポイント間のループバックテストという単一の計測手法で大半のボトルネックを検知できる。(Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]]) - **binary network tomography はホスト内トポロジにも応用できる**: スイッチ・リンクレベルの障害箇所特定に使われてきた binary network tomography(パス単位の観測からリンク単位の状態を逆算する手法)を、Hostping はホスト内の RNIC-エンドポイント間パスに適用し、full-mesh ループバックテストの結果からリンク(PCIe・メモリチャネル・UPI)単位の異常を推論する。ネットワークレベルの箇所特定手法がホスト内部の障害診断にもそのまま転用可能であることを示した。(Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]]) - **誤設定(ACS/ATS)がハードウェア障害と同等の深刻さを持つ**: Hostping の本番展開では、リンクの物理障害だけでなく、ACS(Access Control Service)の意図しない有効化や ATS(Address Translation Service)の無効化といった PCIe 設定ミスが GDR(GPU Direct RDMA)トラフィックを CPU 経由に迂回させ、ハードウェア障害と同水準のレイテンシ増加・帯域劣化を引き起こすことが報告されている。ホスト内ボトルネックの根本原因は物理層の故障に限らず、ソフトウェア設定層にも及ぶ。(Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]]) - **症状の検知と根本原因のメカニズム解明は異なる階層の問題である**: Hostping はホスト内の「帯域劣化」「レイテンシ増加」という症状を binary network tomography で検知するが、なぜその症状が生じるかのメカニズムは扱わない。[[@2024__SIGCOMM__Understanding the Host Network]] は [[ドメイン別クレジットベースフロー制御]] という概念的抽象化により、ホストネットワーク内の性能劣化がどのドメイン(CHA/MC/IIO/LFBを結ぶサブネットワーク)のクレジット枯渇・レイテンシ膨張に起因するかを、Intel uncore performance counters による実測と解析式(誤差10%以内)で定量的に説明する。両者を組み合わせれば、Hostping の症状検知に本論文の根本原因メカニズムを接続できる可能性があるが、そのような統合はこの wiki が持つソースからはまだ確認できていない。(Source: [[@2024__SIGCOMM__Understanding the Host Network]]) - **ホスト内ネットワーク競合はRNIC-エンドポイント間パスに限らず、CPU内部のプロセッサ・メモリ・周辺機器インターコネクトの相互作用でも生じる**: Hostping が対象とするPCIe・メモリチャネル・UPI/QPI/xGMIといったリンク単位の障害診断に対し、[[@2024__SIGCOMM__Understanding the Host Network]] はソケット内部のLFB・CHA・IIO・MCという、より細粒度のコンポーネント間相互作用が競合の発生源になりうることを示す。これはホスト内ボトルネックの原因の所在が、リンクレベルの障害だけでなく正常動作時のインターコネクト間の設計上の非対称性(例: C2M-WriteドメインはMCを含まないがP2M-WriteドメインはMCを含む)にも及ぶことを意味する。(Source: [[@2024__SIGCOMM__Understanding the Host Network]]) - **同じ「RNIC線速とPCIe帯域のギャップ」という診断的観察が、独立して「能動的な制御」を動機づける**: Hostping は RNIC 線速の急増(25Gb/s→200Gb/s)と PCIe 帯域の停滞という観察を診断ツールの設計動機として用いるが、[[@2024__APNet__Rethinking Intra-host Congestion Control in RDMA Networks]](RHCC)は同じ観察(RNIC線速25Gbps→200Gbps、PCIe帯域63Gbps→256Gbps)から出発し、診断ではなく能動的な資源配分・レート制御機構を提案する。RHCC の実測(3倍のホスト内輻輳負荷でPFC有効/PFC-free環境それぞれスループット62%/68%低下、レイテンシ2.4倍/2.6倍増加)は、Hostping が定義する「ホスト内帯域劣化・レイテンシ増加」という症状の輻輳制御的な側面を定量化しており、両論文は同じ著者グループ([[Jiao Zhang]]・[[Kefei Liu]]・[[Tao Huang]]・[[BUPT]])から同年(2024年)に発表された、診断と制御という補完的な貢献にあたる。(Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]], [[@2024__APNet__Rethinking Intra-host Congestion Control in RDMA Networks]]) - **ホスト内ボトルネックとRNIC自体の接続性問題は、同じ診断エージェントが異なる症状として扱うべき別カテゴリである**: [[@2024__TON__Diagnosing End-Host Network Bottlenecks in RDMA Servers]](Hostpingの拡張ジャーナル版)は、NSDI '23版の「帯域劣化・レイテンシ増加」という2症状に加え、RNIC同士が相互にRDMAパケットをプローブし合うR2R(RNIC-to-RNIC)probingという第3の機構を導入し、「接続性問題」という第3の症状カテゴリ(ルーティング誤設定・フラッピング・誤ったスイッチポート配線)を切り出した。ホスト**内**リンクの状態はRNIC-エンドポイント間ループバックテストで、RNIC**自体**の接続性はホスト間のR2R probingで、という住み分けにより、同一の診断エージェントがコントローラ不要・低オーバーヘッドのまま両方の問題領域をカバーできることを示した。(Source: [[@2024__TON__Diagnosing End-Host Network Bottlenecks in RDMA Servers]]) - **binary network tomography に基づくリンク推論は疑似コードとして定式化できる**: NSDI '23版では「アイデア」として説明されていたリンク状態推論(正常パス→リンク正常、異常パス上のuncertainリンク→異常、全リンク正常な異常パスは flapping 候補)が、TON拡張版ではAlgorithm 1として厳密な擬似コード化される。特に「異常パス上のリンクが既にabnormalとマークされている場合でも、新たなRNICがそのリンクを異常と判定するたびに`abnormal_cnt`を加算し続ける」という多数決的な集計ロジックは、擬似コード化して初めて明示される実装上の細部である。(Source: [[@2024__TON__Diagnosing End-Host Network Bottlenecks in RDMA Servers]]) - **同じ著者グループの2本の会議論文が、それぞれ独立に拡張ジャーナル版へ発展している**: Hostping(NSDI 2023)は拡張版 [[@2024__TON__Diagnosing End-Host Network Bottlenecks in RDMA Servers]](IEEE/ACM Transactions on Networking 2024)へ、RHCC(APNet 2024)は拡張版 [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]](IEEE Transactions on Networking 2025)へと、いずれも同じ [[Jiao Zhang]]・[[Tao Huang]]・[[BUPT]] のグループから発表されている。両論文とも「症状の診断」(Hostping)と「能動的な制御」(RHCC)というホスト内ネットワークボトルネックの異なる側面を扱いながら、会議発表後に体系的な拡張(Hostpingは第3の症状カテゴリR2R probing、RHCCは収束性解析とhostCC比較の体系化・パラメータ感度分析)を経てジャーナル誌に掲載されるという、同一著者グループの共通した研究サイクルを示している。(Source: [[@2024__TON__Diagnosing End-Host Network Bottlenecks in RDMA Servers]], [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]]) ## 未解決の問い - ホストが busy な状態でのサービストラフィック干渉下におけるリンク状態診断の精度は、affinitive エンドポイント比較に依存する。end-to-end のトラフィック情報を得られればより正確な診断が可能になるとされるが(著者ら自身の課題認識)、具体的にどのような情報源(eBPF によるアプリケーションレベルのトラフィック計装等)が有効かは示されていない。 - Hostping はホスト内ネットワークに焦点を当てており、RNIC 自体のスケーラビリティ限界(QP 数の増大に伴う性能劣化等)は対象外としている。RNIC 内部のボトルネックとホスト内ネットワークのボトルネックを統一的に診断する枠組みは今後の課題として残る。 - ホスト内診断(Hostping)とネットワーク監視([[RDMAネットワーク監視]] が扱う R-Pingmesh 等)を単一のダッシュボード・単一の根本原因分析パイプラインへ統合する仕組みは、現時点でこの wiki が持つソースからは確認できていない。 - Hostping の症状ベース診断([[ホスト内ネットワークボトルネック]])と、[[@2024__SIGCOMM__Understanding the Host Network]] の根本原因メカニズム([[ドメイン別クレジットベースフロー制御]])を単一の運用パイプラインへ統合する具体的な設計は、この wiki が持つソースからはまだ確認できていない。 - [[@2024__APNet__Rethinking Intra-host Congestion Control in RDMA Networks]](RHCC)が用いるIIOバッファ占有量という単一の輻輳シグナルは、Hostpingが診断対象とするPCIe・メモリチャネル・UPIといった複数のリンク単位の障害・誤設定(ACS/ATS誤設定等)を区別して検知できるか。RHCCの輻輳制御とHostpingの障害診断を同一の監視基盤に統合する設計は、この wiki が持つソースからはまだ確認できていない。 - [[@2024__TON__Diagnosing End-Host Network Bottlenecks in RDMA Servers]]のR2R probingは、タイムアウトの原因がRNIC自体・RNIC-ToR間リンク・ToRスイッチポートのいずれにあるかを直接切り分けられず、これらをまとめて「RNICネットワーク問題」として扱う。ホスト内ボトルネック診断(binary network tomographyベース)がリンク単位まで原因を特定できるのに対し、RNIC接続性診断がなぜそこまで粒度を落とさざるを得ないのか(ToRスイッチ側の情報が得られないという制約以外の理由があるか)は、この wiki が持つソースからは確認できていない。