要約

  • RFC 2414は、TCPの初期ウィンドウ拡大を必須ではなく任意とした。上限は min(4*MSS, max(2*MSS, 4380 bytes)) で、新規接続の最初の送信に関する規則だった。
  • 2セグメントなら遅延ACKタイマーの満了前に応答を促し、短い転送を早める可能性がある。RFC 2415のns-2シミュレーションでは、モデル化した多くのケースでWebページの中央値が下がった。
  • 混在グループの結果は一つの結論には収まらない。中程度の負荷ではIW=3がIW=1を悪化させなかった一方、32対32のWebクライアントによる極端な混雑ケースでは、大きい窓のグループ自身が不利になった。
  • これはシミュレーションであり、インターネット上の実導入調査ではない。接続単体の高速化と、共有経路で影響がどう配分されるかは別の問いだ。

最初の確認応答が狙いだった

提案は小さく見える。新しいTCP接続で、データセグメントを一つより多く送ってから待つ。大きな転送が始まる前にも利点が出る。一つしか飛行中にない場合、遅延ACKを使う受信側はタイマーが切れるまで待つことがある。二つ目のセグメントが届けば、タイマー前にACKを送れる。小さなメールやWebオブジェクトなら、その待ちを省くだけで一往復のうちに転送を終えられる可能性がある。RFC 2414は、より大きな輻輳ウィンドウを使える接続なら、初期スロースタートから最大3往復と遅延ACKタイムアウトを取り除けると説明した。

RFC 2414はすべての接続に4セグメントを求めてはいない。1998年9月のExperimental RFCとして、許容上限を min(4*MSS, max(2*MSS, 4380 bytes)) に引き上げ、TCPは大きな値を MAY とした。MSSによって上限は2、3、4セグメントのいずれにもなる。対象は3ウェイハンドシェイク後の新規接続の初期ウィンドウだ。損失後のウィンドウは1セグメントのままで、長時間のアイドル後の再開は別の任意規則として扱われた。「起動時に大きくする」は境界のある実験であり、通信が止まるたびに輻輳ウィンドウを拡大する許可ではない。

エンドポイントは最初の送信量を選べても、パケットが通るキューを予約できない。RFC 2414はトレードオフの両側を記した。バーストにより送信元の接続が損失やタイムアウトを被る可能性がある一方、共有する混雑リンクでは他の通信も損失や不公平を受け得る。ブラウザーが複数接続を同時に開き、それぞれを大きなウィンドウで始めると問題が強まるとも警告した。1フローの改善が、そのフローだけのものではないキューへの負荷を変えるという話だった。

シミュレーションは一つ以上の結果を数えた

RFC 2415はInformationalのシミュレーション研究であり、導入報告ではない。ns-2のモデルでは、高速リンクの間に1.5 Mbps、50 msのボトルネックを置いた。Webクライアントは8、16、32台、長時間のFTP転送は最大3本とし、初期ウィンドウを1460バイトの1～4セグメントで変えた。Webモデルは埋め込みURLを3つ含む小さなページを使い、ランダムな待ち時間のあとで新たな要求を出した。FTPは1 MBのファイルを転送した。こうした設定で比較は制御できるが、同時に、結果が答えられる範囲も定まる。

モデルの多くのケースで、大きな初期ウィンドウを使うWebクライアントはページの中央値を下げた。改善幅はしばしば約30%だった。著者らは1から2セグメントにした際の急な改善の多くを、モデルに使ったURLサイズの分布に結びつけた。中央値のメインURLと埋め込みURLが2パケットに収まったためだ。分布が変われば曲線も変わり得る。これはモデル内の機構と設定の結果であって、すべてのブラウザーやリンクに当てはまる割合ではない。

グループを分けた結果で問いはさらに明確になる。WebクライアントをIW=1とIW=3に8対8、16対16で分けたケースでは、1セグメント側への悪影響は見られず、大きな窓の側は優位性を保った。32対32の極端な混雑ではIW=3のクライアントが不利になった。著者らは、多数の接続が同時に開き複数の損失が起きたためと解釈した。大きな起動が常に隣のフローを害すると示したのではない。全体の中央値だけでは、モデル化したすべての負荷における各グループの体験を説明できないと示した。

この内容は、すでに公開されているRFC 2416の記事とは異なる。同記事は単一接続と3バッファのキューを扱う。RFC 2415は、ボトルネックを共有する多数のモデル化フローと、その混在比による変化を扱った。どちらのシミュレーションも、インターネット上の実機挙動や普遍的な公平性指標を証明してはいない。後にRFC 3390はRFC 2414を標準化過程の任意上限で置き換え、RFC 5681がそのルールを記録し、RFC 6928が10セグメント起動を実験した。この文書の順序をさかのぼって、1998年のモデルを導入実態調査に変えることはできない。

ヘン・ルーの「Running-Code Primacy」は、実際に試した機構とシステムから証拠をはみ出させないための狭いレンズとして役立つ。「On Reality Layers」は、ページ遅延、キューの損失、ネットワーク全体の結論を一つの観測にまとめないための補助線だ。どちらもTCP史の一次資料ではなく、一次資料はRFC 2414とRFC 2415である。

出典