要約

  • PTO満了はACKを促すプローブを1つまたは2つ送信し、バックオフを増やす。
  • それだけでパケット損失、輻輳、ACKの紛失を宣言することはできない。
  • タイマー、packet number space、プローブ、後続ACK、損失宣言、アプリケーションの結果は分けて扱う。

運用上の誤判定は、タイマーの満了をそのまま損失イベントに置き換えるところから始まる。PTOの満了は、まず特定のpacket number spaceに属するタイマーイベントである。ACKを誘発するパケットが計算された期間内に期待された進展を生まなかった場合、またはクライアントのアドレス検証前にサーバーがプローブ送信を必要とする場合に、送信側は進展を求める。少なくとも1つ、最大2つのフルサイズのACK誘発プローブデータグラムを送り、その後のPTOバックオフを増やす。しかし、この満了時点では、どのパケットが失われたかは決まっていない。

PTOはpacket number spaceごとに管理される。Initial、Handshake、Application Dataを一つの待ち行列として扱ってはならない。通常の計算はsmoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delayである。InitialとHandshakeではmax_ack_delay項をゼロにする。ハンドシェイク確認前にApplication Data PTOを作動させない。ACKを促すパケットの送信または確認、そしてInitialやHandshakeの鍵の破棄は、PTOを再始動させる契機になる。満了後の次の期間は2倍になり、packet number spaceにまたがる連続期間は指数的に伸び、最終的には別のidle timeoutに制限される。

損失検出には別の証拠が必要である。time-threshold loss-detection timerが優先され、そのタイマーが設定されている間はPTOを作動させない。後から届くACK範囲は、RFC 9002に基づくpacket thresholdまたはtime thresholdの損失宣言につながり得るが、それはPTO満了とは異なるイベントである。ACKがないパケットを満了直後にすべて損失扱いにする監視処理は、後続の証拠を先取りしている。

プローブを「再送」と呼ぶのも正確ではない。新しいデータがあればそれを使い、なければ以前に送った情報を新しいフレームと新しいパケットで再び運ぶ。データがなければPINGなどのACK誘発フレームを使える。RFC 9000は、失われたQUICパケットを全体として再送するのではなく、修復が必要な情報を新しいフレームとパケットで運ぶと説明する。古い情報を新しいパケットに載せることは同じパケットの再生ではない。PINGとPADDINGには再送可能な情報がない。

アドレス検証前は、サーバーのプローブもanti-amplification limitに算入される。予算内で追加送信できなければ、別のクライアントデータグラムが予算を増やすまで、サーバーはPTOを作動させてはならない。クライアントがサーバーの送信制限を解除するためにプローブを必要とすることはあるが、これは損失の証明ではない。PTO満了だけでは、輻輳、受信側のアプリケーションデータ処理、サービス応答、業務完了のいずれも証明しない。