要約

  • RACK は送信時刻、ACK/SACK、RTT、到着順の入れ替わりを許容する待ち時間から損失を判定する。物理的破棄を直接見てはいない。
  • 後続 DSACK は再送が不要だった可能性を示すが、ネットワーク上の原因までは特定しない。
  • 運用記録は回復判断だけでなく、推定入力と各送信コピーを保存すべきである。

履歴が確定する前に回復する

RACK が答えるのは、後発データの到達証拠と経過時間が、未確認範囲を再送するのに十分かという実務上の問いだ。送信側は完全な確証を無期限に待てない。

RFC 8985 では、より後に送ったセグメントが届き、古いセグメントが推定 RTT と到着順の入れ替わりを待つ時間を超えても届かない場合に損失とみなす。単純なタイマーより根拠は強いが、その時点の送信側による推定である。

ECMP や無線リンクの回復処理などは到着順を変え得る。元のコピーが経路上に残る間に同じシーケンス範囲が損失判定されることもある。判定は回復を指示するもので、破棄の目撃証言ではない。

RACK の時間軸を残す

RACK は、再送分も含め、セグメントごとに直近の送信時刻を記録する。損失判定では、配達確認済みのセグメントのうち送信時刻が最も新しいものを基準にし、直近の RTT と、到着順の入れ替わりを待つ時間を加味する。

この待ち時間は適応的で上限がある。小さい初期値は短いフローを速く回復させる一方、不要な再送を生むリスクがある。到着順の入れ替わりを示す証拠があれば、待ち時間を広げる。

ACK が少ない末尾では TLP が新しいデータ、または最大シーケンスのセグメントを送り、応答を促す。その ACK は RACK の推定材料であって、物理損失の直接観測ではない。

DSACK が事後評価を変える

RFC 2883 の DSACK は、受信側が重複セグメントや重複範囲を報告する仕組みである。再送後の DSACK が確定するのは、重複データが届いたという点だけだ。送信履歴と照合すれば再送が不要だった可能性を示唆できるが、どのコピーがいつ、なぜ届いたかまでは確定しない。

RFC 8985 はこの証拠で到着順の入れ替わりを待つ時間を広げることを勧める。ただし DSACK は、原因となったキュー、無線、トンネル、ECMP 経路を特定しない。

出典