3 月 15 日 ~ 3 月 21 日に開催された IETF 122 で、Media over QUIC Transport(MoQT)の相互接続試験に参加しました。 相互接続試験では、NTT Communications(以下 NTT Com) が OSS で公開している moq-wasm を持ち込み、4 種類の MoQT 実装と接続できました。
本記事では、Media over QUIC Transport(MoQT)の概要や、相互接続試験で遭遇した問題や、相互接続試験の結果について報告します。
はじめに
NTT Com で SkyWay の R&D エンジニアをしている 内田です。
3 月 15 日から 3 月 21 日で開催された IETF 122 の ハッカソンイベントで、Media over QUIC Transport(MoQT)の相互接続試験に参加しました。
本記事では、我々の実装の不具合や、他実装の修正提案、WebTransport ライブラリへの Pull Request など、相互接続試験によって得られた知見や成果を共有します。 同僚の前田が参加した IETF 121 の記事も過去に公開しておりますので、こちらも合わせてご覧ください。
Media over QUIC Transport(MoQT)とは
Media over QUIC Transport(MoQT)とは、その名の通り、QUIC プロトコルを利用して Media を送受信するためのプロトコルです。
MoQ のプロトコルスタック（出典: 中間会議資料)
前回のIETF 121 参加記事でプロトコルスタックについては詳しく説明しておりますので、本記事では割愛します。
取り組みの背景
NTT Com が開発している SkyWay は、誰でも簡単にビデオ・音声通話が簡単に実装できる、マルチプラットフォームな SDK です。
SkyWay は現在、WebRTC を採用して、ビデオ・音声通話を実現しておりますが、WebRTC はウェブ会議に非常に特化したプロトコルであるため、それ以外のユースケースにおいては WebRTC のカスタマイズ性に関する問題が発生する場合もあります。
そのため SkyWay は、幅広いユースケースで活用できる MoQT による映像・音声・データ配信に注目しており、MoQT のプロトコル実装 moq-wasm の開発や IETF の相互接続試験への参加を通して、MoQT の仕様標準化に貢献していきたいと考えています。
より詳しいモチベーションについては、MoQ とか勉強会#2 の登壇スライドをご覧ください。
相互接続試験の雰囲気と結果報告
3/15(土) ~ 3/16(日) は ハッカソン の時間として確保されており、3/16 の夕方にはその結果が会場全体に共有されます。
会場はテーブルごとに取り組む内容が分かれており、私は Media over QUIC / RTP over QUIC のテーブルに合流しました。
MoQ のテーブルには、Meta や Cisco、Meetecho、学生の方など、4 人 ~ 8 人程度の方が集まっていました。IETF のセッションで発表予定の方もいたため、土日通してテーブルにいたのは 4 人程度でした。
私は IETF 初参加で初対面の方ばかりだったのですが、打ち解けやすい環境で、非常に楽しく相互接続試験を行えました。
今回の相互接続試験では、IETF 121 での結果に引き続き、多くの MoQT 実装との接続に成功しました。持ち寄られた MoQT 実装は、draft-08 対応している実装と、draft-10 対応している実装で分かれていたものの、moq-wasm は draft-10 に対応していたため、適宜修正しながら相互接続試験を行いました。
MoQT は WebTransport と Raw QUIC の両方に対応しているプロトコルですが、moq-wasm は WebTrasnport のみ対応しているため、WebTransport に対応している moxygen, meetecho, aiomoqt, moqtail などの実装と相互接続試験を行い、接続に成功しました。相互接続試験の結果については、下図をご確認ください。
相互接続試験で見つかった問題 1 ( moxygen ↔ moq-wasm )
Meta が開発している moxygen の client と moq-wasm を接続した際に、MoQT ではなく WebTransport レベルで疎通できないという問題に遭遇しました。
この問題は、moxygen が利用している proxygen という HTTP3(WebTransport)ライブラリと、moq-wasm が利用している wtransport という WebTransport ライブラリが疎通しない問題でした。
wtransport が WebTransport の双方向ストリームを確立する際に、想定されている種別ではない QUIC フレームを受け取ると確立できずに破棄されてしまうのが問題であったため、wtransport にパッチを加えることで解消できました。この変更は wtransport に PR を上げて、現在はマージされています。
この問題は IETF121 での相互接続試験でも発生しており、解消できていない問題でした。
自身で実装していない QUIC / WebTransport ライブラリの問題で、原因究明には 3 日ほどかかってしまいましたが、IETF 期間中に解消でき、moxygen client と疎通が確認できたため良かったです。
相互接続試験で見つかった問題 2 ( aiomoqt ↔ moq-wasm)
aiomoqt と moq-wasm を接続した際に、MoQT レベルで疎通しない・特定のメッセージがパースできない問題に遭遇しました。
MoQT レベルで疎通しない問題に関しては、aiomoqt のサーバー実装で受け取った URL が正しくデコードされていない問題であり、こちらは aiomoqt の実装者の方に連絡することで解決できました。
また、特定のメッセージがパースできない問題に関しては、我々の実装である moq-wasm において SUBSCRIBE メッセージの Parameter 情報の処理が誤っていたことが分かったため、修正を加えた所、疎通が確認できました。
相互接続試験で見つかった問題 3 ( 複数の実装 ↔ moq-wasm)
複数の実装から我々の moq-wasm サーバーに SUBSCRIBE メッセージを送信した際に、サーバー側で MoQT メッセージが受け取れず、処理できないという問題が発生しました。
この問題の原因究明には非常に時間がかかりましたが、QUIC のログを確認したところ、「パケットサイズが大きい MoQT メッセージを双方向ストリームで受け取った際にパケットロスが発生し、回復しない」という事象が原因であるとわかりました。
この問題の根本的な原因は未だ分かっていませんが、QUIC のパケットロス検知の閾値の変更や、QUIC パケットのサイズの上限を設定する修正を加えたところ、疎通が確認できました。
結果を振り返って
今回の相互接続試験では、解決に時間を要する問題が複数発生しました。
しかし、前回の IETF121 では接続できなかった moxygen client ↔ moq-wasm server 間での接続も成功し、wtransport に PR を上げることで、WebTransport の相互接続試験という観点でも貢献できました。意義のある取り組みになったと感じています。
今後は QUIC / WebTransport の問題にも迅速に対応できるよう、これらの仕様についても理解する必要がありそうです。
「MoQT 実装は QUIC 対応のみの実装も多い」という事も実感できたため、今後は moq-wasm の Raw QUIC 対応も行っていきたいと考えています。
おわりに
今後も MoQT の仕様変更に追従して moq-wasm の開発を継続し、Raw QUIC 対応や、RTP over QUIC の実装なども行うことで、仕様の標準化に貢献していきたいと思っています。
