Re: [Moq] Scope of MOQ and ULL Streaming

[Luke Curley <[e-mail]>]

I also have a mostly HLS background. It's important to take a step back and
explore *why* we want to replace HLS/DASH, and what we lose by doing so.

The best part about HLS/DASH is the HTTP ecosystem. That includes CDN
support, optimized software, and general interoperability. We lose a lot of
this by creating a custom pub/sub mechanism.

The worst part about HLS/DASH is the latency. This is caused by
head-of-line blocking (buffering) and the client being in charge
(requesting playlists and segments). The Warp draft tackles these problems
with QUIC prioritization (delivery order) and WebTransport push
respectively.


The premise behind specifying a generic pub/sub protocol is that we can
support non-media applications, so it's then more attractive for a CDN to
support MoQ. However I'm terrified that we don't have any other
applications in mind, and we're too eager to sacrifice media functionality
in the pursuit of a bigger pie.

I'm not saying that we can't fulfill all of our media requirements with a
generic pub/sub protocol. That being said, I think it's telling that I
haven't seen an existing pub/sub protocol used for media. I would like to
know why "Media over MQTT" or "Media over RabbitMQ" is not adequate.
Routing objects based on a path and wildcard subscriptions has been done
many, many times before and I want a reason why this time is different.


So I strongly urge us to focus on media first. That means pull media with
HTTP/3, or push media with WebTransport. The middle ground is the worst of
both: we won't produce something generic enough and/or we won't produce
something media-specific enough.



On Tue, Feb 7, 2023, 4:48 AM Nathan Burr <[e-mail]> wrote:

> MQTT is a Pub/Sub protocol used for sending data generally for the
> "Internet of Things" devices to the cloud. I wouldn't use it here for this
> type of thing. but something similar could work. What I like about it is
> how you can create topics ( looks like paths ) and use wildcards. This
> site
> <https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/>
> might help if you would like to learn more.
>
> encoders would publish data to a topic.
>
> anyone can subscribe to a topic and so any updates get sent to all people
> who subscribe as soon as they are available
>
> You could make it so you could subscribe to Big_Buck_Bunny/Metadata  and
> then have it send the current persistent data for that topic and all future
> updates or just do a regular GET request for the current metadata and not
> subscribe to any changes.
>
> On Mon, Feb 6, 2023 at 9:04 PM Shihang(Vincent) <[e-mail]>
> wrote:
>
>> <External Email>
>>
>>
>> Hi Nathan,
>>
>>
>>
>> “In my opinion, MOQ should be a stateless forwarding machine. I would
>> like to do two basic types of requests.
>>
>>    - Subscribe
>>       - I picture this is something similar to how MQTT works with
>>       topics. Subscribe to a topic or sub topics and use wildcards. Example:
>>
>> Big_Buck_Bunny/VideoTrack{N}/Representation{N}/
>> Big_Buck_Bunny/AudioTrack{N}/Representation{N}/
>> Big_Buck_Bunny/SubtitleTrack{N}/Representation{N}/
>>
>>    - GET
>>       - I feel like this would still be important to discover
>>       information about the channel without having to subscribe. IMO each topic
>>       should have an associated metadata endpoint. that describes the channel,
>>       track, representation. This way a client can get stream details without
>>       needing information from a manifest.”
>>
>> I am not familiar with the MQTT. What is the difference between the
>> Subscribe and GET?
>>
>>
>>
>> Cheers,
>>
>> Hang
>>
>> *From:* Moq <[e-mail]> *On Behalf Of *Nathan Burr
>> *Sent:* Tuesday, February 7, 2023 1:05 AM
>> *To:* [e-mail]
>> *Subject:* [Moq] Scope of MOQ and ULL Streaming
>>
>>
>>
>> *Discussion #1:*
>>
>>
>>
>> I've spent a bit of time trying to wrap my head around what MOQ is and I
>> feel like this needs to be discussed further. I've seen everything from VR,
>> Conferencing, ULL Broadcasting and gaming as possible use cases. I feel
>> like this is an important discussion because MOQ could be a base layer spec
>> that supports all of these. But that means possibly the need for more
>> specs. Such as VR ov MOQ or ULL Streaming over MOQ. Or it could be a Spec
>> that is more specific to just one thing. The original work around WARP
>> seemed to lean more towards ULL Streaming while RUSH leaned more towards VR
>> and gaming.
>>
>>
>>
>> So where does MOQ fit into all of this? Maybe this has already been
>> discussed and I'm just missing context..
>>
>>
>>
>> My expertise is around ABR Streaming. So I'll be providing more feedback
>> on that side of the conversation of where I would like things to go.
>>
>>
>>
>> *Discussion #2:*
>>
>>
>>
>> What is the target latency? Maybe that depends on the answer to
>> Discussion #1. For ULL Streaming I would think somewhere between 500ms -
>> 2.5s.
>>
>>
>>
>> *Discussions around ULL Streaming involving MOQ:*
>>
>>
>>
>> [image: image.png]
>>
>>
>>
>> In my opinion, MOQ should be a stateless forwarding machine. I would like
>> to do two basic types of requests.
>>
>>    - Subscribe
>>
>>
>>    - I picture this is something similar to how MQTT works with topics.
>>       Subscribe to a topic or sub topics and use wildcards. Example:
>>
>> Big_Buck_Bunny/VideoTrack{N}/Representation{N}/
>> Big_Buck_Bunny/AudioTrack{N}/Representation{N}/
>> Big_Buck_Bunny/SubtitleTrack{N}/Representation{N}/
>>
>>    - GET
>>
>>
>>    - I feel like this would still be important to discover information
>>       about the channel without having to subscribe. IMO each topic should have
>>       an associated metadata endpoint. that describes the channel, track,
>>       representation. This way a client can get stream details without needing
>>       information from a manifest.
>>
>> Relaying is probably out of scope for MOQ. Looks like some are working on
>> that process. But I would imagine some sort of smart relaying where you
>> only relay what is being subscribed to down the subscription chain.
>>
>>
>>
>> In order to support channel composition (inserting ads, blackout, slate,
>> scheduling, switching channels, PiP, contributor feed, commentary, etc.) I
>> feel like we will still need a manifest of some sort that contains
>> different metadata from different assets and channels. In this scenario
>> having the ability to share a session ID between the manifest and transport
>> would be important. This would probably fall under some of the other AuthZ
>> type of discussions.
>>
>>
>>
>> Session ID would be needed to make sure to terminate any subscriptions
>> after their subscription has expired.
>>
>>
>>
>> *Next Gen ULL Streaming Wish List:*
>>
>>    - "Synchronization Tracks" for quick channel switching and recovery.
>>    https://media.idlab.ugent.be/keyframe-insertion-electronics
>>    <https://urldefense.com/v3/__https://media.idlab.ugent.be/keyframe-insertion-electronics__;!!CxwJSw!LOoclAmKobZ09z6p5IugHIWxEy8E7fyRwvdOA-UWtCTQzsvTqJ403kaIhBxVsr9_yhbH5gPzeBRAn6qOXBJq$>
>>
>>
>>    - AV1 - Switch Frames
>>
>>
>>    - DRM - EME requires ISOBFF. Would be nice if EME supported raw ES.
>>    Some discussions around content protection and WebCodecs:
>>    https://github.com/w3c/webcodecs/issues/41
>>    <https://urldefense.com/v3/__https://github.com/w3c/webcodecs/issues/41__;!!CxwJSw!LOoclAmKobZ09z6p5IugHIWxEy8E7fyRwvdOA-UWtCTQzsvTqJ403kaIhBxVsr9_yhbH5gPzeBRAn56wzYmv$>
>>    Could make it so we transport CMAF over MOQ or make a polyfill around
>>    EME/MediaSource that muxes content into ISOBFF format. as long as the ES
>>    conforms to CENC spec.
>>    - No more polling. Updates to the manifest are streamed.
>>
>>
>>
>> -Nate
>>
>>
>>
>>
>>
>>
>>
>> --
> Moq mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/moq
>
>