要約

  • RACKが古い送信を損失とみなすには、後から送ったセグメントの到着が確認され、なおかつ古い送信が推定RTTと上限付き並べ替え窓を超えて未確認であるという二つの条件が要る。
  • TLPはRTOの前に最大一つのプローブを送り、ACKを引き出す。プローブは損失の証明ではなく質問であり、RACKの判定後も回復送信の権限は輻輳制御にある。

三つ数えられない場所

従来の高速再送は、同じ累積確認を示す重複ACKが三つ来れば、それより前に穴があると推定する。後続パケットが十分に流れる場面では実用的だ。しかし短い応答、アプリケーション制限中のフロー、送信窓の最後で起きた損失では、受信側に追加のACKを生む材料がない。細かな証拠が尽きた送信側は、慎重に設計された再送タイムアウトまで待つことになる。

SACKは観測できる範囲を広げた。RFC 2018により、受信側は累積ACKより先で届いたバイト範囲を報告できる。RFC 6675はそのスコアボードで損失回復を進めるが、主要な基準は穴より上にある不連続なSACKシーケンスやバイト数を数えるものだ。並べ替え、ACKの集約、複製はその数を早くも遅くもする。シーケンス空間の個数は、問題の送信が経路上でどれだけ待ったかを表さない。

Recent ACKnowledgment、すなわちRACKは判断軸を送信時刻へ移す。RFC 8985はYuchung Cheng、Neal Cardwell、Nandita Dukkipati、Priyaranjan Jhaの共同著作で、2021年2月にIETF Standards Track文書として公開された。IETFとGoogle Researchの公式プロフィールはCardwellの本人性、ネットワーク研究、文書との関係を裏付ける。一方で、集団で作られた標準を単独発明としたり、現在のあらゆる実装を本人が支配しているとしたりする根拠にはならない。

後発の到着で時計が意味を持つ

RACKは未確認セグメントごとに最新の送信時刻を保持する。再送したなら、その新しい時刻が対象になる。まだ確認されていないセグメントSより後に送ったデータがACKまたはSACKで到着済みと分かったとき、初めて比較の基準が生まれる。経路はSの後発者を一つ運び終えたのである。

それでもSを直ちに損失とはしない。後発データの配達という事実に加え、Sが推定RTTと並べ替え窓の合計以上に未確認でなければならない。RFCはセグメントごとの仮想タイマーで説明するが、実装が物理タイマーを大量に持つ必要はない。未処理集合から最初に満了する時刻を一つ追跡すればよい。

時刻の粒度も仕様の一部である。RFC 8985は、各未確認セグメントの最新送信時刻を最小RTTの4分の1より細かい精度で保持するよう求める。状態量について4または8オクテットという見積もりも示すが、これは時刻表現に依存する設計上の概算で、すべての実装に同じ請求書を出す数字ではない。

ACKが証明するのは、特定のTCPバイト範囲が受信側へ届いたことだけだ。経路全体の健全性、遅延の原因、輻輳地点、ミドルボックスの動作、アプリケーションによる処理完了までは証明しない。RACKは原因を特定せず、送信側から見える順序と時間が回復処理に足るかを決める。

並べ替えには有限の猶予を与える

経路はパケットを失わずに順序だけを変え得る。そこでRACKはRTTに並べ替え窓を加える。RFCが示す状態に応じ、この窓はゼロまたは最小RTTの小さな割合から始まる。Duplicate SACKが、行った再送は不要だったと示せば、送信側は想定より深い並べ替えの証拠を得る。DSACKに基づく適応が推奨され、窓は平滑化RTTを上限とすべきだとされる。

狭い窓は本当の損失を早く修復する代わりに、遅れているだけの原本を重ねて送る危険を増す。広い窓は余分な通信を抑えるが、実際の穴を長く放置する。「時間ベース」は確実性の別名ではない。不確実性にどれだけ待つかを、明示的かつ有限な予算へ変えたものだ。

監査できる損失記録には、疑わしいセグメントの最新送信時刻、到着した後発セグメントの送信時刻、根拠となったACKまたはSACK、RTT推定、当時の並べ替え窓、窓を変えたDSACKが必要になる。RACK lossという合計値だけでは、証拠が改善したのか、判定が短気になったのか分からない。

TLPは末尾へ一度だけ問いを送る

Tail Loss Probeは、ACKを生む後続データが乏しい末尾を扱う。プローブタイムアウトは一般に平滑化RTTの約2倍を軸に計算されるが、遅延ACKとRTOとの関係に関する仕様の条件を受ける。新しいRTT測定が必要で、未応答のTLPプローブは一つを超えてはならない。

満了時、新規データがあり輻輳窓が許せば、それを送る。なければ、未確認のうち最も大きいシーケンス番号のセグメントを再送する。どちらもACKを促し、前方の状態を見えるようにするためだ。満杯の輻輳窓を一時的に一パケットだけ超えることは許されるが、その送信は在飛行量に数えられ、次のACKで帳尻を合わせる。

プローブを送った事実は、元の末尾が失われた証明ではない。返るACKは、RACKが必要とする後発配達を示すかもしれないし、元データは届いていてACKの動きだけが止まっていたと示すかもしれない。プローブまで失われればRTOが最後の安全網として残る。TLPは観測を作り、RACKがその意味を判定する。

検出器に送信許可証はない

RACKが損失と判定しても、即座に再送できるわけではない。RFC 8985は、輻輳制御アルゴリズムが許可するまで待つよう明記する。RFC 5681が古典的な輻輳制御の責務を示し、RFC 6937のProportional Rate Reductionが回復中の送出調整に推奨される。

この分離によって、優れたセンサーが攻撃的なアクチュエーターへ化けるのを防ぐ。RACKは回復対象を示し、輻輳制御はネットワークへ何バイト出せるかを決める。満杯の窓を越える一回のTLPも、狭く規定され、会計から消えない例外である。

RFC 6298のRTOも存続する。細かな手段から証拠が得られないときに進行を保証し、慎重なバックオフを担う。SACKは到着範囲を記述し、RACKは時間順で損失を評価し、TLPは末尾で応答を求め、輻輳制御は回復の速度を制限し、RTOは最後の沈黙を引き受ける。

精密な時刻にも分からないことがある

後発パケットの到着は、経路が健全だという証明ではない。エンドポイントを認証せず、輻輳場所を特定せず、無線損失と合法な並べ替えを因果的に区別もしない。正しい損失判断であっても、送信側信号から導くトランスポート上の結論にとどまる。

RFC 8985のセキュリティ考察はSACKの既知の懸念を引き継ぐ。また狭い利点として、1バイトずつ確認を進めるACK splittingでは、RACKが参照する「最近配達された送信時刻」が進まないため効果が小さいと説明する。特定手口への耐性であって、ACK全般の真正性保証ではない。

RFC 9002はQUICの損失検出に時間しきい値を用い、RACK-TLPを系譜の一つとして挙げる。ただしQUICには固有のパケット番号空間とACK規則、輻輳制御との境界がある。発想の近さから、状態や定数や権限まで同じだとは言えない。

2013年の数字を現在形にしない

Cardwellも著者に含まれる2013年の論文「Reducing Web Latency: the Virtue of Gentle Aggression」は、Googleフロントエンド通信の一標本を調べた。その限定環境では、観測された損失の77％が高速回復ではなくRTOで修復されていた。試験した仕組みの組み合わせは、平均遅延を23％、99パーセンタイル遅延を47％削減したと報告する。

この数字は、設計者が短い通信の末尾を重視した歴史的理由を示す。現在の導入率、今日のGoogleの運用、RFC 8985一般の性能保証は示さない。残る洞察は限定的だが重要である。短いフローでは、待ち時間より先に、証拠を生む後続パケットが尽きる。

出典