SACK と RACK：選択確認応答と時刻ベース再送

累積 ACK が抱える二つの限界

TCP の確認応答は累積 ACK です。受信側は「次に期待するシーケンス番号」を 1 点だけ返し、そこまでが連続して届いたことを示します。素朴で堅牢ですが、損失回復の観点では二つの限界を持ちます。

ひとつは情報量の不足です。1 つの RTT で複数のセグメントが落ちると、累積 ACK が指せるのは先頭の穴 1 個だけ。送信側は 2 個目以降の穴の位置を知れず、回復が穴の数だけ直列化します。もうひとつは損失判定の仕組みです。古典的な再送は重複 ACK が 3 つ届いたことを損失の合図にしますが（再送制御の内部（RTO・ファストリトランスミット・SACK） 参照）、この「個数ベース」の判定は経路の並べ替え（reordering）に弱く、ウィンドウ末尾の損失では重複 ACK 自体がそもそも返りません。

SACK は前者を、RACK-TLP は後者を解く機構です。順に見ていきます。

SACK：飛び地の受領範囲を伝える

SACK（Selective Acknowledgment、RFC 2018）は、累積点より先で飛び飛びに届いた範囲を TCP オプションで明示通知します。各ブロックは [左端, 右端) 形式で、TCP オプション領域 40 バイトの制約から最大 3 個（タイムスタンプオプション併用時）まで載ります。送信側はこれを scoreboard（各セグメントの送達状態を持つ管理表）に反映し、SACKed と印の付いた範囲を再送対象から外します。

受信状況:  [1000-2000] 欠落 [3000-5000] 欠落 [6000-7000]
            └ 累積ACK     └ SACKブロック1   └ SACKブロック2

ACKオプション:
  ack = 2000                       ← 累積：2000まで連続受領
  SACK: {3000-5000}, {6000-7000}   ← 累積より先の受領済み範囲

この例で再送すべきは 2000-3000 と 5000-6000 の 2 区間だけ。SACK があれば 1 RTT で両方の穴を特定し並行再送でき、累積 ACK のみのときのような直列化が消えます。SACK は SYN で SACK-Permitted を双方が交換したときだけ有効です。

RACK：時刻ベースで損失を判定する

SACK は「どこが届いたか」を正確にしますが、「いつ損失とみなすか」は依然として重複 ACK の個数に依存していました。RACK（Recent ACKnowledgment、RFC 8985）はこの判定を時刻ベースに置き換えます。アイデアは単純です。あるパケットより後に送ったパケットの ACK（SACK 含む）が既に届いているなら、先に送ったそのパケットは十分な時間が経っても届いていない＝失われた可能性が高い、と推論します。

RACK は各パケットの送信時刻を記録し、最新の RTT に小さな余裕 reorder_window を加えた待機時間を設けます。あるパケットについて「より新しいパケットが ACK 済み」かつ「送信からの経過時間が RTT + reorder_window を超えた」場合に損失と判定します。

判定ロジック（概念）:
  最も新しくACK/SACKされたパケットの送信時刻を rack.xmit_ts とする
  各未確認パケット p について:
    if p.xmit_ts < rack.xmit_ts            # pより後のものが先に届いた
       and now - p.xmit_ts > RTT + reorder_window:
       p を損失とマークして再送

ここで個数（重複 ACK の数）はどこにも出てきません。「3 つ」という固定しきい値を捨て、経過時間で測ることが本質です。これにより二つの長年の問題が解けます。

並べ替えへの強さが効くのは、RACK が reorder_window を経路の実測並べ替え量に応じて伸縮させるからです。DSACK で「無駄な再送だった」と分かるたびに窓を広げ、安定すれば狭めます。固定しきい値の硬直性がなく、並べ替えの多い経路では保守的に、少ない経路では機敏に振る舞います。

TLP：テール損失をプローブで埋める

RACK は「後続パケットが既に ACK 済み」を手掛かりにします。ではウィンドウの最後のパケットが落ちたらどうなるでしょう。後続が存在しないため新しい ACK が返らず、RACK も重複 ACK も発火しません。残るは秒オーダーの RTO だけ——これがテール損失（tail loss）で、短いフロー（HTTP リクエスト 1 個など）で体感遅延を最も悪化させる要因です。

TLP（Tail Loss Probe）はこれを埋めます。データを送り終えてしばらく ACK が来ないとき、RTO よりずっと短い PTO（Probe Timeout、おおむね 2 × RTT 程度）でプローブを 1 つ送ります。プローブは末尾の未確認セグメントの再送、または送るべき新しいデータです。プローブへの ACK や SACK が返れば、そこで RACK が損失を判定して正規の回復に入れます。秒オーダーの RTO を待たず、数 RTT で末尾損失から立ち直れるわけです。

DSACK：偽再送を事後検知して取り戻す

時刻ベースや早すぎる RTO は、ときに届いていたデータを再送します（spurious retransmission）。受信側は同じデータを二度受け取ったことを DSACK（Duplicate-SACK、RFC 2883）で通知します。最初の SACK ブロックに累積 ACK 以下、または既受領済みの範囲を載せることで「重複受信」を表します。

送信側はこれを受けて二つの補正をします。ひとつは RACK の reorder_window を広げること。偽再送は並べ替えを損失と誤判定した証拠なので、次回はより慎重に待ちます。もうひとつは輻輳ウィンドウの巻き戻しです。偽再送に反応して cwnd を半減していた場合、損失は実在しなかったのだから縮めた分を取り戻します。これにより、reordering の多い経路でスループットを不当に失わずに済みます。

全体像：検知の精度を時間軸で上げる

SACK から RACK-TLP への流れは、損失回復を**空間（どこが穴か）と時間（いつ損失とみなすか）**の二軸で精密化した歴史です。SACK が穴の位置を点から範囲へと正確にし、RACK が判定基準を個数から時刻へと移し、TLP が末尾の死角を能動的に埋め、DSACK が誤りを事後に正します。

現代の Linux はこの一式を既定で使い、QUIC も同じ思想を採用します。QUIC はパケット番号が再送で必ず増える設計のため、ACK の曖昧性が原理的に無く、RACK 相当の時刻ベース判定をより素直に実装できます（QUIC の内部構造（ストリーム多重化と0-RTT） 参照）。損失検知の精度は輻輳制御の挙動を直接左右するため、CUBIC のようなウィンドウ制御（CUBIC の三次関数ウィンドウ制御）や輻輳制御の系譜（TCP輻輳制御の系譜（Tahoe→Reno→CUBIC→BBR））と合わせて読むと、SACK/RACK が性能のどこに効くかが立体的に見えてきます。