Zenn
Open9

An Unreliable Datagram Extension to QUIC

QUIC
#
datagram
voluntasvoluntas

QUICのUnreliable Datagram拡張機能

概要

本文書は、QUICトランスポートプロトコルの拡張機能を定義し、QUICコネクション上での信頼性の低いデータグラムの送受信をサポートする。

voluntasvoluntas

1. はじめに

QUICトランスポートプロトコル[I-D.ietf-quic-transport]は、アプリケーションデータの信頼性の高いストリームを送信するためのセキュアな多重化接続を提供する。QUICにおける信頼性はストリームごとに実行されるため、フレームタイプによっては再送の対象とならないものもある。

アプリケーションの中には、特にリアルタイムのデータを送信する必要があるものなど、信頼性の低いデータの送信を好むものがあります。このようなアプリケーションでは、トランスポートとしてUDP[RFC0768]を直接利用したり、DTLS[RFC6347]でセキュリティを追加したりすることができます。QUICを拡張して信頼性の低いアプリケーションデータの送信をサポートすることは、信頼性の高いストリームに使用される暗号および認証コンテキストを共有するという付加的な利点を持つ、安全なデータグラムのための別のオプションを提供します。

本ドキュメントでは、再送を必要とせずにアプリケーションデータを伝送する2つの新しいDATAGRAM QUICフレームタイプを定義しています。

voluntasvoluntas

2. 動機

信頼性のないデータをQUICで伝送することは、既存のソリューションに比べてメリットがある。

  • 信頼性の高いTLSストリームと信頼性の低いDTLSフローの両方を同一相手に公開するアプリケーションは、信頼性の高いQUICストリームと信頼性の低いQUICデータグラムのフローの間で、単一のハンドシェイクと認証コンテキストを共有することで恩恵を受けることができます。これにより、ハンドシェイクに必要なレイテンシーを削減することができます。
  • QUICは、基本的なパケットロス再送タイマーを持つDTLSハンドシェイクよりも、より微妙なロスリカバリーメカニズムを使用しています。これにより、QUICデータの損失回復をより迅速に行うことができます。
  • QUICデータグラムは信頼性が低いものの、確認応答をサポートしており、アプリケーションはデータグラムが正常に受信されたかどうかを認識することができます。
  • QUICデータグラムはQUIC輻輳制御の対象となるため、アプリケーションは独自の輻輳制御を実装する必要がありません。

QUICデータグラムはQUIC輻輳制御の対象となるため、アプリケーションが独自に実装する必要はありません。このような接続遅延の低減や、データグラムの配信状況をアプリケーションが把握することは、オーディオ／ビデオストリーミングアプリケーション、ゲームアプリケーション、その他のリアルタイムネットワークアプリケーションの最適化に有効です。

また、信頼性の低いQUICデータグラムは、仮想プライベートネットワーク（VPN）など、QUIC上のIPパケットトンネルを実現するために利用することもできます。インターネット層のトンネリングプロトコルは一般的に、信頼性のある認証されたハンドシェイクを必要とし、その後、信頼性のない安全なIPパケットの伝送を行います。例えば、制御データにはTLS接続、IPパケットのトンネリングにはDTLSが必要となる。1つのQUIC接続は、信頼性の低いデータグラムを使用して両方の部分をサポートすることができます。

voluntasvoluntas

3. トランスポートパラメータ

  1. トランスポートパラメータ

DATAGRAMフレームタイプの受信サポートは、QUICトランスポートパラメータ（name=max_datagram_frame_size, value=0x0020）によってアドバタイズされます。max_datagram_frame_sizeトランスポート・パラメータは、エンドポイントが受信してもよいDATAGRAMフレーム（フレームタイプ、長さ、ペイロードを含む）の最大サイズをバイト単位で表す整数値（可変長整数で表される）です。このパラメータを含むエンドポイントは、DATAGRAM フレームタイプをサポートし、この接続でそのようなフレームを受信することを望んでいます。エンドポイントは、max_datagram_frame_size トランスポートパラメータを受信するまで、DATAGRAM フレームを送信してはなりません (MUST NOT)。エンドポイントは、エンドポイントがピアから受信した max_datagram_frame_size の値よりも厳密に大きいサイズの DATAGRAM フレームを送信してはなりません (MUST NOT)。max_datagram_frame_sizeトランスポートパラメーターを送信していないときにDATAGRAMフレームを受信したエンドポイントは、エラー PROTOCOL_VIOLATIONで接続を終了しなければなりません（MUST）。max_datagram_frame_sizeトランスポートパラメータで送信した値よりも厳密に大きいDATAGRAMフレームを受信したエンドポイントは、エラーPROTOCOL_VIOLATIONで接続を終了しなければなりません（MUST）。DATAGRAM フレームの使用を希望するエンドポイントは、相手が DATAGRAM フレームを使用できるように十分な max_datagram_frame_size の値を確実に送信する必要があります。max_datagram_frame_sizeトランスポートパラメータに65535という値を送信することが推奨されます。これは、このエンドポイントがQUICパケット内に収まる任意のDATAGRAMフレームを受け入れることを相手に示すためです。

max_datagram_frame_sizeトランスポートパラメータは、DATAGRAMフレームのサポートを示す一方向性の制限値です。DATAGRAMフレームを使用するアプリケーションプロトコルは、単一方向でのみネゴシエートして使用することを選択してもよい（MAY）。

クライアントが 0-RTT を使用する場合、クライアントはサーバーの max_datagram_frame_size トランスポートパラメーターの値を保存してもよいものとします (MAY)。これにより、クライアントは 0-RTT パケットで DATAGRAM フレームを送信することができます。サーバーが 0-RTT データの受け入れを決定した場合、サーバーは、クライアントに NewSessionTicket メッセージを送信した接続でクライアントに送信した値以上の max_datagram_frame_size トランスポートパラメーターを送信しなければなりません (MUST)。クライアントが0-RTT状態でmax_datagram_frame_sizeトランスポートパラメータの値を保存している場合、ハンドシェイクでサーバーから送られてきたmax_datagram_frame_sizeトランスポートパラメータの新しい値が、保存されている値以上であることを検証しなければなりません(MUST)。

データグラムを使用するアプリケーションプロトコルは、max_datagram_frame_sizeトランスポートパラメータが欠落した場合の対応を定義しなければならない(MUST)。データグラムのサポートがアプリケーションに不可欠である場合、 アプリケーションプロトコルは、max_datagram_frame_sizeトランスポートパラ メータが存在しない場合、ハンドシェイクを失敗させることができる。

voluntasvoluntas

4. データグラム・フレームの種類

DATAGRAMフレームは、アプリケーションデータを信頼性のない方法で伝送するために使用されます。データグラム・フレーム・タイプは、0b0011000X（または0x30と0x31の値）の形をしています。データグラム・フレーム・タイプの最下位ビットは、LENビット（0x01）です。このビットは、Lengthフィールドが存在することを示します。このビットが0に設定されている場合、Lengthフィールドは存在せず、Datagram Dataフィールドはパケットの最後まで伸びます。このビットが1に設定されている場合は、Lengthフィールドが存在する。

DATAGRAMフレームの構造は以下の通りです。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        [Length (i)]                         ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Datagram Data (*)                      ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

図1：DATAGRAM フレームフォーマット
DATAGRAMフレームには、以下のフィールドがあります。

長さ。
データグラムの長さをバイト単位で指定する可変長整数です。このフィールドは、LENビットが設定されている場合のみ存在します。LENビットが設定されていない場合、データグラムデータはQUICパケットの最後まで延長されます。空の（つまり長さゼロの）データグラムが許容されることに注意してください。

データグラムデータ。
配信されるデータグラムのバイト数です。

voluntasvoluntas

5. 動作と使用法

アプリケーションがQUIC接続で信頼性のないデータグラムを送信すると、QUICは新しいDATAGRAMフレームを生成し、最初に利用可能なパケットで送信します。このフレームは可能な限り早く送信すべきであり、他のフレームと合体させてもよい（MAY）。

QUICのエンドポイントは、有効なDATAGRAMフレームを受信すると、フレームを処理でき、内容をメモリに保存できる限り、直ちにアプリケーションにデータを配信すべきです（SHOULD）。

DATAGRAM フレームは、0-RTT または 1-RTT の鍵で保護されなければなりません (MUST)。

データグラムを使用するアプリケーションプロトコルは、データグラムデータフィールドのセマンティクスと、その解析方法を定義する責任があります。アプリケーションプロトコルが、1つのQUICコネクション内でデータグラムを使用する複数のエンティティの共存をサポートする場合、それらの間でデマルチプレクスを可能にするメカニズムを使用することができます。例えば、HTTP/3でデータグラムを使用する場合、すべてのデータグラムにフロー識別子を前置する必要があります[I-D.schinazi-quic-h3-datagram]を参照してください。

max_datagram_frame_sizeトランスポート・パラメータはDATAGRAMフレームの最大サイズを制限しますが、その制限はmax_packet_sizeトランスポート・パラメータやエンドポイント間のパスのMTU（Maximum Transmission Unit）によってさらに小さくすることができることに注意してください。DATAGRAM フレームは断片化できないため、 アプリケーション・プロトコルでは、 データグラムの最大サイズが他の要因で制限される場合に対応する必要があります。

5.1. アクノリッジメントの処理

DATAGRAM フレームは損失検出時に再送されませんが、 ack-eliciting ([I-D.ietf-quic-recovery])されます。受信機は、DATAGRAM フレームのみを含むパケットの受信に対する ACK フレームの遅延 (max_ack_delay で指定された範囲内) をサポートすべきです (これらの確認応答のタイミングは損失回復に使用されないため)。

特定の DATAGRAM フレームを含むパケットが失われた可能性があることを送信者が検出した場合、実装は、データグラムが失われたと考えられることをアプリケーションに通知してもよい（MAY）。同様に、DATAGRAM フレームを含むパケットが確認された場合、実装は、データグラムの送受信が成功したことをアプリケーションに通知してもよい（MAY）。並び替えにより、失われたと思われていた DATAGRAM フレームが後の時点で受信され、確認される可能性があることに注意してください。

5.2. フロー制御

DATAGRAM フレームは、明示的なフロー制御信号を提供しません。また、フロー単位またはコネクション全体のデータ制限にも寄与しません。

DATAGRAM フレームにフロー制御を提供しない場合のリスクは、受信者がフレームの処理に必要なリソースを確保できない可能性があることです。例えば、フレームの内容をメモリに保存できない可能性があります。しかし、DATAGRAM フレームは本質的に信頼性が低いため、受信者がフレームを処理できない場合は、受信者がフレームをドロップしてもよい（MAY）。

5.3. 輻輳制御

DATAGRAM フレームは、QUIC 接続の輻輳制御装置を使用します。その結果、コネクションは輻輳コントローラが許可するまで、アプリケーションが生成した DATAGRAM フレームを送信できない可能性があります [I-D.ietf-quic-recovery]。送信側の実装は、コントローラが許可するまでフレームの送信を遅らせるか、フレームを送信せずにドロップする(この時点でアプリケーションに通知してもよい)必要があります(MUST)。パケットペーシングを使用する実装は、フレームの過剰なドロップを避けるために、少なくとも輻輳コントローラが許可するペーシングされたパケットの送信にかかる時間だけ、データグラムフレームの送信を遅延させることをサポートすべきです（SHOULD）。

実装では、オプションとして、アプリケーションが、輻輳制御された DATAGRAM フレームを送信せずにドロップすべき時間を超えて、送信満了時間を指定できるようにすることをサポートします。

voluntasvoluntas

6. セキュリティに関する考察

DATAGRAMフレームは、QUICコネクション内で送信される他のデータと同じセキュリティ特性を持っています。DATAGRAMフレームで送信される全てのアプリケーションデータは、STREAMフレームと同様に、0-RTTまたは1-RTTの鍵で保護されなければなりません（MUST）。

voluntasvoluntas

7. IANAに関する検討事項

本文書では、QUIC Transport Parameter Registryに新しい値を登録する。

Value:
0x0020 (本文書が承認された場合)

パラメータ名。
max_datagram_frame_size

仕様は以下の通り。
接続が、信頼性のないデータグラムフレームのサポートを有効にするべきであることを示す。このトランスポート・パラメータをアドバタイズするエンドポイントは、トランスポート・パラメータで提供されるバイト単位の長さまで、他のエンドポイントからのデータグラム・フレームを受信することができます。

また、このドキュメントでは、QUIC Frame Typeレジストリに新しい値を登録する。

値。
0x30, 0x31 (本ドキュメントが承認された場合)

フレーム名
データグラム

仕様は以下の通りです。
信頼性のないアプリケーションデータ