要約

  • TCPの累積確認は、欠けたデータにぶつかると止まる。SACKは、その先に届いている連続したバイト範囲を受信側から知らせた。
  • RFC 2018は受信側による報告済みデータの破棄を認めた。送信側は累積確認が進むまで自分のコピーを保持しなければならない。

帳簿の一枚目、二枚目、四枚目が届く。受付の印は二枚目までしか進められない。三枚目がないからだ。四枚目は机にあると余白に書ける。だが机がいっぱいになれば、その紙を片付けるかもしれない。この「正式な印」と「机上のメモ」の違いを、TCPは通信の回復手順に持ち込んだ。

1988年のRFC 1072は、遅延と帯域幅の積が大きい経路で累積確認だけに頼る不便さを説明した。一つ欠けると確認番号は止まり、先に届いた後続セグメントが送信側から見えにくくなる。次の往復を待てば修復が遅れる。闇雲に送り直せば、受信側が既に持つデータまで運ぶ。選択的な報告は、穴の向こうにあるデータを伝える案だった。これは試験的な提案であり、後に定められたSACKの形式そのものではない。

1996年10月のRFC 2018は、その報告をTCPオプションにした。相手が接続開始時のSYNでSACK-Permittedを通知していなければ、受信側はSACKを送れない。通常の確認番号はTCPヘッダーに残り、切れ目なく届いた位置を示す。SACKブロックは、その先で受け取ったバイト範囲の両端を示す。受付印が二枚目で止まっても、四枚目の所在は伝えられる。

メモ欄は狭い。TCPオプションの領域には、ばらばらに届いた全区間をいつも列挙できるだけの空きがない。RFC 2018は、確認を引き起こした最新セグメントを含むブロックを先頭に置くよう求めた。ただし、そのセグメントが累積確認を進めた場合は別だ。残りには異なるブロックをできるだけ載せ、最近の報告を繰り返すことも勧めた。一通のACKが失われても、次のメモが同じ情報を届けるかもしれない。送信側の見取り図は有用だが、常に全量ではない。

RFC 2018の第8節には、さらに厳しい現実がある。受信側は、SACKで受け取りを知らせた順序外データを後で捨ててよい。バッファーの圧迫などが理由になる。これをrenegingという。古いデータを捨てた後のSACKで、手元に残っているふりを続けてはいけない。一方、先頭ブロックには最新セグメントを示す特例があり、受信側がそのセグメントを捨てるつもりでも到着は報告される。SACKは到着と一時的な置き場所を伝える。永久保管の約束ではない。

そこで送信側には単純で重い規則が課された。累積確認がカバーするまでは、バイトを手元から消してはならない。SACKを見て、どこを先に再送するか決められる。届いていそうな区間を当面避けることもできる。しかし、最後の再送可能な原稿を破り捨てるのは早い。受信側が机を片付けてしまえば、送信側の保管分が修復の出発点になる。

2000年7月のRFC 2883は、同じオプションを重複到着の報告にも使った。D-SACKである。累積確認番号の意味やACKを送る時機は変わらない。重複は一通のACKにだけ載る場合があり、そのACKが消えれば報告も消える。詳しいメモにも、配達事故は起きる。

SACKは切れた列を修復する際の無駄な推測を減らした。同時に、通信の役割分担をはっきりさせた。受信側の鉛筆書きを再送の判断に使う。送信側の原本を捨てるのは、累積確認の印が追いついてからだ。