Re: [Moq] Scope of MOQ and ULL Streaming

On Wed, Feb 8, 2023 at 3:32 PM Ali C. Begen <ali.begen=
40networked.media@dmarc.ietf.org> wrote:

>
>
> > On Feb 8, 2023, at 3:21 PM, Bernard Aboba <bernard.aboba@gmail.com>
> wrote:
> >
> > On Feb 8, 2023, at 14:28, Ali C. Begen <ali.begen@networked.media>
> wrote:
> >>
> >> If there were some performance numbers put forward by the RUSH folks,
> we would have a better idea. Without a code we can play with and no
> reported results, your conclusion is just a guess and it is not necessarily
> better or worse than mine.
> >
> > [BA] I have an open source JavaScript implementation of frame/stream
> transport, as described on day 1 of the Interim.  It’s using headers closer
> to RTP than RUSH, but it would be easy to modify it to make it more
> “RUSH-like”.  If we could agree on what “performance numbers” might be
> relevant (I’m measuring frame RTTs, loss, reordering, etc. at the moment),
> perhaps we can make some progress.
>
> Yes, and we will start with that as soon as we can and indeed “performance
> numbers” is part of the requirements discussion I mentioned below.
>
> >
> >> Agreed and because of that we are still repeating some of the questions
> that were asked a year ago. It is not necessarily a bad thing and every
> viewpoint may provide new insights into the problem at hand, but I feel we
> are reinventing some of the things we had in the early days of DASH/CMAF
> (with very minor changes and not necessarily all good).
> >
> > [BA] Yes, that was my feeling as well.  When I talk to people about MoQ
> they understand the need for a successor to RTMP, but they are puzzled as
> to why it is necessary to reinvent HLS/DASH.
>
> I will post the link again:
>
> https://dashif-documents.azurewebsites.net/Ingest/master/DASH-IF-Ingest.html
>
> It can replace RTMP right on.
>
> We published this version some time ago before H3 was finalized and all
> that. It has the right notion of “pushing” using HTTP for ingest. It is not
> perfect for some of the use cases mentioned here, but I don’t see why it
> would be a bad starting point if we are cool with keeping the DASH/HLS
> syntax/model. We can work on it, make it use H3 with priorities, etc. so
> that it does pretty much what most of us want to do.
>
> >> As you all know, codec folks publish a new codec standard once they are
> about 50% better than the last one. We should debate how much we need to be
> better than what we have today or what we are addressing that was not
> addressed before. Then, we write the requirements for that purpose and list
> the agreed assumptions.
> >
> > [BA] That approach would be more likely to convince the doubters.
>
> +1
>
>
>

Our hope with the proposal of QUICR as pub/sub based media delivery
protocol over QUIC , was for the WG to think about building a media
delivery protocol that allows for unified (interactive + streaming)
use-cases and make ways to enable applications like mixed reality
(Hologram, VR tiles), gaming and so on.

 I tend to agree with the sentiments laid out by Ali and Bernard here. I
think it will be beneficial and important for us to keep a longer term
vision and range of media applications in mind when developing the MoQ
protocol. Also any such protocol would be greatly benefited with native
support for intermediaries, like CDNs/Service providers, that play a larger
part of the content distribution over the Internet.

For anyone interested in learning more on QUICR, here are few links:

Protocol:
https://www.ietf.org/archive/id/draft-jennings-moq-quicr-proto-01.html

and a intro slide-deck on the same here:
https://datatracker.ietf.org/meeting/114/materials/slides-114-moq-if-time-
permits-quicr-01

Please note that we have paused updates to QUICR Spec for the time being
and hence, it  lacks the more recent details on its development. I am happy
to talk/share further and discuss ideas with anyone who is interested.
Please let me know.

Cheers
Suhas

-- 
> Moq mailing list
> Moq@ietf.org
> https://www.ietf.org/mailman/listinfo/moq
>