要約

  • 重複通知は特定の再送が不要だったことを示せるが、同じウィンドウの全セグメントが損失なく届いたとは示さない。
  • RFC 3708が輻輳状態を戻す結論を許すのは、前ウィンドウの再送単位がすべて確認済みで重複と標識され、停止条件にも該当しない場合だけだ。

誤読を誘うのは、ほとんど罠のような例だ。送信側はNとN+1を再送した。失われたのはNだけで、N+1は遅れていただけだった。受信側がN+1を重複として知らせれば、その再送が不要だったことは分かる。しかしネットワークで損失がなかったとは分からない。Nは依然として実際の損失を示す。ウィンドウ全体の輻輳状態を元に戻せば、まだ有効な証拠まで消してしまう。

この区別が2004年2月にExperimentalとして公開されたRFC 3708の核心だ。TCPの重複選択確認（DSACK）とSCTPの重複Transmission Sequence Number（TSN）通知をどう慎重に使うかを示す。用途は二つに分かれる。プロトコルスタックは集計や監視のために通知数を数えられる。一方、輻輳制御の変更を取り消すなら、より厳しい識別アルゴリズムが必要だ。

まず、通知されたシーケンス範囲またはTSNを送信側が再送したか確認する。同じウィンドウで二度を超えて再送されていたら処理を止め、以前の輻輳状態には戻さない。送信側が一度も再送していないデータなら、ネットワークがパケットを複製した可能性がある。その場合、RFC 3708は接続の残り期間、このアルゴリズムを使わないよう求める。その後の重複通知は、送信側の不要な再送によるものか見分けにくくなるからだ。

通知が再送と一致しても、それだけでは足りない。送信側は一つ前のデータウィンドウ内にある全再送単位を調べる。すべてが確認済みかつ重複として標識されて初めて、その再送はすべて不要であり、ウィンドウ内に損失はなかったと結論する。未標識の再送が一つでも残れば、その通知からは結論を出せない。SACK記録が空で、DSACKの左端がSND.UNAと等しい場合にも停止する。これはウィンドウ全体のACK喪失と整合し、その場合は送信レートを下げ続けるのが保守的だからだ。

この判断には状態保持も要る。通常のSACK回復情報に加え、どのシーケンス番号またはTSNが重複として確認されたかを追跡する。得られるのは範囲を絞った推論であり、受信側の誠実さや経路上の全事象を保証するものではない。RFC 3708のセキュリティ節は、実損失がある中で受信側が順序外データを重複だと誤って示し、送信側に危険な輻輳状態の変更をさせる可能性を警告する。

RFC 2883はTCPのD-SACKブロックで重複データをどう符号化するかを定めるが、送信側の反応は規定しない。RFC 3522のEifelは別の証拠経路を使い、全パケットにTimestampオプションを載せる代わりに、不要な再送をより早く検出できる。RFC 3708の方法は遅いが、二つの問いを分ける。個別の再送が不要だったか、そしてウィンドウ全体を無損失と判断できるか。検出後の対応は規定外だ。

出典：RFC 3708、RFC 3708の状態、RFC 2883、RFC 3517、RFC 3522、RFC 2960、RFC 4960。