要約

  • 累積ACKは番号より前の全バイトに対する確定的な約束である。SACKブロックは、受信側が現在保持すると述べる区間であり、後に撤回され得る。
  • 送信側は原本を残し、複数の部分報告から自分のscoreboardを作り、既存の輻輳制約の中で再送を選ぶ。
  • D-SACKは重複を報告できても原因を証明しない。TCPは証拠を増やしたが、回復の権限までは渡さなかった。

届いたと聞いても消せないデータ

受信側が5000を待ちながら[5500,9000)を保持しているとする。SACKは後半の到着を知らせ、送信側は穴に集中できる。

それでも5500以降の送信コピーは消せない。受信側はメモリ事情で報告済みデータを捨てるかもしれず、timeout時には古い情報が無効かもしれない。累積ACKが区間を越えて初めて、保管責任は終わる。

助言は行動を変えられる。約束だけが責任を終えられる。この差がSACKを安全にした。

変えてはいけない古い約束

RFC 793ではACK Xが、X未満の全octetの到着と次の期待位置を示す。この強い境界は、最初の穴より先の飛び地を表現できない。

同じACKが続いても、一つの損失か複数損失か、単なる並べ替えかは分からない。必要だったのは基本の意味を薄めることではなく、別の強さを持つ観測を加えることだった。

RFC 1072は1988年に最初の案を示したが、その形では共通展開に至らなかった。RFC 6247は後にHistoricへ移した。文書化と実装合意は別の歴史である。

全キューを描けない四十byte

RFC 2018は1996年に方式を改訂した。SYNのSACK-Permittedで利用を合意し、各ブロックは32bitの左右端を伝える。通常ACKの意味は変わらない。

TCP optionは四十byteしかない。SACKだけなら最大四ブロック、timestamp併用では通常三ブロックである。最新segmentが変えたブロックを先に置き、最近のブロックを後続ACKでも繰り返す。戻り道でも報告は失われるからだ。

一通のSACKは在庫表ではない。送信側が複数の断片的な視点を統合する。

Renegingが助言の境界を示す

RFC 2018はSACKをadvisoryと呼ぶ。受信側は報告済み区間を破棄できる。送信側は通常回復でその区間を飛ばせるが、累積確認までは原本を保持する。

再送timeout後は古い印を慎重に扱い、左端から保証し直す。基本ACKへの退路があるため、豊かな情報経路が壊れても配送契約は残る。

RFC 6675は保守的scoreboardを送信側に置いた。報告はネットワーク内データ量の推定を更新し、次のsegmentは送信側が選ぶ。

重複は原因を告白しない

RFC 2883のD-SACKは重複到着を報告する。それは並べ替え、ACK損失、複製、早すぎるtimerのいずれも示し得る。RFCは一つの反応を命じず、受信側を無条件に信頼できないとも述べる。

RFC 5681の輻輳義務も残る。穴が正確に見えても送信枠は増えない。資料が証明するのは規則と限界であり、世界共通の導入日、損失場所、報告者の真正性ではない。SACKの成果は、訂正可能な証拠を受領証や命令に変えずに共有したことだった。