追記 2021/07/18
HTTP/3でDATAGRAMフレームを使う場合に多重化出来るようにする提案仕様が別途出ています
asnokaze.hatenablog.com
QUICはUDP上で暗号化された信頼性のあるデータ通信を提供するトランスポートプロトコルです。
現在IETFの「QUIC WG」で標準化が進んでおり、先行して実装されていたGoogle版QUICもIETF版QUICへの移行が進められています。
QUICのアプリケーションレイヤ
現在QUIC上のアプリケーションプロトコルとしては「HTTP over QUIC」にフォーカスして標準化が進められています。
一方で、WebRTC over QUIC (Quartc)、QUIC as a VPN (QBone)、DNS over QUICといったその他のアプリケーションプロトコルでもQUICを使用する考えを持ってる人もいます。
そこでそういったプロトコルのトランスポートとして使用できるように、QUIC上でロスしたパケットに含まれるデータを再送しないデータ通信を可能にする拡張仕様が提案されています。もちろん通信は暗号化されていますし、Ackにより相手が受信したかどうかは確認することが出います。
MESSAGEフレーム/Datagramフレーム
提案自体は同時期に個別に2つの仕様が出ています。
1つ目の「QUIC Messages」はGoogleのIan Swett氏提案しているMESSAGEフレームを定義し利用するもので、Google QUIC v45ですでに実装されています。
2つ目の「An Unreliable Datagram Extension to QUIC」はApple人らによって提案されているDATAGRAMフレームを定義利用するものです。著者はIETF102において、Ian Swett氏との議論に基づいてDraftを書いたと述べています。
これらはフレーム名を除いて同じもののようです。実際に、Ian Swett氏は共同で作業していく意思を示しています。
DATAGRAMフレーム
DATAGRAMフレームのフレームタイプは、0x1c又は0x1dであり最下位ビットが1の場合はLengthフィールドを持ちます。0の場合はパケットの最後まででデータであることを意味します。
DATAGRAMフレームのフォーマットは次のとおりです
STREAMフレームの場合はストリームIDによって一つのコネクション上に多重化されますが、DATAGRAMフレームの場合は多重化するのならQUICを利用するアプリケーションの責任によって実施されます。
DATAGRAMフレームのみのパケットにはAckする必要がありますが、ロス回復には使用されないためAckを遅延させてバッチ的に応答すべきです(SHOULD)。DATAGRAMフレームはコネクションレベルのフロー制御を受けます。また、輻輳制御やフロー制御によりブロックされた場合はそのままドロップすることもできます(MAY)
