要約

  • RFC 3522は回復開始時の再送時刻印を保存し、最初の受理可能なACKのecho値と比較する。古い値なら、ACKは元送信への応答であり、回復が不要だったと判断できる。
  • その判断はcwnd、ssthresh、RTO、サービス性能を復元しない。元送信、トリガー、不変のRetransmitTS、曖昧性の出口、保存状態、応答処理、その後の配送を分けて記録する必要がある。

送信側は、証拠が届く前に決断していた。タイムアウトか重複ACKの閾値が再送を起こし、輻輳制御は動作範囲を狭めた。後から来たACKは過去の説明を変えたが、現在の変数を書き戻す命令ではなかった。

RFC 3522は2003年4月のExperimental文書で、Internet Standardではない。TCP Timestampsを使い、再送後のACKが元送信と再送のどちらに対応するかという曖昧性を取り除く。

定義するのは検出だけである。(RESP)は何もしないプレースホルダーだ。診断の所有者と状態変更の所有者を同じにしない設計が、本文に刻まれている。

最初のACKが履歴を識別する

回復を始めるとき、送信側はSpuriousRecoveryをfalseにし、最初のtimeout retransmitまたはfast retransmitのTimestamp ValueをRetransmitTSへ保存する。後続再送で上書きしてはならない。

次に、未確認データを進める最初の受理可能なACKを待つ。そのTimestamp Echo ReplyがRetransmitTSより小さければ、時刻の早い元送信に対するACKである。保守的な確認を通れば、不要な回復と分類する。

最初のACKで分かるため、誤タイムアウト後のgo-back-N連鎖を止められる可能性がある。遅い検出も会計には使えるが、進行中の動作を抑える力は小さい。

それでも証拠は事後である。トリガー、状態縮小、最初の再送、ACK、分類、応答という順序を保存しなければならない。

同じ外形でも原因は一つではない

遅延の急増はACK到着前にRTOを満了させる。パケット並べ替えは重複ACKを作る。データやACKの複製もfast retransmitを誤って起こせる。

古い時刻印は、回復が不要だったことを示しても、原因を一意に示さない。reordering、無線ハンドオーバー、特定ドメインの責任を証明しない。

誤fast retransmitは通常、不要な一コピーと窓半減を生む。誤timeoutはslow startと追加の再送連鎖を生み得る。同じ分類名で影響をまとめるべきではない。

fast timeoutも区別される。本当の損失があり、timerが重複ACKより早かっただけなら回復は正しい。トリガー競争と誤判定は同義ではない。

等値なら判断しない

基準は厳密な「小さい」である。時計が粗い、または経路が速いと、元送信と再送が同じ値になり得る。その場合、RFCは不要回復と宣言しない。

最適化機会を失っても、区別不能な情報で状態を戻さない。証拠不足を肯定へ変換しないための境界である。

生値、粒度、比較演算子、分岐を残す必要がある。「Eifel成功」という表示だけでは肯定・否定・不明を区別できない。

ACK全損は似た時刻印を作る

元データが届いてもACKの一群がすべて失われれば、送信側はtimeoutするしかない。再送バイトは重複でも、timeoutは避けられず、逆方向の混雑に対する窓縮小は妥当かもしれない。

重複データへの応答で、受信側が最後に順序どおり届いた元送信の時刻印を返すと、再送時刻より小さく見える。

ステップ5はDSACKと全未確認データの被覆を調べ、特定条件で分類せず終了する。単純比較ではなく、行動しない出口を含めてアルゴリズムである。

受信側が証拠を偽れる

不正な受信側は古いecho値を返し、本物の再送を不要に見せられる。安全変種は未確認の元送信すべての時刻印を保存し、対応する元値との完全一致を要求する。

強い証明にはメモリが必要で、特定ACKの損失や並べ替えに弱くなる。粗い粒度なら失われた値を推測しやすい。

timestamps有効という一項目では信頼性を示せない。保存した秘密、粒度、相手の知識、証拠欠落時の拒否方針を記録する。

保存していない過去は復元できない

RFC 3522は、輻輳状態の復元、不要な追加再送の回避、DupThreshやRTT推定の適応を応答候補に挙げるが、実行しない。

RFC 4015が後にEifel responseを定める。cwndやssthreshを戻すなら縮小前の値を保存しなければならない。「誤りだった」という分類から上書き済みの数値は生成できない。

一つの不要再送と同じ窓内の本当の損失は共存する。RFC 3708のDSACK分析がこの混合を示す。一つのコピーが余分でも、すべての輻輳対応を戻せるとは限らない。

応答後も結果は未確定である

応答が値を戻し、新しいデータを送り、timerを適応しても、実際の窓、閾値、RTOと後続のACK・損失・並べ替えを観測する。

窓復元は容量安定やアプリ完了を証明しない。TCP roadmap、RACK-TLP、QUIC、CUBICは後年の比較であり、RFC 3522採用の証拠ではない。

約束がバイト配送なら確認範囲、遅延なら測定区間、アプリ取引なら認証済みアプリ受領証で閉じる。時刻印がその意味を継承することはない。

誤信号の前から受領証を作る

timestamp交渉と粒度、元バイト範囲と印、トリガー、dupacksまたはtimer入力、変更前の輻輳変数を記録する。

最初の再送と不変のRetransmitTSを結び、ACK範囲、echo、DSACK、ステップ5の決定、基礎・安全変種を保存する。

応答版、保存・復元・維持した値と理由、その後のネットワーク事象、配送、アプリ結果を関連付ける。集計カウンタだけでは個別rollbackを再構成できない。

証拠の境界

本稿はTCP実装、OS、事業者、ネットワーク、経路、受信側、利用者、フロー、事故、導入を特定せず、採用、timestamp利用、損失、並べ替え、性能、電力、安全性、事業成果を主張しない。

RFC 3522は2003年4月のExperimental文書として扱う。RFC 4015、5681、5682、6298、7323は各自の範囲を保つ。RFC 9438、8985、9002は比較資料だけである。

Heng Luのauthorityとrunning codeの文章は、形式信号、動作状態、観測結果を分ける編集視点であり、IETF意図の資料ではない。

結論は狭い。ACKは診断を変えられるが状態は変えない。別の応答が動き、その効果が観測されて初めて復元と言える。

出典