Multipath-TCPのように、複数の経路を使用したQUIC通信を可能にする『Multipath Extension for QUIC』という提案仕様が出されています。これにより、例えばWi-Fiとキャリア回線を両方使った通信も行えるようになります。
QUICのマルチパス機能は、長らく議論されており、複数の提案仕様が出されていました。それらについては、去年書いた記事を御覧ください。
asnokaze.hatenablog.com
今回提出された、『Multipath Extension for QUIC』は、いままで出てきた提案仕様に共通するコア機能にフォーカスした仕様となっています。
なお、この提案はIETF 112でも議論になり、この仕様を元に議論を進めていくコンセンサスが得られそうです。
設計
『Multipath Extension for QUIC』の基本的な設計は次のとおりです。
- RFC 9000 QUICv1の仕組みを可能な限り再利用する。特に、コネクションマイグレーションのパス検証(path validation)の仕組みを利用する
- パケットはQUICv1と同じパケットヘッダー形式を使用する
- 輻輳制御、RTT測定、PMTU検出はパスごとに行う。(各パスの利用スケジューラについてドキュメントでは定義しない)
- パスは送信元/送信先IP・送信元/送信先ポートの4タプルごとに一つとなる。なお、パスごとにコネクションIDは異なるものが使用される(QUICv1の通り)
複数パスの利用は、コネクションマイグレーションと同じ手順を踏みます。このときにコネクションをマイグレーションするのではなく、同時に利用できるようになるのが大きな違いです。
その他に大きな違いは、次のとおりです。
- パスを破棄する PATH_ABANDONフレームの定義
- シングルパケット番号空間/マルチパケット番号空間の定義
- マルチパケット番号空間利用時の、ACK_MPフレームの利用
順番に見ていきましょう。
(この提案仕様では、複数パス上でやりとりするパケットを管理するのに、シングルパケット番号空間/マルチパケット番号空間と2種類の方法を定義しています。どちらか一つになることを想定していますが、実際に試しながら議論を進めていくようです)
パケット番号空間
先述の通り、シングルパケット番号空間/マルチパケット番号と二種類の管理方法があります。
シングルパケット番号空間
複数のパスで単一のパケット番号空間を利用します。このとき、QUICv1と同じACKフレームを利用します(どのパスで受け取ったパケットに対して、どのパスでもACKを返せます)
マルチパケット番号空間
複数のパスごとに独立したパケット番号空間を持ちます。パスをしてしてACKを返すことが出来る、ACK_MPフレームを用います（ACK_MPを送るパスと、ACK_MPの対象となるパスは異なって良い）
通常のACKフレームとは異なり、パケット番号空間を示すPacket Number Space Identifierがある。Packet Number Space IdentifierはコネクションIDはによって指定される。
パケット暗号時の、ナンスがユニークになるように暗号処理にQUICv1から処理が少し変更される。
ネゴシエーション
クライアントとサーバはお互いにマルチパス拡張をサポートしているかまず確認します。そのために、QUICのハンドシェイク時にトランスポートパラメータとしてenable_multipathを送信します。
enable_multipathの値は
- 0: サポートしていない
- 1: シングルパケット番号空間のみサポート
- 2: マルチパケット番号空間のみサポート
- 3: シングルパケット番号空間/マルチパケット番号空間 両方をサポート
クライアントが両方サポートしている場合は、サーバ側がどちらを使うか選択します。
また、active_connection_id_limitパラメータを使うことで、同時に使用するパスの数も制限することが出来ます。
新しいパスの利用開始
新しいパスを利用するクライアントは、PATH_CHALLENGEおよびPATH_RESPONSEを利用しパス検証を行います。
検証が成功すると、非プローブの1-RTTパケットを送信できるようになります。
パスの利用終了
パスの利用を終了するのには、PATH_ABANDONフレームを送信する (終了するパスとはことなるパスで送信しても良い)
Path Identifierで終了するパスを指定する。指定は、コネクションIDで指定するか、送信しているパスが対象であることを伝える事ができる。
