要約

  • 新しいトランスポートが長時間フローのスループットを仮に35%伸ばしても、短時間フロー、キュー遅延、goodput、既存トラフィック、経路変更後の振動を測っていなければ、ネットワーク改善とはいえない。
  • RFC 5166は複数の指標間の trade-off を求め、RFC 5033は安全性と推奨を分けて破綻領域を調べさせる。RFC 2914は、個別の攻撃性が共有ネットワークの有用な仕事を減らす仕組みを示す。

評価表を逆から読むと、本当に知るべきことが見える。「35%向上」の行ではなく、空欄を探す。99パーセンタイル遅延はあるか。小さな転送の完了時間はあるか。標準 TCP と競合したか。逆方向トラフィックを加えたか。帯域や経路が変わった直後を測ったか。

35%という値は分析用の仮定であり、特定のアルゴリズム、製品、運用網の実績ではない。再現可能な測定であっても、その外側の判断まで自動的に正しくなるわけではない、という境界を示すための数字だ。

「速さ」を観測した主体は誰か

2008年3月のRFC 5166は、Sally Floyd を editor とする IRTF Transport Modeling Research Group の Informational 文書であり、Internet Standard ではない。最適化すべき唯一の指標について合意があるとは書いていない。合意として置くのは、単一指標ではなく、複数指標の trade-off で輻輳制御を評価することだ。

スループットには少なくとも三つの読み方がある。ネットワークはリンク全体の利用率を見る。フローは転送速度や完了時間を見る。利用者は仕事が終わるまでの待ち時間を見る。goodput なら、重複や下流で捨てられるパケットではなく、役に立って到着した量を問う。

この違いを消すと、満杯のリンクが効率的に見える。実際には再送や、後段で廃棄されるパケットが希少な帯域を消費しているかもしれない。平均値も分布を消す。少数の大きなフローが得をして、多数の短い要求が尾部に追いやられても、一つの平均では見えない。

遅延も同様だ。bulk transfer 自身が一パケットの待ち時間を気にしなくても、FIFO キューを共有する音声や操作トラフィックは同じ待ち時間を受ける。平均遅延が小さくても、tail が利用体験を壊すことがある。損失率には burst、ECN mark、再送、下流廃棄の区別が必要になる。

平衡点へ向かう途中を捨てない

帯域低下、競合フローの開始、移動、経路変更、断続的な接続は、制御器の本性を過渡状態で表す。反応が遅ければ混雑が続く。短い変化に強く反応しすぎれば、送信率が落ち込み、空いた後に再び急増し、キューと速度が揺れる。

RFC 5166が応答時間と oscillation を並べるのはこのためだ。速い反応と滑らかな挙動は別の価値であり、同時に最大化できるとは限らない。収束時間、overshoot、複数の時間幅における分散、回復中の損失を観測する必要がある。

実験の最後だけを比べれば、移行費用は存在しなかったことになる。しかし運用では、変化から次の安定状態までがサービスだ。warm-up として切り捨てた区間に、利用者が負担する結果がある。

公平性の式より前に単位を決める

一つの flow、一つの session、一人の user、一つの送受信 host pair のどれを公平性の単位にするのか。RTT が違うフロー、複数の混雑リンクを通るフロー、リアルタイムと bulk を同じ速度にするのが望ましいのか。Jain index、max-min、proportional fairness は同じ価値判断ではない。

RFC 5166はこの不一致を隠さない。だから公平性を省略してよいのではなく、誰を比較し、何を守ったかを記録しなければならない。新方式の伸びが既存 TCP の低下から生じたなら、二つを別々のニュースにしてはいけない。

Floyd が編集したRFC 2914は、長年の共同研究をもとに、offered load の増加がネットワークの useful work を減らす congestion collapse を説明する。さらに、より攻撃的な transport や application が局所的に勝ち、それを他者が追う arms race を警告する。新しいフローだけを採点する benchmark は、その競争を高性能として表彰しうる。

Experimental にも二つの境界がある

Sally Floyd と Mark Allman によるRFC 5033は Best Current Practice である。代替輻輳制御を評価する際、利点と欠点を含む十分な科学的検討を求める。

一つ目の境界は、global Internet の best-effort traffic で安全に実験できると判断された方式と、simulation、testbed、controlled environment に留めるべき方式の間にある。二つ目は safe と recommended の間にある。共有網に重大な害を与えなくても、特定条件で利用者に悪い方式は推奨できない。

評価対象は標準 TCP、SCTP、DCCP への影響、wireless などの難しい環境、複数の帯域・RTT・reverse-path 負荷・statistical multiplexing・queue 方式に及ぶ。どこで性能が崩れるかを探し、極端な混雑での full backoff、同方式間の公平性、misbehaving node や攻撃者、突然の変化、incremental deployment を扱う。

つまり、失敗条件は研究の傷ではなく、配備契約の中心だ。「ここでは使わない」という文章だけで scope が守れるか、protocol 上または運用上の強制が必要かも判断しなければならない。

名前を広げすぎない

Floyd 自身のICIR biographyは、BART のリアルタイム計算機システム、UC Berkeley、LBNL、ICIR へ続く経歴を記録する。projects archiveには RED、ECN、DCCP、TFRC、HighSpeed TCP、modeling、評価手法が並ぶ。

これは継続的な研究参加の根拠であり、単独発明の証明ではない。RFC 5033には Mark Allman がいる。各技術には共同著者、reviewer、implementer、community がいる。RFC 5166も TMRG から詳細な feedback を受けたと記す。本稿で確認できるのは、Floyd の公開記録が繰り返し、他のトラフィックが負う費用と評価の限界を可視化したことだ。

グラフに反証可能性を残す

配備前の記録には、実装 version と default、fallback、topology、queue、RTT、reverse load、競合 traffic、goodput・完了時間・遅延・損失の distribution、変化と障害への応答、canary、停止条件、rollback、未観測領域を結び付ける必要がある。

Lu Heng のRunning-Code Primacyreality rather than advocacy を論じた文章は、Sofia Ren の後年の分析レンズとなる。technical claim は running outcome によって否定されうる状態を保たなければならない、という比較だ。これは本稿の2026年の解釈であり、Floyd、TMRG、IETF の私的意図を述べるものではない。

スループットを軽視する必要はない。ただし、自分の正しさを自分一人で採点させてはいけない。複数の指標に耐え、外部費用と失敗領域が見え、反証が出たときに撤回できる範囲だけが、次の配備範囲になる。

出典