MoQ の通信プロトコル側から見て 第1回 Media over QUIC とか勉強会 @flano_yuki

No content

Scope (Spec) ● Media over QUIC Transport (draft-ietf-moq-transport) ● WebTransport over HTTP/3 (draft-ietf-webtrans-http3) ● HTTP Datagrams and the Capsule Protocol (RFC 9297) ● HTTP/3 (RFC 9114) ● An Unreliable Datagram Extension to QUIC (RFC 9221) ● QUIC: A UDP-Based Multiplexed and Secure Transport (RFC 9000)

draft-ietf-moq-transport draft-ietf-webtrans-http3 HTTP/3 DATAGRAM QUIC Extended CONNECT

1. MOQT より下の話

MOQTの下位層 MOQTでは下記のプロトコルを下位層に用いる ● Raw QUIC ● WebTransport over HTTP/3

QUIC - UDPで動作する - ストリームでのアプリケーションデータの多重化 - 再送制御・輻輳制御 (+DATAGRAM拡張) - コネクションマイグレーション Client Server QUICパケット QUICパケット QUICパケット QUICパケット Src Connection ID Dst Connection ID Src Connection ID Dst Connection ID QUICパケット QUICフレーム QUICフレーム

WebTransport over HTTP/3 - HTTP/3 (QUIC上でHTTPリクエスト・レスポンスをやりとりする)を拡張して、双方向 用途につかう仕組み - HTTPリクエスト (拡張CONNECT)で、確立したコネクションをWebTransport用に利 用する - アプリケーション用途で、双方向ストリーム・単方向ストリーム・DATAGRAMが使える - コネクションプーリングにより、一つのQUICコネクションに複数用途通信を多重化出 来る (a.example.com/b.example.com通信。 通常リクエスト + WebTransport) QUICパケット QUICフレーム(s-id) QUICフレーム(s-id) HTTP/3フレーム HTTP/3フレーム

DATAGRAM - QUICではアプリケーションデータは再送制御により再送されます。 - QUIC DATAGRAM拡張として定義されるDATAGRAMフレームは、 UnOrderd かつ UnReliableなメッセージ送信が可能 - 輻輳制御をうける - Ackの対象となる - Raw QUICでも、WebTransport over HTTP/3で送れる。 - DATAGRAMフレームはストリーム上で送られるわけではない

比較 MOQTをRAW QUICで使うかWebTransportで使うか - WebTransportはHTTPリクエストなので - URLをもち、LBのようにそれによりルーティングが出来る (Raw QUICでも便宜上URL定義してるが、ルーティング用ではない - HTTPヘッダがつく。HTTP認証/Cookie認証 - （コネクションプーリングが今後使えるかも...?） - QUICはシンプル - HTTPレイヤ (QPACK) とか実装しなくてよい - ブラウザのサポート次第...? - (ブラウザがRaw QUICならそれでいいが、poolingしたそう - クラウドのマネージドLBがQUICやWebTransportのLBを提供するか？

フォールバックについて QUICが疎通しない環境もあるため、QUICを使うプロトコルではTCPベースプロトコルの フォールバック先を考える必要がある。(HTTP/3ならHTTP/2など) MOQTとしては、フォールバック先、つまりTCPベースのMOQTは定義しておらず。各自 で考えてねということになっている。。。 一応、手段はあるがMOQTとしては言及されてない - QUIC on Streams (draft-kazuho-quic-quic-on-streams) - WebTransport over HTTP/2 (WebTransport over HTTP/2)

2. MOQT の話

No content

MOQT - メディアデータ (Object)を、配送するためのプロトコル。 - 具体的なメディアデータの形式は言及していない - メディア用のデータをStream/Datagramで送信できる - Pub/Sub - ANNOUNCE/SUBSCRIBEの仕組みを提供 - 受信者がどのデータをSubscribeするか - CDN(リレー)をサポートする前提で設計 あくまでトランスポートであり、スケジューリングは別

MOQTの動機 - レイテンシー: キューイング(バッファ)を制御し、輻輳を迅速に検出したい - QUICの活用: TCPレイヤのHoLBを回避したい - ユニバーサル: 動画の取り込みから配信までを単一のプロトコルで実現 - リレー: サードパーティによる中継をサポートしたい

登場人物 Original Publisher Relay Publisher ingestion relay delivery End Subscriber End Subscriber Publisher Publisher Subscriber Subscriber Subscriber Relay 下流 上流

Track Grpoup Grpoup Grpoup トラック/グループ/オブジェクト MOQTでのデータモデル - Object: 最小単位。バイトシーケンス。 - Group: グループ内のオブジェクトは順番・依存関係をもつ。受信単位 - Track(+Track Namespace): サブスクライバーがSubscribeする単位 Object Object Object Object

優先度制御 優先度制御の指定。 （もちろん単一セッション内のでの送信するデータの優先度の話し） - Original Publisherはオブジェクト毎に8bit長での優先度を設定できる - SubscriberはSUBSCRIBE時に - 8bit長で購読Trackの優先度を8bit長で指定できる - Groupの受信について、降順か昇順の優先度を指定できる 一つのセッション内で複数Subscriptionがある場合、Subscriberの優先度をまず見て から、オブジェクトの優先度をみて、送信されるデータが決まる （*古いHTTP/2の優先度制御は、送信割合とか決めれたけど...

Publisher/Subscriberの通信 (Relayを除く) Publisher Subscriber QUIC/WebTransport コネクション確立 CLIENT_SETUP SERVER_SETUP SUBSCRIBE SUBSCRIBE_OK OBJECT

MOQTのメッセージ 利用ストリーム - オブジェクトの送信は、単方向ストリームもしくはDATAGRAM ( 一つのストリームで複数オブジェクト送っても良い - それ以外(通信の制御・切断・OK・エラーなど)は、セッション開始時にクライアントか ら開通される双方向ストリーム (制御ストリーム)。 メッセージフォーマット

MOQTのメッセージ ● OBJECT_STREAM ● OBJECT_DATAGRAM ● SUBSCRIBE_UPDATE ● SUBSCRIBE ● SUBSCRIBE_OK ● SUBSCRIBE_ERROR ● ANNOUNCE ● ANNOUNCE_OK ● ANNOUNCE_ERROR ● UNANNOUNCE ● UNSUBSCRIBE ● SUBSCRIBE_DONE ● ANNOUNCE_CANCEL ● TRACK_STATUS_REQUEST ● TRACK_STATUS ● GOAWAY ● CLIENT_SETUP ● SERVER_SETUP ● STREAM_HEADER_TRACK ● STREAM_HEADER_GROUP

CLIENT_SETUP/SERVER_SETUP クライアントとサーバーが交換する最初のメッセージ - ピアは相互にサポートされるバージョンを確立し - オブジェクトを交換する前に初期設定を行う。 パラメータ - Version - ROLE parameter - PATH parameter - ここにURIが入る - (Support Extension)

SUBSCRIBE Trackのサブスクライブを行う - Subscribe IDの指定 - Trackの指定 - Filter Type - Latest Group - Latest Object - AbsoluteStart - AbsoluteRange

SUBSCRIBE 関連 - SUBSCRIBE_OK - Publisherから送信する、SUBSCRIBEに対する正常応答 - SUBSCRIBE_ERROR - Publisherから送信する、SUBSCRIBEに対する異常応答 - UNSUBSCRIBE - Subscribeから送信する、Subscriptionの解除 - SUBSCRIBE_UPDATE - Subscribeが送信する、SUBSCRIBEメッセージの更新。Subscriber Priorityの変更など - SUBSCRIBE_DONE - Publisherが送信する、SubscribeがSUBSCRIBEしたTrackの終了

OBJECT_STREAM/OBJECT_DATAGRAM Objectデータおよびメタデータ。 Streamで送る場合もDATAGRAMで送る場合も中身は一緒 - Subsrive ID, Group ID, Object ID, Priority - Object Status - Normal object - Indicates Object does not exist - Indicates Group does not exist - Indicates end of Group - Indicates end of Track and Group - Payload 一つのストリームで複数オブジェクトを 送る Multi-Object Streams の仕組みも

GOAWAY (サーバ側のシャットダウンなどで) セッションを張りなおすることを、サーバからクライア ントに通知する。実際のセッション切断は下のレイヤで出来る 移行先のURIを通知する。

Publisher/Relay/Subscriber Publisher Relay CLIENT_SETUP SERVER_SETUP ANOUNCE ANNOUNCE_OK Subscriber SUBSCRIBE SUBSCRIBE_OK SUBSCRIBE SUBSCRIBE_OK CLIENT_SETUP SERVER_SETUP

ANNOUNCE パブリッシャーから(Relayに対して)、ANNOUNCE 制御メッセージを送信する ルーティング出来るようにTrack Namespaceを通知する

3. Major Issues

Issues - Always use ALPN for version negotiation #499 - バージョンネゴシエーションを ALPNでやる - Peeps First Attempt #494 - Peepsというグルーピングを追加 Group>Peep>Object - Add MAX_SUBSCRIBE_ID to limit number of subscriptions #491 - Discovery of publishers via a relay instead of catalog #484 - No way to keep two subscriptions with identical priority in sync #475 - 複数トラックの同期 - Sender-side ABR #259 -

4. Any Other Work

draft - Logging over Media over QUIC Transport (draft-jennings-moq-log) - Metrics over MOQT (draft-jennings-moq-metrics) - Secure Objects for Media over QUIC (draft-jennings-moq-secure-objects) - -