Re: [Moq] Scope of MOQ and ULL Streaming

Bernard Aboba <bernard.aboba@gmail.com> Wed, 08 February 2023 23:21 UTC

From: Bernard Aboba <bernard.aboba@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Date: Wed, 08 Feb 2023 15:21:34 -0800
Message-Id: <677D4402-9BA0-480E-A7F5-EA17DBFDD0AB@gmail.com>
References: <2A48E511-F42A-4819-9952-48EBBB52A682@networked.media>
Cc: Luke Curley <kixelated@gmail.com>, nathan.burr@paramount.com, "Shihang(Vincent)" <shihang9@huawei.com>, MOQ Mailing List <moq@ietf.org>
In-Reply-To: <2A48E511-F42A-4819-9952-48EBBB52A682@networked.media>
To: "Ali C. Begen" <ali.begen@networked.media>
Archived-At: <https://mailarchive.ietf.org/arch/msg/moq/zusdbrDyJGqs2IkXlDQqG-E53JI>
Subject: Re: [Moq] Scope of MOQ and ULL Streaming
Precedence: list

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. 

> 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.  

> 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.

[Moq] Scope of MOQ and ULL Streaming Nathan Burr
Re: [Moq] Scope of MOQ and ULL Streaming Bernard Aboba
Re: [Moq] Scope of MOQ and ULL Streaming Shihang(Vincent)
Re: [Moq] Scope of MOQ and ULL Streaming Nathan Burr
Re: [Moq] Scope of MOQ and ULL Streaming Spencer Dawkins at IETF
Re: [Moq] Scope of MOQ and ULL Streaming Luke Curley
Re: [Moq] Scope of MOQ and ULL Streaming Spencer Dawkins at IETF
Re: [Moq] Scope of MOQ and ULL Streaming Nathan Burr
Re: [Moq] Scope of MOQ and ULL Streaming Bernard Aboba
Re: [Moq] Scope of MOQ and ULL Streaming Ali C. Begen
Re: [Moq] Scope of MOQ and ULL Streaming Bernard Aboba
Re: [Moq] Scope of MOQ and ULL Streaming Ali C. Begen
Re: [Moq] Scope of MOQ and ULL Streaming Suhas Nandakumar
Re: [Moq] Scope of MOQ and ULL Streaming David Fernández
Re: [Moq] Scope of MOQ and ULL Streaming Bernard Aboba
Re: [Moq] Scope of MOQ and ULL Streaming Spencer Dawkins at IETF
Re: [Moq] Scope of MOQ and ULL Streaming Bernard Aboba
Re: [Moq] Scope of MOQ and ULL Streaming Luke Curley
Re: [Moq] Scope of MOQ and ULL Streaming Behcet Sarikaya
Re: [Moq] Scope of MOQ and ULL Streaming Charles 'Buck' Krasic
Re: [Moq] Scope of MOQ and ULL Streaming Nathan Burr
Re: [Moq] Scope of MOQ and ULL Streaming Suhas Nandakumar
Re: [Moq] Scope of MOQ and ULL Streaming Spencer Dawkins at IETF