要約

  • RFC 6928の10セグメントはMSSに応じた任意の上限であり、すべての接続に最大値を使わせる規則ではない。
  • IW10は短い転送の往復回数を減らす一方、経路情報がない段階でキューへ多くを投入する。そのため初回バーストの測定とRFC 3390へのフォールバックが不可欠である。

TCPの3ウェイハンドシェイクは相手の存在を確認する。しかし、その先のアクセス回線の速度、バッファの深さ、競合するフローの数までは教えない。初期輻輳ウィンドウは、この情報不足の中で下す最初の資源配分である。ACKが経路を説明し始める前に、送信者はいくつのデータを送り出してよいのか。

RFC 6928は上限を min(10*MSS, max(2*MSS, 14600)) とした。10は許容される最大値で、実装は小さく始めてもよい。この変更は、3ウェイハンドシェイク中または直後の最初のデータRTTに適用される。SYN/ACKや、そのACKによって初期ウィンドウが増えることはない。

この問いはTCP Fast Openとは異なる。Fast OpenはアプリケーションデータをSYNに載せ、ハンドシェイク完了前へ移す。IW10は通常の接続確立順序を保ったまま、最初のデータ便を増やす。前者が時点を変えるのに対し、後者はフィードバック前に経路へ預ける量を変える。

往復は減っても、経路は既知にならない

RFCの単純化された前提、すなわち帯域無限、損失なし、標準的な遅延ACKでは、初期ウィンドウを3から10へ増やすと、4 KB超の転送で最大4 RTTを省ける。32セグメントの例は5 RTTから2 RTTになる。初回ウィンドウが大きければ重複ACKも得やすく、初期RTOを待たずFast Retransmitで一部の損失を回復できる可能性も高まる。

これは現在の任意のネットワークに対する保証ではない。受信ウィンドウが10セグメント未満なら利点は制限される。引用された試験は主に1,500バイトのEthernet MTUを使った。さらにアプリケーションが同時に複数接続を開けば、接続単位の10セグメントが大きな合成バーストになる。

コストは送信者より先にキューへ届く

低速回線、小さなバッファ、混雑中のルータでは、初回バーストが早期の破棄、再送タイムアウト、slow startからの早すぎる離脱を招きうる。IW10のフローは、RFC 3390の小さな初期値を使うフローより最初に多くの容量を取る可能性がある。アクセス網の長いキューは、DNS、音声、ゲームなど遅延に敏感な通信へ負担を移す。

RFC 6928は、一度だけの増加が単独で持続的輻輳や輻輳崩壊を起こす可能性は低いとする。以後のTCPバックオフは残るからだ。ただし「一度」は接続ごとの話である。ページやサービスが多数の接続を同時に開けば、アプリケーション層では同じ行為が反復される。

初期、再開、損失の三つの窓

新規接続の初期ウィンドウ、アイドル後の再開ウィンドウ、RTO後の損失ウィンドウは別物である。再開値は初期値と現在のcwndの小さい方を超えない。深刻な輻輳に対する損失ウィンドウは1 MSSのまま保たれる。初期または再開ウィンドウで4 KB超を送った後に損失が見つかれば、再開ウィンドウはRFC 3390の挙動へ戻すべきだ。

低帯域経路では、バーストの直列化時間がRTTを支配し、見かけのタイムアウトを生む。そこでRFC 6928はRFC 6298に従い、新しいデータを確認するACKごとに現在のRTOを再始動することを求める。

証拠の範囲

根拠は2013年4月にExperimentalとして公開された RFC 6928 のみである。式、比較、条件付き導入義務はここから確認できるが、現在どの製品がIW10を使うか、特定ネットワークでどう動くか、10を超える値が安全かは立証しない。