要約

  • 同じシーケンス範囲を二度送った後の累積 ACK は、配送を確認しても、どちらの送信が原因かを示さない。そのため通常の RTT サンプルには使えない。
  • RTO は、新しいデータを送信し、その ACK から曖昧さのない有効な RTT 測定値が得られるまで指数バックオフを続ける。再送されたデータの ACK は通常この条件を満たさないが、TCP タイムスタンプが送信インスタンスを識別できる場合は例外となる。

TCP 送信側がセグメントを送り、再送タイマーを開始したとする。タイムアウトになると同じ範囲を再送する。その後に累積 ACK が届けば、信頼性の状態については明快だ。確認されたバイトは届いている。しかし遅延については、最初のコピー、再送コピー、あるいは両方が ACK の原因だった可能性が残る。

RFC 793 は、シーケンス番号付きデータを再送キューで管理し、タイマー満了時に未確認セグメントを再送する流れを示す。例示的な RTO 手順は、番号付きオクテットの送信から、それを覆う ACK の到着までを測って RTT を平滑化する。ただし同じ範囲が再送された場合、ACK をどの送信に結び付けるかは解決しない。

RFC 1122 の4.2.3.1節は、Karn と Jacobson の両アルゴリズムについて「MUST implement」、指数バックオフについて「MUST include」と明記している。Karn は採用可能な測定を選び、Jacobson は RTT の分散を推定に組み込む。観測の起点が分からないなら、計算を精密にしても問題は消えない。RFC 6298 が後に述べる SHOULD から MUST への格上げは、一般的な RTO アルゴリズムのサポートを指し、RFC 1122 のこの二つの明示的要件を推奨へ弱めるものではない。

RFC 6298 は、再送されたセグメントから RTT サンプルを取ってはならないと明記する。タイムアウト時には最も早い未確認セグメントを再送し、2.5節が認める任意の上限に従いつつ RTO を倍にしてタイマーを再開する。通常の次の測定には、新しいデータの送信と確認が必要だ。TCP タイムスタンプによって ACK を送信インスタンスに対応付け、曖昧性を解消できる場合には、再送からも安全に RTT サンプルを得られる。

Karn は損失検出、高速再送、輻輳制御、SACK、タイムスタンプ仕様、遅延 ACK の規則ではない。ACK が配送状態を進めながら RTT 推定には不適格であり得る、という測定上の境界を定めるものだ。

出典