要約

  • RFC 3148は、ネットワーク容量を一つの普遍的な数値で定義しなかった。転送方式を明記する複数のBulk Transport Capacity測定として枠組みを示した。
  • 損失のまとまり、再送タイムアウト、TCPのACKクロックなどは測定値の違いを説明する手掛かりになる。ただし、一つの試験フローだけで全利用者やアプリケーションの性能は判断できない。

数字ほど実験は単純ではない

二台のホストが同じ経路で大きなファイルを送る場面を考える。どちらの試験も同じボトルネックを埋め、経過時間あたりの有効データを計算する。結果の単位はいずれもビット毎秒だ。それでも、一方の輻輳制御方式は連続したパケット損失から素早く立ち直り、もう一方は確認応答による送信の刻みを失って再送タイマーの満了を待つ。経路は変わっていないのに、測定速度は変わる。

これは計算ミスではない。RFC 3148が見えるようにしようとした問題だ。2001年7月にInformational RFCとして公開された「A Framework for Defining Empirical Bulk Transfer Capacity Metrics」は、Bulk Transport Capacity（BTC）を、TCPのような輻輳を考慮する一つの転送接続が長期的に出す平均速度として扱う。基本量は、重複を除いたデータ量を経過時間で割ったものだ。しかし、その分かりやすい式の中には実装上の選択が含まれていた。

「容量」という語から、リンクに固定された属性を思い浮かべがちだ。RFC 3148はそこまで主張しない。直感的な基準として、一つの理想的なTCP実装が経路上で出す長期平均速度を置いた。一方、IETFの仕様は複数の輻輳制御方式を認め、それぞれにも実装の幅がある。その差が比較不能な測定値につながるなら、「この経路のBTC」は単独では意味が定まらない。方式を添える必要がある。

準拠TCPは同じ測定器ではない

転送プロトコルの標準は共通動作を定めるが、実装の細部まですべて固定するわけではない。RFC 5681もTCP輻輳制御を説明しつつ、測定に影響する選択を残している。そこでRFC 3148は、輻輳ウィンドウの増やし方、スロースタートしきい値と等しい場合の扱い、損失回復方式、セグメントサイズ、再送タイマー、計時の開始と粒度などを、BTCの各方式が定義するよう求めた。

これらは見た目の設定ではない。送信速度は経路から戻るACKに左右される。損失は高速再送と回復を始めることもあれば、送信側をタイマー待ちにすることもある。SACKやNewRenoによる回復、再送タイムアウト、送信バッファー、受信ウィンドウ、最大セグメントサイズは、一定時間内に一つのフローが運ぶ量を変え得る。その仕組みはRFC 5681、RFC 6298、RFC 2018、RFC 6582、RFC 6675に記録されている。仕組みが定義されているからといって各実装が同じになるのではない。試験で選んだ動作が、結果の意味を構成するということだ。

RFC 3148は「Congestion Avoidance Capacity」という狭い指標と、より包括的なBTCを区別した。前者は再送タイムアウトとスロースタートが作動する期間を除く。安定した輻輳回避の速度を表せる反面、実際の大容量転送で無視できない回復動作を落とすこともある。どの指標が常に優れているという話ではない。名前と数字だけで、含めた動作や除外した動作を隠してはならないという話だ。

差を説明する記録を残す

目立つ速度値だけでは、二つの方式がなぜ違ったのか分からない。RFC 3148は、補助指標を収集するか、後で導き出せるだけの情報、たとえばセグメントトレースを残すよう勧めた。候補には、損失のまとまり、パケットの並べ替わり、タイムアウト、輻輳ウィンドウの推移、ACKクロックの維持、試験ホスト内のパケット損失やキュー、セグメントサイズ、逆方向経路の負荷がある。

ACKクロックは分かりやすい例だ。TCPは、すでに届いたデータへの確認応答を受けて新しいデータを送ることが多い。その刻みが崩れると、タイムアウトとスロースタートによる回復で時間を失う。定常時の速度値だけでは、その時間が見えないことがある。同じ損失に直面しても回復動作が異なるため、二つの方式の値が分かれることもある。トレースは調査を可能にするが、どのルーターやキューや事業者が原因だったかを自動で証明するものではない。

この考え方は、指標の定義と測定手順を区別し、不確実性も扱うRFC 2330の測定規律につながる。後のRFC 5166は輻輳制御方式の評価指標を扱い、RFC 6349はTCPスループット試験の枠組みを示した。どちらも関連する背景資料だが、RFC 3148を唯一の万能試験に変えるものでも、特定事業者が実装した証拠でもない。

RFC 3148には経済面で微妙な警告もある。輻輳の動きが非線形なら、ある条件ではリンク速度を上げたのにTCPまたはBTCの測定値が下がる可能性がある。これは可能性と研究課題の指摘であって、観測済みの商用障害、設備増強全般に通じる法則、帯域を増やすと利用者に害が出るという証明ではない。測定値が変わったときは、商業的な結論を出す前に試験方式と経路の記録を残すべきだという教訓である。

試験もネットワークを使う

BTCは少数の受動的な観測ではなく、大量のデータ転送で測る。試験はボトルネックを埋めようとする。RFC 3148は、方式によっては通常のTCP以外のパケットを用い、ネットワーク事業者にはサービス拒否攻撃に見えることがあると指摘した。そのため、試験の時間、量、頻度を関係者で調整するよう勧めている。試験パケットが見分けられて特別扱いされる場合や、似たパケットを挿入して測定を歪められる可能性も挙げた。

運用への影響は両端の外にも及ぶ。試験側はアルゴリズム、時間、バッファー、計測器を選ぶ。経路は遅延、損失、並べ替わり、キューの状態を持ち込む。事業者には容量を消費する強いフローが見える。解釈と再試験に足る条件を記録し、その経路と時間帯で試験の許可を得る必要がある。

一つの結果が言えること

RFC 3148は、近接するRFC 3133の話とは異なる。RFC 3133はFrame Relayの方向別配送比率を定義し、小さな確認フレームの損失が大量の再送につながると、リンク層の比率が良くてもアプリケーションは遅くなり得ると述べた。これは配送計数に固有の仕組みだ。RFC 3148が問うのは、複数の転送方式が規格に適合しながら異なる動作をするとき、単一フローの大容量転送測定をどう比較するかである。

答えは測定方法を丁寧に扱うことだ。転送動作を明記し、補助証拠を保管し、試験ホストが先にボトルネックになっていないか確かめる。可能なら往路と復路の影響を分け、条件を書いて実験を繰り返す。その結果が支えるのは限定された命題になる。すなわち、このように定義された方式が、この観測経路で、この時間に、これだけの重複しないデータを運んだということだ。

一つの結果だけで、物理リンクの速度、競合フロー全体に使える容量、あらゆるTCP実装の速さ、SLA違反、アプリケーションの完了時間、利用者の体験までは証明できない。原因を特定するには、トレースと独立した証拠も必要になる。

歴史的な貢献は控えめだが長く残る。RFC 3148は、測定器の内部にある選択を一つのラベルで消させなかった。見出しになる数字は残し、その数字とともに方式も示すよう求めた。

解釈の視点として、Lu HengのNote 64（最小限の初期仕様とローカルな選択）およびNote 20（形式的な記述と観測可能な現実の区別）を参照した。これらは編集上の枠組みであり、RFC 3148の著者の主張ではない。

出典

  1. RFC 3148 — A Framework for Defining Empirical Bulk Transfer Capacity Metrics
  2. RFC EditorによるRFC 3148の記録
  3. RFC 2330 — Framework for IP Performance Metrics
  4. RFC 3133 — Terminology for Frame Relay Benchmarking
  5. RFC 5166 — Metrics for the Evaluation of Congestion Control Algorithms
  6. RFC 6349 — Framework for TCP Throughput Testing
  7. RFC 5681 — TCP Congestion Control
  8. RFC 6298 — Computing TCP's Retransmission Timer
  9. RFC 2018 — TCP Selective Acknowledgment Options
  10. RFC 6582 — The NewReno Modification to TCP's Fast Recovery Algorithm
  11. RFC 6675 — A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment
  12. Lu Heng, Note 64 — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  13. Lu Heng, Note 20 — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile