この記事は、 NTT Communications Advent Calendar 2024 10日目の記事です。
先日、自前のMedia over QUICの実装をIETF 121のハッカソンへ持ち込んで相互接続試験に参加してきました。 その結果、他の参加者の実装との相互接続に成功し、Working Groupのリストに名前を記載いただけました。
本記事では、Media over QUICの概要や動向を紹介し、ハッカソンでの体験について報告します。
はじめに
こんにちは、イノベーションセンター所属の前田です。 WebRTCプラットフォーム「SkyWay」のR&Dを担当しています。
最近は、次世代のメディア伝送技術として提案されているMedia over QUIC（以下、MoQ）なども研究しており、同チームの内田とともに内製で開発した実装「moq-wasm」をOSS公開しています。
先日（2024年11月）、標準化貢献を目的としてIETF 121 Dublinのハッカソンへmoq-wasmを持ち込んで参加してきましたので、その様子や成果について報告します。 なお、MoQは現在策定中の比較的新しい概念ですので、本記事ではその概要の解説から行います。
Media over QUICとは？
概要
Media over QUICはその名のとおり、QUICでメディアを伝送するための技術を意味します。WebTransportにも対応しているのでブラウザからでも利用可能です。
プロトコルの構成
プロトコルスタックは以下のとおりです。
MoQのプロトコルスタック（出典: 中間会議資料）
MoQには大きく分けて以下2つの層が存在します。
- Media over QUIC Transport（以下、MOQT）
- ストリーミングフォーマット
MOQTの層ではメディアを送信するための共通のルールや振る舞いが提供されます。MOQTのドラフトを確認すると、メッセージの種類やフォーマットなどが定義されていることがわかります。
ストリーミングフォーマットの層ではMOQTの上でどのようにメディアを扱うかが定義されます。例えば、WARPというストリーミングフォーマットでは以下のことが定められています。
- WebCodecsを活用したLOCというメディアパッケージ手法を主に採用すること
- （扱うメディアは基本的に音声・映像のみ）
- 送信するメディアの情報を相手へ伝えるためにCatalogという仕組みを用いること
この記事を書いている2024年12月現在、WARPはまだ個人ドラフトの状態ですが、もうすぐ正式にWorking Group（以下、WG）ドラフトになる1予定です。
通信の参加者
MoQの通信には主に以下3種類の参加者が存在します。
- Original Publisher: メディアの送信を開始する
- Relay: メディアを受信し、（必要に応じてキャッシュし、）それを他の参加者へ転送する
- End Subscriber: メディアを受信し、それを他の参加者へ転送しない
Original / Endというワードが必要なのは、RelayがOriginal Publisherに対するSubscriberとなり、End Subscriberに対するPublisherとなるため、それらと区別するためです。
もしもメディアを双方向に送り合いたい場合、アプリケーションの中でメディアごとにOriginal PublisherとEnd Subscriberを入れ替えれば実現できます。
Relayの数は定められていません。アプリケーションのユースケースやその規模などに応じてRelayの台数を増やすことでスケーリングできます。
何が嬉しいの？
MoQは主に以下の2つのユースケースに対し、柔軟性を高めながらカバーしていくことが期待されています。
- HLS（HTTP Live Streaming）などを用いるようなメディアコンテンツ配信
- WebRTCなどを用いるようなリアルタイムコミュニケーション
具体的には以下が主なメリットだと思っています。
メディアのフリーズを防げる
主にHLSなどTCPベースの配信手段を活用する場合、パケットの送信に失敗すると次のパケットの送信を待たせて先に失敗したパケットを再送します。結果、パケットの再送が成功するまで後続のパケットが詰まってしまい、再生しているメディアがフリーズしてしまいます2。
QUICはTCPとUDPの特性を併せ持っているため、パケットの送信に失敗してもそのパケットの再送を待たずに後続のパケットの送信を行えます。これによって、ネットワーク障害などが発生している場合を除き、再生中のメディアのフリーズを抑えることができます。
映像や音声以外も扱える
現在最も議論が進んでいるストリーミングフォーマットは音声・映像を扱うWARPですが、それ以外のストリーミングフォーマットを定義することで全く違う種類のメディアを送信することもできます。 例の1つとして、MoQ上でチャットアプリケーションを実現する方法が個人ドラフトとして提案されています。 また、過去に別のWGの会議の中でXRに使用する3Dデータの送信手段の案の1つとしてMoQが言及されたこと3などもあり、将来的に幅広いユースケースで活用される可能性があります。
オンデマンドとリアルタイムを統合できる
これまでは、HLSのようなオンデマンド性とWebRTCのような高いリアルタイム性を両立した形でメディアコンテンツ配信を実現できるプロトコルが存在しませんでした。 一方、MoQは必要に応じてRelayにキャッシュを持たせることができ、WebRTCと同程度の遅延で送信できるため、これを実現できます。
過去の映像の再生中に、シームレスに現在の映像へ切り替えるような使い方も可能です4。
サードパーティのネットワークと連携しやすくなる
MoQは標準化の範囲にCDNの領域を含んでいることも大きな特徴の1つです。MOQTのドラフトの中では、アプリケーションから独立したサードパーティのネットワークを活用できるようになることを目標の1つとして定義しています。 また、送信されるメディアの秘匿性が保たれたまま転送されることを前提として定義していることもあり、これまで以上にCDNの選択・連携がしやすくなると予想されます。
現在の動向と未来予想
まず結論から述べると、MoQが広く活用され始めるまでにはまだまだ時間がかかると思っています。 理由は大きく分けて2つあります。
仕様安定化に向けた議論の継続
MoQ WGはIETF以外にも中間会議で議論を進めています。中間会議は2週間に1度開催されており、回によっては2日連続で6時間以上の会議を開催することもあります5。
MoQ WGの今後の会議予定日
また、現在のMOQTのドラフトの最新バージョンは07であり、まだ比較的若い状態だと思われます。さらに、ストリーミングフォーマットは一番議論が進んでいるWARPすらWGドラフトになっていません。
これらを踏まえると、仕様が安定するまでに今後も多くの議論が必要になると予想されます。
WebRTCの拡張機能との競合
現在リアルタイムコミュニケーションの用途で広く活用されているWebRTCは、あらゆるユースケースへ対応するために機能の拡張が進められている最中です。
一例として、扱うメディアの柔軟性を向上できるRTPTransportやリアルタイム配信用途で活用しやすくするためのWHIP / WHEPなどが提案され、各プラットフォームで実装が進められています。
今後もこのような拡張が続くことで、リアルタイム通信の領域においては、ある程度のユースケースはWebRTCでカバーできるようになっていくことが予想されます。
以上の理由から、MoQは仕様が定まるまでに数年かかり、その後特定のユースケースに向けて徐々に市場に浸透していくような流れになるのではないかと考えています。 特に、大規模な音声・映像配信のユースケースにおける活用が先行するのではないかと予想しています。
ハッカソンの参加報告
ここからはハッカソンの参加報告と題してIETFにおけるハッカソンの概要や私の取り組みをご紹介します。
IETFハッカソンについて
IETFハッカソンはIETFの最初の2日間の土日で開催されます。ハッカソンでは特定の技術の専門家が一箇所に集まり、アイディア出しや実装、相互接続試験などを行います。
ハッカソンの参加方法はオンサイトとリモートの2通りから選べます。 オンサイトの会場にはいくつものテーブルが用意されており、特定の技術に興味のある人が集まったら入口付近に貼られたボードへ技術名を書くことでテーブルを確保します。
テーブルボード（MoQ WGは#10を確保）
現在、MoQ WGの取り組み内容は特に指定されておらず、参加者は自由に議論したり自分のタスクに取り組んだりできます。 MoQの専門家だけではなくQUICやWebRTCなど関連技術の専門家が集まったり、あるいはたまに訪れてくださるので、その都度興味深い話を聞くことができます。
また、ハッカソン期間中に相互接続試験が行われています。もしも自分の実装を持っていれば試験に参加できます。 相互接続試験の結果はハッカソンの終わりではなくMoQ WGの会議の初めに発表されます。
ハッカソンにおける取り組み
私はオンサイトでハッカソンに参加し、moq-wasmの実装を持っていたため相互接続試験に取り組みました。
相互接続試験は参加者が実装した MoQ をそれぞれ接続するものです。 Relayの実装を持っている参加者はRelayサーバのURLを公開し、Original Publisher / End Subscriberの実装を持っている参加者は公開されたRelayサーバへの接続を試みます。 moq-wasmはRelay / Original Publisher / End Subscriberのすべてを実装しているため、Relayサーバの公開と他の参加者の繋ぎこみの両方を行いました。
これらの相互接続試験に関するやり取りはその場で、もしくはWGのSlack上で行われます。 RelayサーバのURLはSlackで公開されますが、基本的にはすぐに接続に成功せず、その場やSlack上でコミュニケーションを取りながら問題のある箇所を探します。 私の場合、オンサイト会場にいたLorenzo Miniero氏からいくつかのご指摘をいただき、問題を修正することで相互接続を成功させることができました。
また、他の参加者から報告された接続失敗の結果を分析してフィードバックすることで、その方の実装の修正に貢献できました。
結果として、いくつかの実装との接続に成功したため、WGの相互接続試験リストに「NTT(Tetta)」と名前を載せていただき、MoQ WGの会議の中で報告いただけました。
相互接続試験の結果6（出典: 会議のアーカイブ動画）
そして延長戦へ
実は会議の中で報告された結果は私が満足できる結果ではありませんでした。というのも、最終的な試験表はIETF開催の約2週間前にリリースされたドラフトバージョン07ベースの結果を元に作成されましたが、私が持ち込んだのはバージョン06ベースの実装だったため一部のメッセージしか疎通しなかったという結果となったためです。
（ハッカソンの終盤で07へのバージョンアップに取り組みましたが、他の参加者との接続確認は完了しませんでした）
ハッカソンの終わり際に、MoQ WG ChairのAlan Frindell氏に上手くいかず悔しかった旨を伝えたところ、なんと「後日集まって延長戦をやろう」と言ってもらえました。 私はこれを非常に嬉しく思い、IETFの会議の合間に準備を進めました。
そして、IETF 6日目の木曜日にThe Forumという名の部屋7に集まり延長戦を行いました。 結果として、メディアを送信するためのメッセージを含め、上記の表における「moxygen (Alan, Daniel, ...)」や「Meetecho (Lorenzo)」と一通り疎通を確認できました。
学び
相互接続試験では各参加者の実装方法や実行環境が異なるため、MoQの領域ではないところでいくつかの問題が生じました。私の場合はQUICやセキュリティに関する箇所で問題が発生し、解析や修正に時間がかかりました。この経験から、MoQだけではなく関連技術についても理解を深めることが重要だと学びました。
おわりに
今回はMoQ WGの相互接続試験に初めて参加し、いくつかの実装と相互接続できることを示したり、他の参加者の実装を改善した形で貢献できました。 今後もmoq-wasmのメンテナンスを続け、さらなる貢献を目指していきたいと考えています。
勉強会の宣伝
現在MoQは非常に議論が活発で、仕様もまだまだ大きく変わるので追いかけるのは大変だと感じています。 不定期で勉強会を開催しておりますので、MoQに興味があるという方は気軽にご参加ください。
なお、先日開催された勉強会では以下の資料で登壇しました。特にメッセージやシーケンスについて詳しく解説しています。
詳細が気になる方はぜひご確認ください。
謝辞
I would like to extend my gratitude to Alan, Lorenzo, and all the others who helped me. Thank you so much!
- 何か提案がある場合、まずは個人ドラフトとしてWGに提出し、WG全体で扱うべきと判断されたらWGドラフトになります。↩
- この問題をHead of Line Blockingと呼びます。↩
- MOPS WGの過去の会議で言及されています。↩
- WGではこの特徴のことを「Live Edge」と呼んでおり、現在具体的な実現方法について議論中です。↩
- これにより多くのことが中間会議で決まってしまうことを避けるため、QUIC WGの進め方の一部を取り入れてコンセンサスを得ることがIETF 121で提案されました。↩
- 空欄は接続試験に失敗したことを表しているとは限りません。今回参加しなかった方の項目や、サポートしている伝送方法（Raw QUICベースかWebTransportベース）の違いにより試験できない項目を含んでいます。↩
- IETF期間中は基本開放されている大広間であり、休憩スペースとして利用したり参加者同士でコミュニケーションを取る場として活用できます。↩
