要約

  • RFC 5136 では、容量値にプロトコル層、パケット群、送受信点、開始時刻、区間が必要になる。
  • 公称物理リンク容量は理論上限であり、特定フローが利用できる IP 容量ではない。
  • IP レイヤー容量は宛先で正しく受信された IP ビットを数え、アプリケーション上の有用性までは保証しない。
  • Type P は対象パケットを定める。マーキング、キュー、ACL、経路制御、負荷分散で扱いが変わるからだ。
  • 使用量は実際に受信されたトラフィックで、利用率はそれを限定済みの容量で割った値である。
  • 利用可能リンク容量は区間中の未使用分、利用可能経路容量は各リンクの未使用分の最小値になる。
  • 最小容量の narrow link と最小利用可能容量の tight link は一致しなくてよい。
  • T と I を失った測定値は、別の観測との比較にも現在状態の証明にもそのまま使えない。
  • 周期的な測定が周期的な負荷と同期すれば、サンプル数を増やしても偏りを繰り返す。
  • 重複パケット、ヘッダー、再送は資源を使うが、利用者に届く一意なデータを増やすとは限らない。
  • Bulk Transfer Capacity は輻輳応答するトランスポートの一意データを扱い、RFC 5136 の IP 量とは別物である。
  • 経営判断では、物理能力、IP 観測、現在の余力、契約上の権利、アプリ結果を別々の証憑にする必要がある。

10G という表示が答えていないこと

資産台帳に 10 Gbit/s と表示されている。これはインターフェースの物理モードとして正しいかもしれない。しかし、対象パケットが送信元から宛先まで毎秒どれだけ正しく届くか、混雑時にどれだけ余力があるか、アプリケーションが期限内に一意なデータを受け取れるかは答えていない。

RFC 5136 は物理層の理論上限を NomCap(L) と呼ぶ。通常は一定だが、衛星トランスポンダーの動的追加のように変動する例も挙げる。重要なのは固定性ではなく役割である。NomCap(L) は上限を示し、後続の IP レイヤー定義を自動的に決めない。

符号化、フレーミング、下位層エラー、パケット長、装置の処理能力が物理表示と IP 観測の間に入る。したがって、ポート速度は有用な証憑だが、経路容量、現在の余力、加入者の権利、アプリ結果を代弁する証憑ではない。

組織上の問題は、最初の数字を所有する部門が後続レイヤーの判定権まで得ることだ。「設置した」が「提供した」になり、「提供した」が「受け取った」になる。RFC 5136 は、この言い換えの前に測定対象の主語を戻す。

IP レイヤーで正しく受信した、という限定

IP レイヤービットは、宛先 D が [T,T+I] に正しく受信した IP パケットについて、IP ヘッダー先頭からペイロード末尾までのオクテット数を八倍して求める。開始時刻と区間は表示用情報ではなく結果の一部である。

IP より下で壊れ、IP 処理へ渡せないデータは数えない。IP ヘッダー検証に失敗したパケットも数えない。一方、トランスポートやアプリケーションの正しさは要件ではない。処理可能な IP フラグメントは、完全な上位オブジェクトへ再構成できなくても資源を消費したため数えられる。

ここに、ネットワーク成功と利用者成功の間の境界がある。ヘッダー、孤立フラグメント、再送ペイロードは経路上の実作業である。しかし、新しい有用データとは限らない。IP 指標は自分の問いに正しく答えていても、アプリケーションの問いには答えていない。

時間境界が一つのパケットを横切る場合、部分パケットは除外される。長い高負荷区間では影響が小さくても、短く疎な区間では偏り得る。最終レートだけ保存すれば、後からその影響を検証できない。

Type P が測定値の利用者を決める

同じ送受信点でも、すべてのパケットが同じ経路とキューを通るとは限らない。マーキングで優先度が変わり、ACL が特定プロトコルを落とし、ポリシーが経路を変え、負荷分散が別リンクを選ぶ。Type P はこの対象フローまたは集合を定義する。

事業者は資源全体を見るため広い Type P を選べる。アプリケーション利用者は実トラフィックに近い狭い Type P を選べる。どちらも正当だが、互換性は自動ではない。優遇された測定パケットの結果を通常トラフィックへ移すには、同じ扱いを受ける証拠が要る。

パケット長も下位層オーバーヘッドを変える。ヘッダー圧縮では媒体上のビット数が減っても、RFC 5136 の IP カウンターは展開後の IP 長を数える。層間の変換を記録せず二つの値を比較すれば、設計どおりの差を障害と誤認する。

測定報告には、パケット種別、マーキング、サイズ、キュー、経路、共有トラフィックが必要になる。「速度試験に成功した」だけでは、誰の容量を測ったのか分からない。

narrow link と tight link

C(L,T,I) は、Type P の IP ビットが S から送られ、区間中にリンク L を越えて D で正しく受信される最大レートである。経路容量は各リンク容量の最小値で、そのリンクが narrow link である。

Used(L,T,I) は任意の送信元から実際に正しく受信された IP トラフィックで、最大値ではない。利用率は Used/C。分母の層、Type P、区間を知らないパーセント表示は意味が欠ける。

利用可能リンク容量は C*(1-Util)、利用可能経路容量は各リンクの利用可能容量の最小値である。この最小余力を持つリンクが tight link になる。低速でも空いているリンクと、高速でも競合トラフィックで埋まったリンクがあれば、narrow と tight は別になる。

この差は投資判断を変える。narrow link の物理レートだけ増やしても tight link の混雑が残れば、現在の余力は増えない。反対にトラフィック移動やスケジューリング変更は、物理設備を変えず余力を改善できる。どちらも同じ「増速」と呼ぶべきではない。

時刻を失った可用性は現在を証明しない

利用可能容量は使用量に応じて揺れる。RFC 5136 は T と I の報告を求め、性質を把握するには測定列を提案する。ただし、列を作るだけでは偏りは消えない。

測定周期が基礎負荷の周期と整数関係にあれば、毎回静かな位相だけ、または混雑位相だけを見ることがある。同じ位相の百回測定は、偏りのない一回にはならない。スケジュール、ジッター、欠測、経路変更、保守と負荷周期を残す必要がある。

鮮度も判断ルールである。昨夜の値は昨夜について優れた証拠であり得るが、経路、キュー、利用者構成、端末ソフトが変わった後の現在を自動的に証明しない。「最新」という画面表示は、観測の有効期限ではない。

二重に届いたパケットと一度しか増えない価値

ハードウェアがパケットを複製し、宛先で二つとも正しく受信された場合、一般的定義では双方が数えられる。リンク資源を二度使ったという問いには正しい。利用者が得た一意情報という問いには、二つ目は価値を増やさない。

そこで一意送信だけを数える Type P 条件や、別のアプリ指標が必要になる。生の資源消費と有用データを同時に保存すれば、差そのものが重複障害を示す。合計レートだけなら、無駄が高い数字の中に隠れる。

RFC 3148 の Bulk Transfer Capacity は、輻輳応答する一つのトランスポート接続が運ぶ一意データを見る。ヘッダーと再送データを有用量から外し、損失、遅延、並べ替え、回復アルゴリズムの影響を受ける。RFC 5136 の IP 量とは異なる視点であり、一致を要求できない。

RFC 9097 は後に一方向 IP 容量の方法と統計を具体化し、RFC 9946 は制御された UDP 試験を定めた。再現可能性は高まるが、試験結果が加入者への資源予約、SLA 判定、アプリ完了へ変わるわけではない。

判断に耐える証憑の順序

最初に媒体、インターフェースモード、ネゴシエーション、NomCap(L) を記録する。次に送信元、宛先、完全な経路と全リンク。続いて層、Type P、サイズ、マーキング、正受信条件、エラー、分割、重複規則。そして T、I、時計、サンプリング計画を残す。

その上でリンク別 C、経路最小値、使用量、利用率の分母、リンク別余力、tight link を解釈する。ルート、キュー、負荷分散の状態も結果に結び付ける。能動試験は投入負荷と安全制限を記録し、観測対象の混雑を自ら作っていないか確かめる。

契約上の約束は別である。コミットレート、バースト、パーセンタイル、例外、判断権者は契約から来る。アプリケーションは一意バイト、完全性、再試行、完了時刻、利用者結果を示す。RFC 5136 はその欄を推測で埋めない。

値が食い違えば診断が始まる。物理は正常でも特定 Type P が詰まる。IP 容量は高くても余力が低い。余力はあってもトランスポート制御が伸びない。転送できても業務期限に遅れる。緑の一数値はこの全体を裁けない。

薄い標準と厚いローカル証明

RFC 5136 の強さは節度にある。共通語彙によって研究者、ツール作者、事業者、利用者が同じ量を比較できる。一方で、資源を設置・予約せず、経路を選ばず、試験負荷を許可せず、契約や利用者結果を決めない。

共通層は相互運用に必要な不変条件を保ち、ローカルな実装と結果はローカルな証拠で確かめる。物理的可能性から IP 観測、現在余力、伝送挙動、利用者結果へ進むたび、新しい証憑が必要である。

経営は、あるカウンターの所有者がサービス全体の採点者になることを防ぐべきだ。資産、ネットワーク測定、運用、契約、アプリケーションが別々に責任を持つ。数字が見やすいことは、権限移譲の根拠ではない。

ポート表示は正しいままでよい。RFC 5136 が求めるのは、その正しさを観測していない層まで拡張しないことである。

出典

  1. RFC 5136 HTML
  2. RFC 5136 プレーンテキスト
  3. RFC Editor レコード
  4. IETF Datatracker レコード
  5. RFC 5136 履歴
  6. RFC 5136 エラータ検索
  7. RFC 1812
  8. RFC 2330
  9. RFC 2544
  10. RFC 3148
  11. RFC 4656
  12. RFC 6349
  13. RFC 6703
  14. RFC 7312
  15. RFC 8337
  16. RFC 9097
  17. RFC 9473
  18. RFC 9946
  19. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  20. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  21. Running-Code Primary