要約

  • 受信側は最初の通常の順序内セグメントへの ACK を短く保留し、次のセグメントや自らの応答とフィードバックをまとめられる。
  • 待機は二つ目のフルサイズ・セグメント、タイマー満了、または損失を示す事象で終了し、無制限の沈黙にはならない。

受信側の状態から考えると、遅れているものが明確になる。最初のフルサイズ・セグメントのバイトはすでに受理され、次に期待するシーケンス番号も進んでいる。まだ送られていないのは、その事実を相手へ知らせる ACK だけである。二つ目が続けば一つの累積 ACK で両方を確認し、来なければタイマーが確認を放出する。

RFC 1122 は1989年、受信データ一つにつき純粋な ACK 一つを返すより、確認数を減らした方がホストとネットワークの効率を高められるとして、遅延 ACK を SHOULD とした。同時に遅延は0.5秒未満でなければならず、フルサイズ・セグメントの連続では少なくとも二つに一回 ACK を返すべきだと定めた。許されたのは短い集約であって、確認を好きなだけ省くことではない。

待機の利点はヘッダー削減だけではない。文字単位のリモートログインなら、受信アプリケーションが文字を読み、ウィンドウを更新し、文字を返すことがある。短く待てば ACK、ウィンドウ更新、エコーを一つのセグメントに載せられる。近接する状態変化を一緒に伝える時間をつくる設計だった。

RFC 5681 は頻度の境界を明確にした。RFC 1122 内で揺れていた規範語を整理し、二つ目のフルサイズ・セグメントを待つ場合でも500ミリ秒を超えてはならないと繰り返した。また、受信側の RMSS と送信側の実際のセグメント長が一致しない問題もある。経路 MTU のため送信側が小さく区切れば、2×RMSS を待つ方式は二つを超える実セグメントを一つの ACK で覆い、stretch ACK を生み得る。このため RFC 5681 は、実際のセグメント長にかかわらず、少なくとも二つの到着セグメントごとに一度 ACK を返すことを受信側に推奨している。

欠損が見えた場面では待たない。ギャップより先のデータには重複 ACK を直ちに返し、ギャップを全部または一部埋めたデータにも速やかに応答することが推奨される。ここで ACK は受領通知だけでなく、送信側が損失と回復の進行を判断する証拠になる。

RFC 2525 が既知の実装問題として記録した stretch ACK は、境界を外れた集約の帰結を示す。ACK の到着は送信側の制御クロックにも関わるため、過度な間引きはウィンドウの成長を遅らせ、より大きなバーストを招き得る。確認パケット数だけを減らせばよいわけではない。