要約

  • QUIC DATAGRAMは一つのアプリケーション・データグラムを非信頼で運び、メッセージ境界を保つ。
  • max_datagram_frame_sizeは一方向の受信意思とサイズ上限を示すだけで、容量や到達を約束しない。
  • パケットのACKはトランスポート処理の証拠であり、アプリケーション確認や業務完了の証拠ではない。

誤解は、ローカルの送信処理をリモートの受領通知として扱うところから始まる。QUIC DATAGRAMで得られるのは、アプリケーションのデータが一つのデータグラムとして扱われるという性質だ。ストリームのオフセット、バイト単位の順序、損失検出後の再送は追加されず、DATAGRAMメッセージ同士の順序も保証されない。境界は保たれるが、信頼性は追加されない。

QUIC DATAGRAM frameと、QUICパケットを運ぶUDPデータグラムも分けて考える必要がある。frameはQUICパケットの中にあり、そのパケットがUDPデータグラムに入る。外側のUDPデータグラムを見たこと、QUICパケットを組み立てたこと、あるいはそのパケットがACKされたことは、アプリケーションのメッセージが相手のアプリケーションに渡ったことを意味しない。

max_datagram_frame_sizeは方向ごとに働く。既定値はゼロで、非ゼロの値は、条件を満たすDATAGRAM frameをその方向で受信する意思を示す。ハンドシェイクや、適用される保存済み0-RTT状態の条件に従う必要があり、送信側は相手の値を超えてはならない。ただし、これは空きメモリ、アプリケーションの処理能力、将来の到達を示すものではない。実際の上限はmax_udp_payload_sizeや経路MTUによってさらに小さくなり得る。この拡張はDATAGRAM frameを分割しないため、アプリケーションプロトコルが小さい有効最大値を扱う必要がある。

DATAGRAM frameにはQUIC stream IDがない。論理的なフロー識別子、データの意味、期限、重複排除、必要な順序、完了条件はアプリケーションプロトコルの責任である。トランスポートだけでは、二つのデータグラムが同じ業務操作の試行なのか、別のメッセージなのかを判断できない。

アプリケーションがデータグラムを渡すと、QUICは新しいframeを生成し、輻輳制御とペーシングの制約のもとで最初に利用できるパケットへ送ろうとする。送信がまだ許可されていなければ、実装は許可されるまで保持するか、送信前に破棄しなければならない。アプリケーションの期限も送信前破棄を選ばせる。したがってAPIの成功は、そのAPIが実際に約束する範囲で記録すべきであり、RFC 9221がそれを送信・相手の受領・アプリ完了の通知に変えるわけではない。

受信側は、frameを処理でき、内容をメモリーに保持できる場合にだけ、アプリケーションへ直ちに渡すべきである。DATAGRAMには明示的なフロー制御がなく、通常のストリームや接続のデータ制限にも数えられない。フロー制御で止められなかったことは、受信能力の証拠ではない。処理できないframeは破棄され得る。

DATAGRAM frameはACKを要求する。損失検出後に再送されないことと、ACKされないことは同じではない。ACKは通常の範囲で遅れることがあり、探査パケットで早い応答を促すこともできる。パケットの並べ替えによって、以前の暫定的な損失判断が覆ることもある。ACKが示すのは受信側トランスポートによる処理であり、アプリケーション処理、永続化、業務完了ではない。