2021/10/26 追記
最新仕様は https://datatracker.ietf.org/doc/html/draft-lmbdhk-quic-multipath-00 こちら
asnokaze.hatenablog.com
QUICのMultipath(マルチパス)拡張に関して、2020年10月にQUIC WG中間会議で議論が行われているので、現状について簡単にまとめる。
はじめに
QUICおよびHTTP/3のドラフト仕様がLast Call (URL)になり、標準化としては大詰めを迎えている。
それにともない、IETF QUIC WGのメーリングリストではQUICのMultipath拡張について、どう取り組んでいくかの議論が盛り上がっている。
Multipath拡張とは、例えばスマホのWi-FiとLTEのように複数のネットワーク(path)を同時に使ってコネクションを張る方式のことです。Multipathを利用する通信としては、TCPのMultipath拡張であるMultipath-TCPがすでにRFC(RFC 8684)となっており、iOSやLinus Kernelでサポートされている。
このMultipathをQUICでも行いたいという話である。
IETFでQUIC WGを設立した際にcharter(URL)として、作業領域および目的を定めたたが、その中にもMultipath拡張を検討する旨記述されている。今標準化を行っている QUIC v1ではこのMultipath機能は取り込まれず拡張仕様として別途議論することと成ったが、そのv1の標準化の終りが見えてきた今、改てMultipath拡張の標準化をどう進めていくかの議論が始まったのである。
まだ、どうなっていくか分からないところだが、中間会議での議論を踏まえて一旦状況を纏めておきたいと思う。
提案仕様
現在、Multipath拡張を実現する提案仕様は、別々に3つ出されている (そのうち2つが同じ仕様名なので注意)。まず最初に簡単に紹介したい。
- 「Multipath Extensions for QUIC (MP-QUIC)」
- 「QUIC Multipath Negotiation Option」
- 「Multipath Extension for QUIC」
Quentin De ConinckらによるMP-QUIC
1つ目の「Multipath Extensions for QUIC (MP-QUIC)」はルーヴァン・カトリック大学、Quentin De Coninckらによる提案である。
2017年頃から提案している、Multipath拡張仕様のうち一番古くからとりくまれている仕様。初期に、MPTCP v0のデザインの影響を受けている。Connection ID毎に単方向のUniflowsを持つ、
すでにGoを用いた実装が行われており、論文なども出されている。
QUIC Multipath Negotiation Option
2つ目の「QUIC Multipath Negotiation Option」はPrivate Octopus IncのChristian Huitema氏による提案である。現在のMultipath 拡張の盛り上がりをうけて、今月提出された仕様である。
これは、その他のMultipath拡張とは異なりPathごとの通信識別子を持たず、QUIC v1がすでに持っているコネクションマイグレーションを利用します。マイグレーションとは異なり、複数のPathをactiveなままに維持します。
AlibabaのMultipath Extension for QUIC
3つ目の「Multipath Extension for QUIC」はアリババ勢による提案である。こちらも、現在のMultipath 拡張の盛り上がりをうけて、今月提出された仕様である。
これは、Quentin De ConinckらによるMP-QUICを参考にしつつも、PathごとにSubConnectionとする構成を持つ。どうやら、すでに中国の特定動画ストリーミングサービスでユーザが使えるようになっているらしく、規模を拡大しつつ実験中らしい。
QUIC WG 中間会議
冒頭に述べたように、Multipath拡張をどう進めていくか盛り上がる中で会議を行い、それぞれのユースケースや知見について共有を行う場が用意された。
発表資料および、議事録は 下記から見ることが出来る。
github.com
この会議の中で
- Googleらによる、gQUIC時代におけるMultipath拡張の実装及び考察が共有された。実装やPathをまたぐ再送制御やスケジューリングが複雑になったこと、多くの場合はコネクションマイグレーションで十分ではないかという話が共有された
- Apple勢による発表では、MPTCPの利用経験から、SiriやApple Musicの例をあげてQUICのMultipath拡張に求められる要件が共有された
- アリババグループによる、動画ストリーミングのMultipath事例や、その他のユースケースに説明された。また、動画読み込みが早くなったというデモ動画も共有されている
- Akamaiのユースケースとして、多段キャッシュサーバ構成において2段目からダイレクトにクライアントにレスポンスを返すユースケースが紹介された
その他にも、衛星通信と地上での通信をMultipathで利用すると言ったユースケースなども共有されている。
これらの議論を通して、Multipath拡張のユースケースと有用性が確認された。
一方で、QUIC WGとしてどのようとりくんでいくかは、進め方の議論をしている段階である。例えば、Martin Thomson氏がメーリングリストに投稿した「My BoF report: multipath」では、Multipath拡張といった大きな取り組みの前に、QUICをデプロイし知見をためつつ、バージョンネゴシエーションといった大きな取り組みの前に準備する必要があると言っています。
その他にも、いくつか目的やデプロイ形式が異なるユースケースを、一つの仕様でカバーしようとすべきではないなどの意見が出ています。
議論の続き
QUIC WGとしてまだ、Multipath拡張をどう進めていくかは議論の最中です。
議論はメーリングリストで行われているので、気になる方はそちらを御覧ください
https://mailarchive.ietf.org/arch/browse/quic/
