要約

  • Media over QUIC Transport第22版では、FORWARD=0 が確立済み購読のObject配信を一時停止する一方、PUBLISH_DONEなどの制御メッセージは継続する。
  • 下流購読者が全員一時停止しても、リレーはキャッシュを温めるため上流購読を動かし続けられる。一時停止の記録だけでは、取得や資源消費の停止を証明できない。

視聴者が一時停止を押す。映像が止まり、端末へのトラフィックが減る。ところが中間リレーは、再開を速くするためライブトラックを上流から受け取り続けているかもしれない。MOQTの現行草案では、この二つは矛盾しない。

2026年10月1日付のdraft-ietf-moq-transport-22は、QUICとWebTransport上で動く発行・購読プロトコルを定義する。DatatrackerはMedia Over QUIC作業部会のActive Internet-Draftとしている。RFCでも、実装・導入の証拠でもない。本文ヘッダーはStandards Trackと記す一方、Datatrackerは現在、想定RFCステータスを表示していない。この差異を承認と読み替えてはならない。

第22版は機構を新設したというより、境界を言い直した。第21版は0または1のForward Stateと呼んでいた。第22版は購読を一時停止中か否かと表現し、変更履歴にもその改称を記録する。基礎動作は以前からあったが、運用上の意味が見えやすくなった。

一時停止中、Publisherはその購読にObjectを送らない。しかしPUBLISH_DONEを含む制御メッセージは送る。初期状態はPUBLISHまたはSUBSCRIBE内のFORWARDで決まり、SubscriberはREQUEST_UPDATEに0を入れて止め、1で再開する。それ以外の値はプロトコル違反となる。

一時停止は取消しではない。購読状態は、取消し、PUBLISH_DONE、REQUEST_ERRORまで維持される。過去分の補完要求も自動保存されない。一時停止中に処理されたFILL_PARAMETERSはfill-fetchストリームを開かず、同じ購読を再開するだけでも後から開かない。補完には改めて意思表示が要る。

ストリーム終端の意味も異なる。関連Objectを全部送る前にSubgroupストリームを閉じるならリセットが必要で、第22版は一時停止によるObject省略をその例に挙げる。正常なFINは購読開始点からの完全性を支え得る。リセットは、最後に受信したObjectの後にも何かが存在し得ると示す。両者は同じ完了証跡ではない。

リレーの裁量はさらに重要だ。下流に一人でも非停止の購読者がいれば、リレーは受信と転送のため上流購読を非停止に保たなければならない。全員が止まったときは、上流も止めるかをリレーが選ぶ。

上流を動かせばObjectを受け取ってキャッシュを予熱でき、再開遅延を抑えられる。一方で、その時点では誰にも下流配信していないコンテンツのため、Publisherと上流資源を使う。上流も止めれば作業を避けられるが、再開が遅くなり得る。仕様はこの利害を局所判断として残した。

したがって画面上の「一時停止済み」は、料金、プライバシー、資源休止まで証明しない。特定購読の配信状態を表すだけで、上流取得、キャッシュ変更、Publisher処理、課金対象トラフィックの停止は別の事実である。逆に継続も推定できない。上流側を観測する必要がある。

運用には七つの記録が要る。Subscriberが順序付きで出した停止意思、Publisherが確認した状態、下流Objectの実際の停止、継続する制御メッセージ、リレーの上流方針、上流トラフィックとキャッシュ変化の計測、そして再開後に視聴者が得た結果である。一つの応答で残りを代用してはならない。

Heng LuのMinimum Initial Specificationは、共通仕様がFORWARDの作用を厳密に定め、遅延と資源の選択は局所に残せることを示す。Running-Code Primacyはラベルではなく両方向の実測を求める。Reality Layersは停止画面、プロトコル状態、キャッシュ、Publisherの仕事を分離する。これはDaniel Kadeの編集上の適用であり、IETFの見解ではない。

命令の権限は、明記された境界までである。利用者は自分への配信を止められるが、リレーの上流戦略まで自動的に支配しない。取得ゼロ、キャッシュ書込みゼロ、費用ゼロを約束するなら、別の制御と別の証跡が必要だ。

出典