要約

  • RFC 2416は、9600 bpsのモデムの手前に3パケット分のキューを置いた受信経路をシミュレートした。この条件では、4パケット開始の4個目は必ず落ちる。
  • しかし局所的な1個の損失だけで接続全体の優劣は決まらない。通常のslow startも後に似たバーストを作り、二つのシミュレーションは時刻とパケット番号をずらすとほぼ同じ回復状態に達した。
  • モデムの送信時間を差し引くと、4パケット開始は多くの場合およそ0.229秒先行した。著者は結論を「この特定のケース」に限り、実機の挙動とネットワーク全体の安全性は未解決とした。
  • 歴史的な教訓は、基準となる1パケット開始の後続損失も含めて比較すること、そして一度のシミュレーションを普遍的な安全証明にしないことだ。

0.229秒はどこから来たのか

RFC 2416で意外なのは、4パケット開始が損失を避けたことではない。損失は前提として置かれている。比較点で二つのトレースがほぼ同じ回復状態に入ったとき、4パケット側は時間で2.889秒、パケット番号で3個分先にいた。ところが9600 bpsのモデムでは、1024バイトのTCPセグメントを3個送るのに2.66秒かかる。シミュレーション上の差し引きは、多くの場合0.229秒の先行になった。

著者の説明では、通常の開始では受信側の遅延ACKタイマーを待つ間、モデムが送るもののない時間を過ごす。4個を先に出すと、その空白の一部を使える。ただし、失われるパケットが二つのトレースで異なるため、すべての試行が同じ差になったわけではない。0.229秒は全接続に約束された性能値ではなく、このモデルでの多数ケースの比較値である。

通常の開始も、後にはバーストを作る

1パケット開始のトレースでは、パケット1を0秒に送る。1.222秒後のACKでパケット2と3を送り、2.444秒後にはパケット4と5を送る。3.278秒にパケット3を確認した後、パケット6と7が出る。後にパケット7が失われ、8.278秒時点の3個目の重複ACKが再送を起こす。

4パケット開始では、パケット1から4を0秒に送る。3個のキュー枠に収まらずパケット4を失い、5.389秒の3個目の重複ACKで再送する。比較した時点では双方の状態がほぼ一致し、その後のトレースも2.889秒と3パケットのずれを除けばほとんど重なる。つまり1パケット開始も、損失のない経路をそのまま通り抜けたわけではない。

この設定は具体的だ。送信元から100 Mbps・遅延なしのリンク、1.5 Mbps・片道25ミリ秒のリンク、9600 bps・片道150ミリ秒のモデムリンクを経て受信側に届く。モデム直前のルーターは3パケット分を保持し、1つが送信中なら2つが待てる。キューあふれは仮説ではなく、このトポロジーの確定条件だった。

実験はLBLのNS 1.2a2を用い、Tahoe、Reno、SACK、FACKの各TCPモジュールを比較した。本文はTahoeの例を追い、結論は選択したモジュールによらないように見えたと述べる。パケットは送信時間計算用に1024バイトとされ、モジュールはTCPのシーケンス番号機構ではなくパケット番号を使った。観測点も送信元近くの高速リンクに置かれた。記述が細かいからこそ、実際に調べた範囲も見える。

接続の時間とネットワークの安全性は別の話

RFC 2416は1998年のInformational文書で、標準を定めない。結論も「この特定のケースでは」有害でなかった、というものだ。著者は、4パケット開始がネットワーク全体に対して安全かは未解決だと記し、実際のTCP、モデム、3バッファ制限での再現を望んだ。報告されたのは接続トレースであり、並行する多数のフローに対する公平性の試験ではない。

Heng LuのRunning-Code PrimacyとReality Layersは、歴史的な著者性の主張ではなく、ここでの分析レンズとして使う。前者は思い込みより実行トレースを重く見る一方、証拠の射程を実際に試したコードと経路に限る。後者はキュー内の損失、単一接続の完了時間、ネットワーク全体の安定性を別の層として扱う。RFC 2416が示したのは最初の二つまでで、三つ目については著者自身が判断を留保した。

Sources