要約

  • 一つのUDPデータグラムには、Initial、Handshake、アプリケーションデータを含む複数の完全なQUICパケットを載せられる。
  • 各パケットの保護、パケット番号空間、処理、ACK、損失は独立している。
  • 観測記録はデータグラム単位で潰さず、パケット単位の証拠をアプリケーションの到達結果と別に結び付ける。

キャプチャには、同じUDPデータグラム内のInitial、Handshake、1-RTTが並んで見えることがある。これはネットワーク上で同じ搬送に含まれていたことを示すだけで、同じ処理結果、損失結果、ACK結果、到達結果になることを意味しない。QUICにとって完全なパケットは処理可能な単位であり、UDPはそれを一つ以上運ぶ外枠である。

パケット・コアレッシングの目的は、ネットワーク上の伝送効率を高めることだ。暗号ハンドシェイクを終え、データ転送を始めるまでに必要なUDPデータグラム数を減らせる。受信側は、コアレッシングされた各パケットの境界を見つけて処理できなければならない。Initial、0-RTT、HandshakeにはLengthフィールドがあり、境界を特定できる。短いヘッダーのパケットにはLengthがないため、必ず最後に置かれる。RetryとVersion Negotiationは別のパケットとコアレッシングせず、異なるconnection IDのパケットもコアレッシングできない。

同じ外枠に入ったからといって、パケットの意味や処理単位が一つになるわけではない。各パケットは、別々のUDPデータグラムで届いたかのように個別処理され、別々にACKされる。一つが復号できなくても、受信側はそれを破棄または保留しながら、残りの処理を試みなければならない。データグラム全体を一つのハンドシェイク成功イベントとして記録する表示は、この区別を失わせる。

Initial、Handshake、アプリケーションデータには別々のパケット番号空間がある。ACKは、それを含む空間のパケットを示す。UDP上で隣り合っていることは、これらの空間を一つの番号列にも、一つのACK領域にも変えない。損失時も同じで、QUICが再送するのは失われたパケットという容器ではなく、そのフレームが運んだ情報である。通常は新しいパケットに入り、元のパケット番号は再利用されない。したがって、同じデータグラムに入っていたという事実から、一つの再送対象や一つの回復結果を導くことはできない。

複数フレームを一つのQUICパケットに入れることと、複数の完全なパケットを一つのUDPデータグラムに入れることは別である。一つのパケットを失うと、その中のデータに関係するストリームが止まる場合がある一方、他のストリームは進める。この影響は同じパケット内のフレーム共有から生じ、UDP外枠の共有からは生じない。

Initialを運ぶデータグラムには1200バイトという特別な条件がある。パディングまたはコアレッシングによって最低長を満たさなければならず、より小さいデータグラム内のInitialはサーバーに破棄される。この搬送条件を、同じデータグラム内の全パケットが同じ処理結果や到達結果になるという一般則にしてはいけない。RFC 9000は、Initialのパディング規則を除けば、パケットをUDPデータグラムへどう分けても接続の機能は変わらないが、性能は変わり得ると説明する。

記録すべきなのは、データグラム識別子と観測地点、送信元と宛先の組、全長、各パケットのオフセットと長さ、connection ID、種別、暗号化レベル、パケット番号空間、利用できる場合の復号済み番号、パケットごとの復号・処理結果、フレーム一覧、ACKとACK範囲の対応関係、損失、再送された情報との対応、ストリームID・オフセット・長さ、Initialの1200バイト適合性、PMTUプローブの役割である。アプリケーションの到達結果は別の記録にする。一つの外枠を観測して分かるのは、ある観測地点で一つの搬送イベントが見えたことだけで、全パケットの復号、処理、ACK、情報の回復、ユーザー空間への到達、メッセージや永続化、業務処理の完了は証明しない。