要約

  • RFC 3465 の Appropriate Byte Counting は、到着した ACK の個数ではなく、その ACK が初めて確認したバイト数に応じて TCP の輻輳ウィンドウを増やし、遅延 ACK と ACK division の両方による歪みを抑えた。
  • バイトの証拠にも上限があった。slow start の一回の増加は L で制限され、二つの SMSS を超えてはならず、RTO 後は過去の到着分を含む累積 ACK に備えて一つの SMSS に戻す必要があった。

ACK の枚数は進捗の量ではなかった

従来の cwnd 成長は、ACK が届くたびに増加の機会を与えた。受信側が各セグメントを確認し、ACK が失われなければ扱いやすい近似だった。ところが二つのセグメントを一つの遅延 ACK で確認すれば、同じバイト進捗なのに機会は半分になる。逆に、一つのセグメントを小分けにして複数の ACK を返せば、同じ進捗から複数の信用を作れた。

2003 年 2 月に Experimental として公開された RFC 3465 は、数える対象を変えた。テキスト版、RFC Editor 記録、Datatracker、履歴、参照、後続参照、正誤情報が公開記録を構成する。RFC 2581 の成長規則を修正する提案であり、RFC 2581 は後に標準トラックの RFC 5681 に置き換えられた。

RFC 1122 に基づく遅延確認は、おおむね二つのフルサイズセグメントを一つの ACK で覆えた。メッセージ数を数える送信側では、ウィンドウが意図より遅く開く。ACK が途中で失われても、後続の累積 ACK が同じバイト到着を示すのに、増加機会だけが消えた。

ACK division は反対側の弱点を使う。受信側が一つのセグメントの小さな連続範囲を個別に確認すると、固定増分を与える実装は ACK の枚数だけ cwnd を増やす。ABC では、多数の小片が持つ新規バイトの総量は元の一セグメントを超えない。

送信側がバイト台帳を持った

congestion avoidance では、bytes_acked に初めて確認されたバイトだけを加える。合計が現在の cwnd に達すると、その窓量を台帳から引き、一つの送信側最大セグメントサイズ SMSS だけ cwnd を増やす。進捗が何枚の ACK に分かれていても、およそ一往復に一セグメントという目標を保てる。

slow start では、一つの ACK が新たに確認したバイト数まで増やせるが、L を上限とした。L=1*SMSS は従来規則より攻撃的ではなく、RFC はこの保守的 ABC を推奨した。二セグメントごとの ACK を相殺する実験として L=2*SMSS を許したが、それを超える値は禁止した。

上限は大きな累積 ACK や stretch ACK が任意の大きさの送信バーストを解放するのを防いだ。それでも二つの SMSS は一 ACK 後の小規模バーストを増やし、slow start を各 RTT の倍増に近づける。RFC が紹介した限定的シミュレーションでは場合によって損失が増え、文書は追加実験を求めた。普及や一般的な公平性を証明したのではない。RFC 2018 の SACK との併用を勧め、RFC 2861 はアプリケーション制約時の未使用窓という関連問題を扱った。

RTO 後の累積確認は古い進捗も運んだ

手前のセグメントが失われ、後続が既に受信側へ着いている場合を考える。RTO 後に欠落を再送すると、次の累積 ACK は複数セグメントを一度に越える。送信側の確認状態にとってはすべて新しいが、現在の RTT にネットワークを出たデータは再送した一つだけかもしれない。

このため RFC 3465 は、RTO 後の slow-start 回復では L=1*SMSS を必須とした。当時のタイマー規則は RFC 2988、後継は RFC 6298 にある。累積 ACK 自体は正しい。現在の容量を測る証拠としての時間範囲が広すぎるのである。

RFC 3042 の Limited Transmit は三番目の重複 ACK より前に条件付きで新規データを送るが、ABC 台帳は定義しない。RFC 3449 は非対称経路や ACK のフィルタ・再構成を扱うが、送信側信用の単位は変更しない。RFC 2525 の実装問題一覧は正確な動作確認の必要性を示す背景であり、ABC の配備証拠ではない。

Heng Lu の後年の現実層の考え方は、観測した ACK、新規確認バイト、アルゴリズムが認めた信用、実際に放出したパケットを分ける。実行コードを優先する議論は、累積器、上限、回復状態、バーストの確認を促す。これは後世の編集上の視点で、RFC 作者の私的意図を示すものではない。

RFC 3465 は、確認済みバイトを無条件の新規容量とは呼ばなかった。枚数で操作しにくい台帳を作り、その台帳の権限にも上限を置いた。受領証を分割しても、進捗そのものは増えない。

情報源