要約

  • ACK Delay は、最大の確認対象パケットを受信してから ACK を送るまでの、受信側が意図的に待った時間を示す。
  • latest_rtt は ACK Delay を差し引く前に、送信側のローカル観測から作られる。
  • 解釈には ack_delay_exponent、ハンドシェイクの段階、max_ack_delay、min_rtt の下限が必要だ。

送信から ACK 到着までの時間を測り、ACK Delay を引き、その残りをネットワーク遅延として公開する。これは監視システムではよくある発想だが、証拠の範囲を越えている。ACK Delay は受信側が意図的に設けた待ち時間についての報告であり、伝搬遅延、ネットワーク内のキュー、片方向遅延、あるいは受信ホストで消費された全時間を直接示すものではない。

対象は明確に限定される。受信側は、確認されたパケット番号のうち最大のものを持つパケットを受け取ってから ACK を送るまでの意図的な間隔を報告する。ACK range に含まれるすべてのパケットに同じ待ち時間があった、という意味ではない。QUIC エンドポイントが制御できない時間、たとえば処理前に OS の経路で待った時間も、ACK Delay に一律に含まれるわけではない。鍵が利用できないことによる待ち時間は規則に従って扱われるが、それでもホスト滞在時間全体やアプリケーション処理時間を表すわけではない。

送信側はまず、ACK を要求した最大の新規確認パケットの送信時刻と、ACK を受け取ったローカル時刻との差から latest_rtt を作る。したがって raw sample は、観測された確認間隔全体を含む。ACK Delay は後段で smoothed_rtt と rttvar を計算する際に使われる。符号化された値は ack_delay_exponent と関連するトランスポートパラメータなしには解釈できない。デフォルトの指数は 3、max_ack_delay のデフォルトは 25 ms だが、デフォルト値だけで接続の文脈を決めてはならない。

min_rtt はローカルに観測した値だけから求められ、相手が報告した ACK Delay によって小さくならない。これは誤った報告による過小評価を抑える下限であり、片方向遅延やネットワークだけの遅延の測定値ではない。ハンドシェイク確認後は、復号した ACK Delay と相手の max_ack_delay の小さい方を使い、調整後の値を min_rtt 未満にしてはならない。確認前は max_ack_delay を上限として使わないため、鍵の利用可能性などで大きな値が現れることがある。

max_ack_delay を超える値にも単一の原因はない。確認後のアルゴリズムでは超過分を実質的に経路遅延として扱うが、その観測だけでは、相手のスケジューラ、先行 ACK の損失、受信側の非準拠を区別できない。保護されたパケットで認証されていることは、報告が正しいことの証明ではない。アプリケーション処理、サービス応答、永続化の完了、業務上の成果も示さない。

記録すべきなのは一つの「遅延」ではなく、証拠の台帳だ。接続と経路、パケット番号空間、最大の新規確認パケットと送信時刻、ACK の到着・処理時刻、raw latest_rtt、ACK Delay の生値と復号値、ack_delay_exponent、相手の max_ack_delay、ハンドシェイク確認状態、min_rtt、適用した上限と下限、調整後のサンプル、smoothed_rtt、rttvar、PTO を分けて保存する。ACK range、鍵の状態、ローカル処理、先行 ACK の損失、アプリケーション時間も別の証拠だ。