要約

  • RFC 3742は、cwndがmax_ssthreshを超えた後のTCPウィンドウ増加を抑え、1 RTTで数千セグメントが追加される事態を避けようとした。
  • 検証済みのErratum 236はRTTごとの増加範囲を訂正した。83,000パケットに達する例の836 RTTは、正確な所要時間ではなく下限である。

「Limited」は「一定レート」を意味しない。RFC 3742は2004年の実験的な任意提案であり、数千MSSに達し得る輻輳ウィンドウを持つTCP接続を対象にした。cwndがmax_ssthresh以下なら、従来のスロースタートと同じく到着ACKごとに1 MSS増やす。閾値を超えるとK = int(cwnd / (0.5 * max_ssthresh))を計算し、ACKごとにおよそMSSの1/Kを加える。max_ssthreshはssthreshの代わりではない。ssthreshを超えればスロースタートを終える。

RFCの第2節に書かれた数値上限は、アルゴリズムの説明より断定的だった。原文は、max_ssthreshを超えた後の1 RTTあたりの増加は閾値の半分以下とした。一方、Kが段階的に変わるACK単位の規則は幅のある値を示す。RFC Editorが検証したErratum 236は不変条件を修正し、増加はRTTあたりmax_ssthresh MSS以下、かつその半分以上とした。到達時間も単一の式ではなく上下限に改められた。100 MSSの閾値から83,000パケットまでという例で、よく引用される836 RTTは「少なくとも」必要な値になった。

これは説明上の誤りを直したのであって、新しい輻輳制御アルゴリズムを導入したのではない。2004年のRFC本文はそのまま残り、エラッタは別の記録として併読する必要がある。修正によって可能な成長幅と所要時間の読み方は広がったが、上下限のいずれも普遍的に測定された結果ではない。

成長制限は送信元の挙動だけでなく、その外部性にも関わる。スロースタート中の大きな増加は一度に多くの損失を生み、再送タイムアウトを招き、接続のウィンドウを小さく戻しかねない。同じボトルネックを共有する他の通信も、キューと損失の影響を受ける。RFC 3742は100 MSSの例を示し、Linux 2.4.16 Web100カーネルでの初期実験に触れている。これは限定された歴史的報告であり、現在の普及状況やインターネット全体の利益、キュー長の保証を示すものではない。

後のTCP文書は異なる制御シグナルを使う。RFC 9438はCUBICのスロースタートに通常HyStart++を推奨し、Limited Slow-Startは実験的な選択肢として挙げている。RFC 9406はRTTの上昇をスロースタート終了の兆候として使い、その判断が早すぎなかったかを確かめる保守的な段階を加える。RFC 3742のウィンドウ依存のACKごとの増分とは別の仕組みだ。

運用者にとって、このエラッタは「目立つ数字が何を制限しているか」を問い直す材料になる。RTTごとのウィンドウ増加量は、バイトレートの上限でも、キューの実測値でも、共有経路での公平性の証明でもない。閾値、ACKの振る舞い、ペーシング、バッファ、RTT、競合フローが実際の影響を左右する。訂正はRFC自身の不確実性を見えるようにするが、取り除きはしない。

出典