要約

  • QUIC DATAGRAM フレームを含むパケットは ack-eliciting であり、その ACK により送信実装はアプリケーションへ、データグラムが送信・受信されたことを通知できる。
  • RFC 9221 の 5.2 節は、その通知が受信側トランスポート層によるフレーム処理を示すにとどまり、受信側アプリケーションの成功処理を保証しないと定める。

監視画面では、ACK はつい「届いた」という完了印に見える。しかし QUIC が確認している対象を取り違えると、その印は別の層の責任まで引き受けたように見えてしまう。RFC 9221 の DATAGRAM において、ACK はアプリケーションの結果ではなく、受信トランスポートの処理についての限定された受領記録である。

2022 年 3 月に公表された RFC 9221 は、Tommy Pauly、E. Kinnear、David Schinazi を著者として、不信頼なアプリケーションデータ用に DATAGRAM フレームを QUIC に加えた。DATAGRAM フレームは ACK を誘発する。これを含むパケットが確認されると、送信側の実装は、自身のアプリケーションへデータグラムが送信・受信されたことを知らせ得る。その通知自体は、QUIC が持つ正当な証拠である。

ただし、同 RFC の 5.2 節はその先を禁止する。ACK は受信側のトランスポート層がフレームを処理したことを示すだけで、受信側アプリケーションがデータを正常に処理したことを保証しない。ペイロードの構文解析、意味の検証、状態の変更は、ACK が観測していない別の出来事である。

DATAGRAM は損失検出後に再送されない。多重化の識別子、データの意味、交付または処理の確認が必要かどうかはアプリケーションプロトコルが決める。より強い受領証が必要なら、アプリケーションは自らそれを定義しなければならない。相関対象、成功条件、期限、失敗の表現はいずれもパケット ACK とは別に持つ。RFC 9000 と RFC 9002 が示す QUIC の輸送と損失回復の仕組みも、このアプリケーション上の空白を埋めない。

max_datagram_frame_size の受信値も、同じように小さく読むべきである。ゼロでない値は、その接続のその方向で、ある端点がその大きさまでの DATAGRAM を受け入れる意思を示す。実際にデータが送られたこと、アプリケーションが使ったこと、理解したこと、処理を完了したことのいずれも示さない。RFC と著者名が公開されていることも、特定の端点や製品、ネットワークでの運用を証明しない。

Heng Lu の Minimum Initial Specification という考え方は、この読み方を支える。実行中の機構が局所的かつ決定的に確認できる命題だけを残し、後の判断はその判断を行う層に返す。ACK はトランスポートの帳簿であり、アプリケーションの結果はアプリケーション自身の帳簿である。

この分離は ACK の価値を下げない。反対に、どの事実がどこで検証可能かを明確にする。処理成功を必要とする運用なら、パケット ACK に言葉を足すのではなく、アプリケーションの受領証を観測可能な形で設計する必要がある。

出典