要約

  • RFC 10052は、反射パケットの長さ、個数、送信間隔を要求するための任意TLVをSTAMPに追加した。
  • Cフラグが示すのは、出口MTUまたは反射器側のレート・総量制限により、要求どおりの応答列を作れなかったかどうかである。
  • アプリケーションに似せた試験パケットが届いても、実アプリの経路、容量、品質、利用者の結果まで確認したことにはならない。

測定画面に「8/8」と表示されると、試験は終わったように見える。だが、8という数が答えているのは受信個数だけだ。どの処理系を通ったのか、実アプリと同じ条件だったのか、利用者の取引が成功したのかは、その数からは分からない。

2026年9月に公開された RFC 10052 は、Session-Senderから受けた1個の試験パケットに対し、Session-Reflectorが異なる長さや複数個の応答を返せるようにする。文書が目指すのは、特定の測定場面でアプリケーション・トラフィックの条件により近づけることだ。「近づける」は「同じである」とは違う。この一語の距離を守れるかが、測定の信頼性を決める。

送信側が書いた値は、まだ観測値ではない

新しい Reflected Test Packet Control TLV は、IANAのSTAMPレジストリでタイプ12に割り当てられた。RFC 8762 の基本交換と RFC 8972 の拡張構造の上で、希望する応答長、応答数、連続する応答間のナノ秒間隔を伝える。

ところが、反射器はその値を無条件に実行しない。実際の長さは、現在のSTAMPモードと拡張を収める最小長以上で、4オクテット境界にそろえられる。出口インタフェースのMTUを超えるなら、要求された列の代わりにMTU長の1個だけを返す。

個数もローカル制御を受ける。対応する反射器は、1要求から生じるデータレートと総データ量の両方に上限を設けなければならない。超過する要求には1個だけを返す。要求数がゼロなら通常は応答せず、受信パケットを捨てる。ローカル方針による例外は可能だが、最初から無応答を望むなら、RFCはReturn Pathの専用制御を推奨する。

従って、監視項目は少なくとも四つ必要だ。要求値、反射器の判断、反射器が送出した数、収集点が観測した数である。これらを一つの「応答数」にまとめると、障害時にどの境界で差が生じたかを追えない。

Cフラグは反射器の局所的な返答

ビット位置3にはC、名称Conformantが割り当てられた。senderは送信時にゼロにし、reflectorは受信した値を無視する。反射器が1を立てるのは、要求長が出口MTUを超えた場合、または要求レート／総量がローカル上限を超えた場合だ。それ以外ではゼロにする。

1個だけ返ったパケットの長さを見れば、二つの理由を区別できる。要求より短ければMTU、要求長と同じならレートまたは総量の制限である。これは運用上役に立つ、明確な診断情報だ。

しかし、C=0はエンドツーエンドの成功票ではない。全パケットの到着、経路の同一性、空き容量、アプリと同じキュー処理を保証しない。C=1も回線混雑の断定には使えない。単に反射器の管理者が慎重な上限を置いた結果かもしれない。

Lu Hengの現実の層という整理を当てはめると、混同が見えやすい。TLVは依頼、Cは局所判断、送信カウンタは実行記録、収集側のpcapは観測、アプリのテレメトリは別系統の観測、顧客行動はさらに後段の結果だ。同じ時刻に発生しても、互いの代用品にはならない。

記録 そこから言えること まだ言えないこと
TLVの値 senderがこの形を要求した reflectorがその形を送った
Cフラグ 二つの例外を使ったか 経路容量が十分か
送出カウンタ 反射器が送信を記録した 収集器まで届いたか
収集側キャプチャ この観測点で列を受けた アプリも同じ条件を経験したか
アプリ指標 指定アプリがこの挙動を示した 他の利用者や経路も同じか

RFC 10052の範囲は「操作部」まで

第4.1節は、アクセスレートのメトリクスと測定方法を文書の範囲外としている。新TLVは RFC 7497 が求めた非対称なサイズやレートの制御に応えるが、容量値の算出方法までは定めない。

RFC 7497は、利用者トラフィックが存在するIn-Service試験と、開通前や保守中のOut-of-Service試験を分ける。試験パケットの特徴が利用者パケットと違えば、ネットワーク側の扱いも違い得る。また大量の試験トラフィックは、結果をゆがめ、自ら混雑を生む。RFC 7799 にいうアクティブ測定は、専用トラフィックを発生させる行為であり、観測対象に触れずに見る方法ではない。

RFC 9097 と RFC 9946 は、容量測定について負荷の増減、試験端点、競合トラフィックなどを別途定義する。この追加条件が必要だからこそ、応答列をそのままMbpsやアプリ品質に置き換えてはいけない。

マルチキャストの絞り込みは標本設計ではない

マルチキャストでは、根から送った一つの試験パケットに複数の葉が応答し得る。Layer 2／Layer 3 Address GroupサブTLVは、MACアドレスのマスクやIPプレフィックスに合う反射器だけを残す。文書には16台に1台が合致する例もある。

ただし、アドレスの16分の1は利用者の無作為抽出ではない。アドレス体系はベンダー、設置時期、地域、ネットワーク構成と結びついている可能性がある。負荷を減らす決定的ルールを、利用者全体の代表性に昇格させるには、別の母集団定義と抽出設計が要る。

マルチキャストは反射増幅も引き起こす。RFCはレート制御を必須とし、最初の要求では応答数1を選ぶよう求め、機能を管理可能かつ初期状態で無効にする。送信元を偽装した要求はDoSに使われ得るため、識別保護が必須で、STAMP認証モードまたはHMAC TLVが推奨される。RFC 8085 のUDP負荷原則も適用される。

収集点を変えれば、証拠の視点も変わる

RFC 9503 のReturn Path／Return Address拡張と組み合わせれば、応答をsenderではなく別の測定収集器へ送れる。RFC 7594 のLMAPは、測定エージェント、制御、収集の役割を整理する。カメラ映像と同じ方向へ試験を送り、戻りだけ分析拠点へ向ける例も示される。

これは便利だが、収集器は万能の観測者ではない。自分の場所と時計で受けたパケットしか証明できない。往路が映像と近くても、フロー識別、負荷分散、サービスクラス、瞬間的なキュー状態が同じとは限らない。アプリ相当性を主張するなら、アプリ側の記録を追加しなければならない。

DatatrackerのRFC記録、草案履歴、9月のIETF活動報告は標準化と公開を示す。現行情報ページ、テキスト版、XML版は規定の照合に使える。どれも実装・導入数の調査ではない。

動くコードの優先に従えば、運用上の主張には実装名、版、設定、観測結果が要る。最小初期仕様は、共通部分を検証可能な制御に限り、測定法や閾値を現場に残す設計を支持する。エージェンシー問題は、試験形状、反射上限、対象群、収集点、解釈を誰が決めたかを表に出す。

8個が返ったという事実は有用だ。有用だからこそ、それ以上の意味を勝手に背負わせない。

Sources