要約

  • 累積ACKは受信済みバイトの境界が進んだことを示すが、同じシーケンス空間が再送された後では、どの送信インスタンスが到達したかを示さない。
  • Karnのアルゴリズムは再送区間のRTT標本を除外し、指数バックオフは新しい曖昧でない観測が得られるまで保守的なRTOを残す。
  • TCP Timestampは送信インスタンスを限定的に区別できるが、エコーと推定器更新には別の条件があり、ACKをアプリケーション完了の証明にはしない。

二つの出発点を持つ一つの到着

送信側がシーケンス番号5000から5999までのデータを送り、その時刻を記録したとする。ACKが来ないまま再送タイマーが満了し、同じ番号のデータが再び送られる。その直後、次に期待する番号が6000だと示すACKが戻る。

最初のデータが失われず、長く遅延していただけかもしれない。その場合、再送時刻からACKまでを測ると、実際より短いRTTになる。反対に、最初のデータが失われ、再送だけが届いたのかもしれない。その場合、最初の時刻から測ると、タイムアウト待ちを含む長すぎるRTTになる。

時計の精度を上げても解決しない。二つの出発時刻と一つの応答時刻が正確に残っていても、どの組が因果的な往復なのかをACKは指定しないからだ。足りないのは桁数ではなく、送信インスタンスの身元である。

それでもACKは正当な仕事をする。累積受信境界を進め、送信キューから確認済みデータを外し、ウィンドウが許す次の送信につなげられる。配送の進展を判断する証拠として有効であっても、遅延推定を更新する証拠としては不適格になり得る。

適応するタイマーには入口審査が必要だった

RFC 793は、再送タイムアウトを動的に決める考えをすでに持っていた。異なるネットワークを結ぶインターネットでは、経路の遅延は一定でない。観測した往復時間を平滑化し、それに基づいて待ち時間を変える必要があった。

ただし、適応は入力の品質に依存する。送る、ACKを見る、推定値を変える、次のタイマーを設定するという循環に、起点が不明な値を入れれば、適応そのものが不安定さを作る。

誤りは増幅される。最初の送信が遅かったのにACKを再送へ結び付ければ、RTTは短く見える。次のRTOが早く切れ、不要な再送が増える。再送が増えるほど、二つの候補を持つACKも増える。推定器は、自分の早すぎる判断が作った現象から、さらに短い待ち時間を学びかねない。

RFC 1122は、RFC 793で示された計算を不十分とし、JacobsonとKarnの両アルゴリズムを必須にした。JacobsonはRTTの変動を推定に入れる。KarnはどのRTT観測を推定へ入れてよいかを決める。計算式の改善と証拠の採否は別の制御面である。

「分からない」をプロトコル状態として残す

Karnの規則は、再送されたセグメントからRTT標本を取らない、というものだ。同じシーケンス範囲が複数回送られた後、通常の累積ACKでは原因となった送信を選べない。ソフトウェアが都合のよい時刻を選んでも、欠けた由来情報は復元されない。

ACKそのものを捨てるわけではない。接続状態は進み、バイトは確認済みになり、次のデータを送れる。拒否されるのはSRTTとRTTVARを更新する用途だけである。不確実性を接続全体へ広げず、測定の入口に限定する。

この区別は運用上も重要だ。一つの観測には用途ごとに異なる証拠能力がある。ACKはバイト列の前進に強いが、物理パケットの因果帰属には弱い。到達可能性の観測が経路権限を証明しないのと同じく、受信の観測は自動的に時間測定の権利を与えない。

標本を失う代償はある。経路が変化している最中に、新しいRTTを得られない可能性がある。しかし、曖昧な数値を平均へ入れても情報は増えない。空白が見えなくなり、後の制御と監査が誤った確信を受け取るだけである。

バックオフは不確実性を行動へ移した

RFC 1122は、同じセグメントに対する連続RTOへ指数バックオフも要求した。RFC 2988と、それを置き換えたRFC 6298は、SRTT、RTTVAR、RTOの関係、タイマー満了時の再送、RTOの倍増を標準化した。

バックオフは、フィードバックがない経路へ同じ速度で負荷を加え続けないための仕組みである。同時にKarnの規則と組み合わさると、測定できない期間の慎重さを保持する。曖昧なACKを使って、拡大したタイマーをすぐ楽観的な値へ戻すことを許さない。

RFC 6298では、新しい有効なRTT標本が得られれば通常の計算へ戻れる。再送の後では、一般に新しいデータが送られ、再送なしに確認される必要がある。回復の条件は、単なる経過時間ではなく、由来の分かる新しい往復である。

実装は規定より保守的になれるが、規定より攻撃的にはなれない。この非対称性は影響範囲を反映する。長すぎる待ち時間は主に一つの接続へ遅延を課す。短すぎる待ち時間は、応答が滞っている共有経路へ重複データを追加する。

2011年のRFC 6298は、通常の初期RTOを従来の3秒から1秒へ変更し、SYNまたはそのACKが失われた場合の扱いを加えた。保守性は固定値を守り続けることではない。十分な調査で数値は変えられるが、原因不明の標本を使わない原則は残る。

ACKはパケットの履歴書ではない

この曖昧さは、ACKに偶然フィールドが不足したためではない。TCPはバイトストリームの位置に番号を付ける。再送では同じ番号範囲を異なるセグメント境界で覆うこともできる。受信側はACKを遅延させ、複数の到着をまとめ、重複バイトをアプリケーションへ二度渡さず捨てられる。

累積ACKが示すのは次に期待するバイトであり、ネットワークを通った一個のデータグラムの固有IDではない。すべての因果を受信側に記録させれば、共通プロトコルの状態と負担が増える。

TCPは小さな契約を選んだ。受信側はストリーム境界を報告し、自分の再送履歴を知る送信側が測定の適格性を判断する。情報を持つ場所と決定権を揃えたのである。

パケット解析画面では、再送の直後にACKが並ぶことがある。見た目の隣接は因果の証明ではない。遅れていた最初のセグメントが応答を生んだ可能性が残る。正しく交渉された追加情報がなければ、時系列は候補を狭めても一つには決めない。

さらにACKは、相手プロセスがデータを読んだこと、保存が永続化したこと、取引が完了したことも示さない。各層は自分が所有する境界だけを証明する。アプリケーション結果には、その結果を所有する構成要素からの受領証が必要だ。

Timestampは限定された因果タグを加えた

RFC 6298は、TCP Timestampオプションが送信インスタンスの曖昧さを除く場合に例外を認める。RFC 7323は、送信側のTSvalと返送側のTSecrを定義している。

受信されたインスタンスに対応する値がACKでエコーされれば、送信側はその値を特定の送信時計へ結び付けられる。通常のACK番号だけではなかった因果ラベルが、接続内のオプションとして現れる。再送期間を一律に測定不能とする必要がなくなる。

しかし、Timestampがあることと、RTO推定へ使えることは同じではない。RFC 7323は、送信ウィンドウの左端を進める返送だけを平均RTT更新に使う規則を示す。遅延ACK、シーケンスの穴、並べ替え、どのTSvalを保持して返すかが標本の意味を変える。

測定数が増えれば履歴の扱いも変わる。RFC 6298の係数は、おおむね1 RTTにつき一標本という前提を持つ。全パケットの値を同じ重みで入れると、数RTTにわたる経路変化の記憶を早く捨てすぎ、不要な再送を増やす可能性がある。インスタンスを区別できても、サンプリング方針は残る。

Timestampは信頼された世界時でもない。接続内でほぼ時間に比例する値をエコーし、差分を測るためのものだ。相手の身元、時計の同期、アプリケーション処理の成功を保証しない。

現代TCPにも残った「使わない」という要件

RFC 9293は現在の基本TCP仕様であり、RFC 6298によるRTO計算とKarnの標本規則を引き続き必須としている。指数バックオフも、ネットワーク安定性を守る基本動作に含まれる。

この規則は、帯域幅やリンク速度に依存しない。二つの送信インスタンスと一つの累積ACKからは、一意の時間区間を作れないという意味上の限界に依存する。そのため環境が変わっても消えなかった。

新しい損失検出や実装上の工夫は、標本のない時間を短くしたり、追加の兆候を使ったりできる。だが、起点が依然不明な区間を真のRTTへ変換するものではない。

仕様の分業も明確だ。基本TCPは詳細なタイマー計算を専門RFCへ委ねる。タイマーRFCは輻輳制御との関係を説明するが、RTOと輻輳ウィンドウを同じ制御にしない。Timestampは情報を補うが、アプリケーションの結果へ権限を拡張しない。

欠測値を失敗と呼ばない

運用画面は連続した線を好む。製品は常に「現在のRTT」を表示したがる。有効な標本がないとき、直前値の繰り返しや、ACKに最も近い送信時刻を選ぶ補完が誘惑になる。

Karnは別の答えを持つ。この再送区間では通常のRTTを測れない、と明示する。空白は収集失敗ではなく、証拠の品質を表す状態である。適当な数字で埋めれば、後の利用者は二つの因果候補が存在した事実を見られない。

監査可能なテレメトリは、最初の送信時刻、再送番号、満了前後のRTO、ACK前進、Timestamp交渉、採用したTSecr、バックオフ後の最初の有効標本を残すべきだ。平均値だけでは、経路変化と誤帰属を区別できない。

この歴史の要点は三つである。ACKが正当に示す進展は受け入れる。送信別RTTという過剰な意味は拒む。新しい根拠が来るまではバックオフで不確実性を行動へ反映する。強いプロトコルは、少ない信号から何でも推測するものではない。まだ答えられていない問いを状態として保持できる。

出典と証拠の限界

RFC 793は初期の適応型再送を示す。RFC 1122は旧計算の不足を記録し、Karn、Jacobson、指数バックオフを要求する。RFC 2988とRFC 6298はRTOと曖昧標本の排除を定式化する。RFC 7323はTimestampによる区別とエコー規則を示す。RFC 9293は現代TCPに要件を残す。

これらはプロトコル仕様であり、現在の全実装、Timestampの普及率、再送頻度を測る資料ではない。本稿は全タイムアウトを輻輳や攻撃へ帰属せず、RTOを輻輳ウィンドウと同一視せず、トランスポートRTTをアプリケーション成功の証拠にしない。