インバンドネットワークテレメトリ

# インバンドネットワークテレメトリ ## 定義インバンドネットワークテレメトリ(In-band Network Telemetry, INT)は、プログラマブルデータプレーン(P4 等)を活用して、テレメトリ情報をネットワーク内を通過するパケットに直接埋め込む方式のネットワーク監視技術である(P4 Applications Working Group, 2025)。INT ソースが選択されたパケットに命令ヘッダを挿入し、トランジットノードが命令に従い自身のメタデータ(キュー占有率・ホップごとの遅延・ノード ID など)を付加し、INT シンクがテレメトリヘッダを除去して収集情報をコレクタにエクスポートする三者構造をとる。 INT はコントロールプレーン介入なしにデータプレーン内で直接動作し、SNMP ポーリング・NetFlow/IPFIX・sFlow サンプリングといった従来の粗粒度・高レイテンシな手法の限界を克服する。IETF の IOAM(In Situ Operations, Administration, and Maintenance)フレームワークが同等機能を標準化している。主要なヘッダ種別は MD-type(ホップごとの詳細計測で最もよく使われる)・Destination-type・MX-type の 3 種。 INTFusion([[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]])は INT のソース/シンク機能を smartNIC にオフロードし、スイッチ側に INT トランジット機能のみを要求する「エッジ終端 INT」アーキテクチャとして発展させた。 INT の最初期の主要な実用化は監視・診断ではなく**輻輳制御**であった。[[HPCC]]([[@2019__SIGCOMM__HPCC - High Precision Congestion Control]]、SIGCOMM 2019)は、経路上の各スイッチが ACK にキュー長(qLen)・送信バイトレート(txRate)・リンク帯域容量(B)を埋め込み、送信者がそれらを直接 CC の入力として使う——という形で INT を輻輳制御ループへ直接組み込んだ。詳細は [[データセンター輻輳制御]] の HPCC の項を参照。 ## パケットが経路上で計測データを収集していく仕組み(ch.2 §2.6) 『Software-Defined Networks: A Systems Approach』第2章は INT を、プログラマブルなフォワーディングパイプラインの登場で初めて可能になった比較的新しい SDN のユースケースとして紹介する。従来のコントロールプレーン主導の監視——固定カウンタ(送受信パケット数など)の読み取りや sFlow のようなサンプリング——との対比で、INT はフォワーディングパイプライン自体がパケット処理の最中に(インバンドで)ネットワーク状態を収集する点を特徴とする。具体的な役割分担は 3 者からなる。INT ソース(アプリケーション・ホストのネットワークスタック・ハイパーバイザーなど)が通常のデータパケットまたは専用のプローブパケットにテレメトリ「命令」を埋め込み、経路上の各スイッチ(トランジットノード)がその命令に従って自身の状態を書き込みながらパケットを転送し、INT シンクが命令の実行結果として蓄積されたデータを回収・報告する。送信元スイッチ S1 からトランジットスイッチ S2 を経てシンクスイッチ S5 に至る経路であれば、各スイッチが自らの通過時刻や状態を書き加えながらパケットをリレーしていく。(Source: ch.2 §2.6) この仕組みから何が観測可能になるかについて、本章は 2 つの具体例を挙げる。1 つは経路上の各スイッチの通過時刻を記録することによる待ち行列遅延の測定であり、「Switch 1 を 780ns、Switch 2 を 1.3µs、Switch 5 を 2.4µs で通過した」という報告からミリ秒未満の待ち行列遅延、すなわちマイクロバーストを検知できる。異なる経路をたどった複数のフローの情報を突き合わせれば、どのフローがどのスイッチのバッファ容量を奪い合っていたかまで特定できるとされる。もう 1 つはフォワーディングルールそのものの報告であり、「Switch 1 ではルール 75 と 250 に従い、Switch 2 ではルール 3 と 80 に従った」という形でパケットに意思決定過程を記録させれば、データプレーンがオペレータの意図通りに転送を実行しているかを検証する用途に道が開ける。本書はこの検証可能性への展開を終章(第10章)で改めて扱うとしている。(Source: ch.2 §2.6) ## HPCC における具体的な INT パケットフォーマット HPCC の INT パディングは UDP ヘッダの後・IB BTH(Base Transport Header)の前に挿入され、nHop(4bit)・pathID(12bit、経路変化検知用)に続き、各ホップが B(4bit、ポート速度種別)・TS(24bit)・txBytes(20bit、単位128B)・qLen(16bit、単位80B)の8バイトを追加する。データセンター内の典型的な経路長(5ホップ以内)ではパディング総量は最大42バイトにとどまる(1KBパケットの4.2%)。(Source: [[@2019__SIGCOMM__HPCC - High Precision Congestion Control]]) ## INT の課題 1. **帯域オーバーヘッド**: トランジットノードがパケットにメタデータを付加するため、ペイロードが膨らむ。MTU 超過が問題になる場合がある 2. **シンク処理オーバーヘッド**: 高リンクレート(100G/400G/800Gbps)では per-packet のテレメトリレポートが分析・ストレージシステムを圧倒する 3. **コンテキスト欠如**: ネットワーク内計測はホスト・アプリケーションの文脈(どのアプリ、どのプロセスが生成したフローか)を持たない ## INT の主要アーキテクチャパターン | パターン | 説明 | 代表システム | |---|---|---| | スイッチ内蔵シンク | スイッチが INT ヘッダを除去してコレクタに送信 | 標準 INT | | smartNIC オフロード | エンドホストの smartNIC が INT ソース/シンクを担当 | INTFusion | | eBPF + INT ハイブリッド | eBPF でホスト層トレースを取得し INT ネットワーク計測と統合 | INTFusion, TCP-INT | | 輻輳制御ループへの直接組み込み | ACK に qLen・txRate・B を埋め込み送信者が inflight bytes 制御に直接利用 | HPCC | ## 横断的知見 - **INT の用途は「輻輳制御(closed-loop control)」から「監視・診断(open-loop observation)」へと主軸を移してきた**: [[HPCC]]([[@2019__SIGCOMM__HPCC - High Precision Congestion Control]]、SIGCOMM 2019)は INT の最初期の主要な実用化例であり、スイッチが埋め込むキュー長・送信バイトレート・帯域容量を送信者がそのまま送信ウィンドウの計算に使う——という形で INT を輻輳制御ループへ直接組み込んだ。7年後の INTFusion(2026年、IFIP Networking)は同じ INT 情報をホスト/アプリコンテキストと融合させ、異常検知・トラブルシューティングという診断目的に転用する。同一の技術基盤が「制御」と「観測」という異なる用途に展開されたことは、INT が汎用的なテレメトリ収集手段として成熟したことを示す一方、HPCC の閉ループ制御(輻輳制御プロトコルへの直接フィードバック)を INTFusion のような汎用診断システムへ輸入する設計は本 wiki 内で確認できていない([[データセンター輻輳制御]] の未解決の問いを参照)。(Source: [[@2019__SIGCOMM__HPCC - High Precision Congestion Control]], [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]]) - **「ネットワーク計測」と「ホスト/アプリコンテキスト」の断片化が INT 普及後も残存する**: INT がスイッチ内部の per-hop 計測を可能にしても、そのテレメトリをどのアプリ・プロセス・フローレットが生成したかという文脈は失われる。INTFusion はこの断片化を、smartNIC への INT シンクオフロードと eBPF によるホスト層トレースの per-flow 融合で解消した。同様の問題は [[テレメトリ]] の横断的知見における「フルスタック計装の階層相関」(Astral の 4 層計装)とも共鳴する——単一層の観測だけでは根本原因に届かないという共通の制約。(Source: [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]]) - **「全パケットミラー vs 積極的サンプリング」の二択が二層エクスポートモデルで解消される**: 従来の INT 展開は全パケットのテレメトリをストリームするか(帯域・処理オーバーヘッド大)、積極的サンプリングに頼るか(輻輳ダイナミクス揺らぎ時に精度低下)のジレンマを抱えていた。INTFusion の二層モデルは、閾値超過イベントのリアルタイム配信と非クリティカル集計のレート制御遅延配信を分離することで、両者の中間点を実現する。これは [[テレメトリ]] の横断的知見「遡及的サンプリング(Hindsight)」が「全数生成 + 症状駆動的収集」で計装コストと有用性を両立するのと同型の設計判断。(Source: [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]]) - **INT は「フォワーディングルールの記述」を主題としてきた SDN 史の外側で育った P4 の応用である**: [[プログラマブルデータプレーン]] concept が整理するように、『ネットワークシステムについて語るときに我々の語ること』第5章は P4 を一貫してコントロール/データプレーン間インターフェース(P4Runtime)の自動生成という文脈で語り、フォワーディング制御の柔軟化に焦点を当てる(ch.5 §5.2, §5.3)。INT はこの同じ P4 の能力を、コントロールプレーン非介在のテレメトリ生成という、ch.5 の射程になかった用途に転用したものであり、プログラマブルデータプレーンという技術基盤が単一の設計意図(制御の柔軟化)を超えて汎用化したことを示す一例になっている。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]], [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]]) - **INT は教科書レベルでも「輻輳制御」ではなく「ビッグデータ/アナリティクス」の文脈で紹介されている**: 『Computer Networks: A Systems Approach』第7章のPerspective節「Big Data and Analytics」は、INTを5Gセルラーネットワークのプランニングと並ぶ「ネットワーク自身の挙動を収集・分析し閉ループ制御を構築する」ための一手法として位置づけ、コントロールプレーン経由の従来型レポートとの対比でデータプレーン内直接収集という特徴を紹介するにとどまり、輻輳制御ループへの直接組み込み(HPCC)や host/network テレメトリ融合(INTFusion)といった具体的なアーキテクチャパターンには踏み込まない。この教科書的な扱いは、INTが2020年時点では「まだ初期段階(still early-stage)」の研究トピックとして紹介されていたことを示しており、本concept が蓄積するHPCC(2019)・INTFusion(2026年)という2つの実装例は、教科書が「今後の研究」として留保した領域が実際にどう具体化したかの後続の軌跡を示す。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 7 End-to-End Data]] Perspective, [[@2019__SIGCOMM__HPCC - High Precision Congestion Control]], [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]]) - **同じ Systems Approach シリーズの中で、INT の記述は「一手法への簡潔な言及」から「1 章を割く独立ユースケース」へと詳細化している**: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 7 End-to-End Data]](2020年)の Perspective 節は INT を、5G セルラーネットワークのプランニングと並ぶ「ネットワーク自身の挙動を収集・分析し閉ループ制御を構築する」ための一手法として簡潔に紹介するにとどまっていた。1 年後に出た[[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 2 Use Cases]]は、INT ソース・トランジットノード・INT シンクという 3 者の役割分担、S1→S2→S5 という具体的な経路例、マイクロバースト検知とフォワーディングルール検証という 2 つの応用先を、章の締めくくりの独立ユースケースとして詳述する。両者は同じ著者陣(Larry Peterson を中心とする Systems Approach シリーズ)による記述であり、単なる別々の視点の突き合わせというより、同一著者グループの中で INT の扱いが 1 年の間に「脇道の言及」から「本文一節を割く事例」へと格上げされた経緯を示す。この格上げ自体が「INT はまだ初期段階(early-stage)」という両書共通の留保と矛盾しない——扱いの厚みは増したが、成熟度の評価は変わっていない。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 7 End-to-End Data]] Perspective, [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 2 Use Cases]] §2.6) - **INT の「観測可能になるもの」として、SDN 本 ch.2 は HPCC/INTFusion にない第三の用途——フォワーディング意図の検証——を明示する**: 本ページが記録する HPCC(2019)は INT を輻輳制御ループへの直接組み込みに、INTFusion(2026)は host/network テレメトリ融合による異常検知・トラブルシューティングに用いる。[[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 2 Use Cases]]はこれらとは異なる第三の用途として、各スイッチが従ったフォワーディングルールをパケット自身に報告させることで、データプレーンがオペレータの意図通りに転送を実行しているかを検証する使い方を挙げる。これは「性能計測」でも「輻輳制御」でもなく、SDN のコントロールプレーンが意図した状態とデータプレーンの実際の挙動との一致を検証するという、SDN 特有の関心(オペレータの意図と実装のギャップを埋める)に根ざした応用である。HPCC・INTFusion のどちらの実装例もこの検証用途を扱っておらず、本 wiki 内ではまだ具体的なシステムでの検証は確認できていない。(Source: [[@2019__SIGCOMM__HPCC - High Precision Congestion Control]], [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]], [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 2 Use Cases]] §2.6) - **終章(第10章)は、INT を「検証可能なクローズドループ制御」を成立させる測定入力源として明示的に位置づけるが、具体的な検証アルゴリズムや実装には踏み込まない**: 本ページが記録する HPCC(輻輳制御ループへの直接組み込み)・INTFusion(host/network テレメトリ融合による異常検知)・SDN本第2章(フォワーディングルール検証の可能性)の3用途はいずれも、INT が生成する計測データを「誰が」「何のために」使うかという利用側の視点からの記述だった。SDN本第10章(図60)はこれと逆に、INT を「細粒度計測がコード生成・形式検証ツールへフィードバックされるクローズドループ制御」という一般アーキテクチャの中の一部品として位置づける——INT ソース/トランジット/シンクという役割分担(第2章)そのものは繰り返さず、代わりにこの計測が「ディスアグリゲーションが本質的に持つ価値(構成による正しさの推論可能性)を補完する」とし、SDN が目指す検証可能性(verifiability)という最終目標にとってなぜ INT が不可欠なのかという、より上位の設計原理からの位置づけを与える。ただし、この閉ループがどのような検証アルゴリズムでネットワークの挙動を実際に検証するのか、具体的な実装は本章でも示されない——第2章が既に留保していた「具体的な実装例は本書に明示されない」という限界は、終章でも解消されないまま残る。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 10 Future of SDN]], [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 2 Use Cases]] §2.6) ## 未解決の問い - INT による「フォワーディングルール検証」(オペレータの意図した転送とデータプレーンの実際の挙動の一致確認)を具体的に実装したシステムはあるか。[[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 2 Use Cases]]はこの応用の可能性を述べるにとどまり、終章(第10章)もINTをクローズドループ制御の測定入力源として一般的な図式(図60)で位置づけるにとどまり、パケットへのルールID埋め込み方式や検証アルゴリズムといった具体的な実装には踏み込んでいない。本書ではこれ以上具体化されないため、本 wiki 外のソース(p4vなど第10章が挙げるFurther Reading文献)を追う必要がある。 - INTFusion は 10 GbE sNIC でのプロトタイプで、100G/400G/800G Gbps のデータセンターファブリックへの適用性は未検証。ラインレートで INT を処理する sNIC/DPU のスケーラビリティはどうなるか。 - フローレット抽象化のパケット間隔閾値をどう自動チューニングするか。異なるワークロード(ストレージ・ML 訓練・Web サービス)で最適値はどう変わるか。 - クロスホストのタイムスタンプ対応が NTP 精度に依存しており、マイクロ秒級の遅延計測ではずれが問題になりうるか。PTP(精密時刻同期)への移行で改善されるか。 - Centralizer(Elasticsearch ベース)のスケーラビリティは大規模クラスタ(数千ホスト)でどうなるか。 - INT の命令ビットマップによる収集メタデータの選択と、ホスト CPU オーバーヘッド(特に Spooler のポーリング)の間の最適なトレードオフはどこにあるか。 ## 関連 - 概念: [[テレメトリ]] / [[ネットワーク監視]] / [[データセンター輻輳制御]] / [[eBPF]] / [[限定観測可能性]] / [[プログラマブルデータプレーン]] - ソース: [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]] / [[@2019__SIGCOMM__HPCC - High Precision Congestion Control]] / [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] / [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 7 End-to-End Data]] / [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 2 Use Cases]] / [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 10 Future of SDN]](検証可能なクローズドループ制御の測定入力源としての位置づけ) - エンティティ: [[Leonardo Alberro]] / [[Matias Richart]] / [[Eduardo Grampin]] / [[Universidad de la República]] / [[Alibaba Group]] / [[Yuliang Li]] - 関連 MOC: [[AIOps - Fault Localization - MOC]] / [[Systems for ML - MOC]] ## 出典 - [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]](§I-III) - [[@2019__SIGCOMM__HPCC - High Precision Congestion Control]](§3.1・§4.1、INT を輻輳制御ループへ直接組み込むパケットフォーマットと利用法) - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]](ch.5 §5.2, §5.3、P4 の設計意図との対比材料) - [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 7 End-to-End Data]](Perspective節、ビッグデータ/アナリティクスの文脈でのINTの教科書的な位置づけ) - [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 2 Use Cases]](§2.6、INTソース/トランジット/シンクの役割分担、マイクロバースト検知とフォワーディングルール検証) - [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 10 Future of SDN]](図60、INTが検証可能なクローズドループ制御を成立させる測定入力源としての位置づけ)