Subject: [Moq] Two questions about how to move MOQ forward

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 30 Oct 2021 12:16:46 -0500

Dear MOQ fans,

It looks like we're starting the discussion(s) on this mailing list that
many of us were hoping for. Two questions present themselves to me.

   - Would anyone object to me trying to organize the discussions we're
   having on the mailing list now (for instance, "one email thread per
   question")? Obviously, this is a non-WG mailing list, so it's not like we
   have chairs here ...
   - Do we need at least one side meeting during IETF 112, to get organized?

It seems to me that we could use one side meeting early in the IETF 112
meeting week to talk about the questions we're identifying (along with
anything else that comes up between now and then), and another side meeting
later in the week, to talk about how to organize the work we're talking in
a way that the IETF can carry that work out.

Best,

Spencer

---

From: Alan Frindell <[email-masked]>
Date: Sat, 30 Oct 2021 19:42:44 +0000

Hi Spencer, thanks for helping drive the effort forward here.  I have no objections to organizing the discussions as you suggest.

As for a side meeting, I definitely think we should have one (or even two).  I don’t mind helping to organize it like last time, though if someone else wants to that’s ok with me.

-Alan

From: Moq <[email-masked]> on behalf of Spencer Dawkins at IETF <[email-masked]>
Date: Saturday, October 30, 2021 at 10:17 AM
To: MOQ Mailing List <[email-masked]>
Subject: [Moq] Two questions about how to move MOQ forward

Dear MOQ fans,

It looks like we're starting the discussion(s) on this mailing list that many of us were hoping for. Two questions present themselves to me.

  *   Would anyone object to me trying to organize the discussions we're having on the mailing list now (for instance, "one email thread per question")? Obviously, this is a non-WG mailing list, so it's not like we have chairs here ...
  *   Do we need at least one side meeting during IETF 112, to get organized?
It seems to me that we could use one side meeting early in the IETF 112 meeting week to talk about the questions we're identifying (along with anything else that comes up between now and then), and another side meeting later in the week, to talk about how to organize the work we're talking in a way that the IETF can carry that work out.

Best,

Spencer

---

From: Lucas Pardue <[email-masked]>
Date: Sat, 30 Oct 2021 23:58:44 +0100

Hi Spencer,

I would ask 4 different questions (perhaps in addition?)

1. Does anything here depend on the agendas of other WG meeting at 112? (I
think the answer is no but will stand to be corrected ). The answer here
helps scheduling.

2. Are folks aligned on a single problem, or aligned on differentiable
problems? I.e. is there one or many problems to solve

3. Are the different proposals answers to to (2).

4. Are the different proposals things that need to be pursued in the IETF.
And if so  in what classification.

Cheers
Lucas

On Sat, 30 Oct 2021, 20:43 Alan Frindell, <afrind=[email-masked]>
wrote:

> Hi Spencer, thanks for helping drive the effort forward here.  I have no
> objections to organizing the discussions as you suggest.
>
>
>
> As for a side meeting, I definitely think we should have one (or even
> two).  I don’t mind helping to organize it like last time, though if
> someone else wants to that’s ok with me.
>
>
>
> -Alan
>
>
>
> *From: *Moq <[email-masked]> on behalf of Spencer Dawkins at IETF <
> [email-masked]>
> *Date: *Saturday, October 30, 2021 at 10:17 AM
> *To: *MOQ Mailing List <[email-masked]>
> *Subject: *[Moq] Two questions about how to move MOQ forward
>
>
>
> Dear MOQ fans,
>
>
>
> --
> Moq mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/moq
>

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 30 Oct 2021 19:27:25 -0700

Lucas said:

"Are folks aligned on a single problem..."

[BA] I'm aware of at least 4 different problems under discussion:

1. Video ingestion, oriented toward quality (e.g. RUSH)
2. Media streaming
3. Ultra-low latency streaming
4. Realtime Communications (e.g. RTP over QUIC)

These problems seem to have quite different requirements.

Problem 1 involves RTMP replacement for video ingestion, in situations
where video quality is valued over the lowest possible latency. This seems
like it could be implemented either with WebTransport or alternatively
directly over QUIC, using reliable streams and the congestion control
mechanisms in current QUIC implementations (e.g. loss-based algorithms).
This is the problem that RUSH seems to be solving.

Problem 2 is about improving the user experience in media streaming by
improving video quality or reducing video freezes. Lowest possible latency
is not a requirement. Research seems to show that allowing keyframes and
discardable frames to be transmitted on different streams helps reduce
video freezes by preventing keyframes being blocked by retransmissions of
discardable frames.  This use case seems like it should be implementable
over QUIC, WebTransport or possibly even HTTP/3.

Problem 3 is oriented toward use cases like game streaming or remote
desktop so it requires minimal latency.  Today solutions to these use cases
are frequently based on WebRTC (either RTCDataChannel or RTP or both),
since low latency is a requirement and P2P operation can be desirable (e.g.
to be able to support remote desktop or game streaming not just from the
cloud but from your own computer or games console).

As a result, if QUIC were to be put forward as a solution, it would
probably be with the understanding that the QUIC congestion control
algorithm would be replaced with an algorithm more appropriate for realtime
communications. Also, P2P operation might be required.

Problem 4 is a current research topic. It seems to require tight
integration with QUIC, and therefore is not easily implemented over
WebTransport.

---

From: Ian Swett <[email-masked]>
Date: Sun, 31 Oct 2021 05:39:47 -0400

IMO these are 4 variations on a single problem, which is 'Semi-reliable
transfer of media with one or more knobs to tune between favoring higher
quality and lower latency.'

I don't see a particular reason to make a protocol ingest only, so the
question to me is can we fit the range of requirements we have with a
single protocol.  I tend to think it should be possible, but maybe there
are technical or legacy reasons(ie: compatibility with existing systems)
that make it impractical.

Integration with Congestion Control and the ability to run over
WebTransport are important features and challenges.  I tend to think of
those changing the deployment more than the protocol.

Ian

On Sat, Oct 30, 2021 at 10:27 PM Bernard Aboba <[email-masked]>
wrote:

>> 1. Does anything here depend on the agendas of other WG meeting at 112?
>> (I think the answer is no but will stand to be corrected ). The answer here
>> helps scheduling.
>>
>> 4. Are the different proposals things that need to be pursued in the
>> IETF. And if so  in what classification.
>>
>> Cheers
>> Lucas
>>
>>> *From: *Moq <[email-masked]> on behalf of Spencer Dawkins at IETF
>>> <[email-masked]>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sun, 31 Oct 2021 11:26:54 +0100

I really doubt that we will be able to find a single solution that covers
all the use cases and requirement variants, which extends the ones
proposed by Bernard.

For the use cases we have:
- VOD streaming (HLS/DASH replacement)
- Live streaming (LL HLS replacement)
- Live ingest (RTMP replacement)
- Real time conferencing (WebRTC replacement)
- Real time streaming ingest (WHIP replacement)
- Interactive streaming (a mix of the above)

Seems unlikely that we are going to be able to define a single protocol
that provides a good solution for all of them. Also, people definitely want
an RTP over QUIC variant, which I doubt will be an acceptable universal
solution for most people in this list. Moreover, RTP over QUIC should be
handed over to AVTCORE and MMUSIC once we have a clearer picture of what is
what we want.

There is also a traversal problem that is the interaction of the QUIC CC
with any BWE/CC that the transport over QUIC uses (rmcat for example) and
how it can be implemented with WebTransport.

Best regards
Sergio

El dom, 31 oct 2021 a las 10:40, Ian Swett (<ianswett=
[email-masked]>) escribió:

>>> On Sat, 30 Oct 2021, 20:43 Alan Frindell, <afrind=
>>> [email-masked]> wrote:
>>>
>>>> Hi Spencer, thanks for helping drive the effort forward here.  I have
>>>> no objections to organizing the discussions as you suggest.
>>>>
>>>>
>>>>
>>>> *From: *Moq <[email-masked]> on behalf of Spencer Dawkins at
>>>> IETF <[email-masked]>
>>>> It looks like we're starting the discussion(s) on this mailing list
>>>> that many of us were hoping for. Two questions present themselves to me.
>>>>
>>>>    - Would anyone object to me trying to organize the discussions
>>>>    we're having on the mailing list now (for instance, "one email thread per

---

From: "Ali C. Begen" <[email-masked]>
Date: Sun, 31 Oct 2021 13:37:21 +0300

> On Oct 31, 2021, at 1:26 PM, Sergio Garcia Murillo <[email-masked]> wrote:
> 

I strongly object to this list of goals. “Replacement” is certainly not a goal maybe except a few. RTMP might be replaced with something else and as a matter of fact, we already have a number of deployed alternatives out there. Yes, they are TCP based but are working just fine with the existing deployments. Another ingest option over QUIC might be desirable for managing the latency a bit better than TCP, but a lossy ingest is not an option for paid or premium content. 

As for the goal of replacing VOD or live streaming (DASH, HLS or their LL variants), this is pretty pointless. If you have a hammer, not everything is a nail so please don’t assume that we want to apply QUIC on everything out there. DASH or HLS just work fine over H3 (and that is by design).

-acbegen

---

From: "Ali C. Begen" <[email-masked]>
Date: Sun, 31 Oct 2021 13:42:11 +0300

> On Oct 31, 2021, at 12:39 PM, Ian Swett <ianswett=[email-masked]> wrote:
> 
> IMO these are 4 variations on a single problem, which is 'Semi-reliable transfer of media with one or more knobs to tune between favoring higher quality and lower latency.'

Lets call it “Variable-reliability” as full reliability is still a requirement unless you are doing user generated content or conferencing type of transfer.  

> I don't see a particular reason to make a protocol ingest only, so the question to me is can we fit the range of requirements we have with a single protocol.

I tend to agree here, though, not everything that can just work over H3 needs to be modified just because we can. There is a fine line between removing the layers vs. cross-layer design vs. the KISS principle.

>  I tend to think it should be possible, but maybe there are technical or legacy reasons(ie: compatibility with existing systems) that make it impractical.

---

From: Ian Swett <[email-masked]>
Date: Sun, 31 Oct 2021 07:09:49 -0400

I should have said that I don't want to replace DASH over HTTP/3.  As you
said, that works quite well for the majority of use cases and it's easy to
put onto a CDN.

However, there are use cases where DASH is used today, such as for
lower-latency live streaming, where it creates some challenges and
overhead.  It works, but using HTTP is hurting more than it's helping.

Ian

On Sun, Oct 31, 2021 at 6:42 AM Ali C. Begen <ali.begen=
[email-masked]> wrote:

> Lets call it “Variable-reliability” as full reliability is still a
> requirement unless you are doing user generated content or conferencing
> type of transfer.
>
> single protocol.
> I tend to agree here, though, not everything that can just work over H3
> needs to be modified just because we can. There is a fine line between
> removing the layers vs. cross-layer design vs. the KISS principle.
>
> >  I tend to think it should be possible, but maybe there are technical or
> legacy reasons(ie: compatibility with existing systems) that make it
> impractical.
>
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sun, 31 Oct 2021 12:15:57 +0100

s/replacement/alternative to/

I have not mentioned if they are desired targets or not, but are all the
alternatives we have on the table right now.  Clarifying the scope about
what uses cases we want to cover should be the first step.

Regarding that,  HLS LL alternative seems to be clearly in the scope of the
semi-reliable quality focus variant.

Best regards
Sergio

El dom., 31 oct. 2021 11:37, Ali C. Begen <[email-masked]>
escribió:

> I strongly object to this list of goals. “Replacement” is certainly not a
> goal maybe except a few. RTMP might be replaced with something else and as
> a matter of fact, we already have a number of deployed alternatives out
> there. Yes, they are TCP based but are working just fine with the existing
> deployments. Another ingest option over QUIC might be desirable for
> managing the latency a bit better than TCP, but a lossy ingest is not an
> option for paid or premium content.
>
> As for the goal of replacing VOD or live streaming (DASH, HLS or their LL
> variants), this is pretty pointless. If you have a hammer, not everything
> is a nail so please don’t assume that we want to apply QUIC on everything
> out there. DASH or HLS just work fine over H3 (and that is by design).
>
> -acbegen

---

From: "Ali C. Begen" <[email-masked]>
Date: Sun, 31 Oct 2021 16:21:05 +0300

> On Oct 31, 2021, at 2:09 PM, Ian Swett <ianswett=[email-masked]> wrote:
> 
> However, there are use cases where DASH is used today, such as for lower-latency live streaming, where it creates some challenges and overhead.  It works, but using HTTP is hurting more than it's helping.

Just to make sure we are on the same page, what challenges do you think DASH has for low-latency live streaming? Or what overhead does HTTP create in that case? For low-latency HLS, there are several server/CDN related issues people have reported already and despite the LL-HLS improvements, some issue still exist. I agree with that but I don’t see the same issues applying to DASH’s low latency.

---

From: "Ali C. Begen" <[email-masked]>
Date: Sun, 31 Oct 2021 16:22:15 +0300

> On Oct 31, 2021, at 2:15 PM, Sergio Garcia Murillo <[email-masked]> wrote:
> 
> Regarding that,  HLS LL alternative seems to be clearly in the scope of the semi-reliable quality focus variant.  

Can you explain this because it is not clear to me at ll?

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sun, 31 Oct 2021 14:32:43 +0100

Because a semi reliable version focused on quality will provide a similar
experience to hls ll in terms of latency and quality.

Anyway,  given said that, the work within this mailing list should not be
about comparing protocols, or stating how the quic variants are better. I
am just using them as examples for agreeing on the scope.

---

From: "Ali C. Begen" <[email-masked]>
Date: Sun, 31 Oct 2021 17:09:17 +0300

> On Oct 31, 2021, at 4:32 PM, Sergio Garcia Murillo <[email-masked]> wrote:
> 
> Because a semi reliable version focused on quality will provide a similar experience to hls ll in terms of latency and quality.

If it is a similar experience in terms of latency and quality, how can it be any better (or different) than the current one? I think what you are trying to say is that at low latency scenarios, you can selectively drop some media frames hoping that the viewer will not be aware of the dropped frames and at the same time, you may stall less. If so, this is a 30-year old debate and everybody has a view on this. These tricks are naturally a good fit for interactive type of applications but I don’t agree with a statement that implies we can equally use them in streaming applications at the same scale we have today with simpler designs like DASH or HLS (the servers only respond to the requests and dont mess with the data).

> Anyway,  given said that, the work within this mailing list should not be about comparing protocols, or stating how the quic variants are better. I am just using them as examples for agreeing on the scope.

I am not disagreeing quic can be more efficient and/or faster than TCP. It should normally be as it has more flexibility. There is tons of data that shows that. DASH or HLS over H3 may also perform better than their counterparts over H2 or HTTP/1.1. There is already some preliminary data on that, too. 

Sending media over QUIC or putting the media into RTP and then sending over QUIC are utterly different things than sending media over H3 that runs over QUIC.

I see people who would like to do the first or the second, which are fine goals. Studying the third and documenting how it can be improved is also a very fine goal. The second one belongs to AVT and I am not sure whether the third one deserves a new WG (MOPS is at least a good place to start working on that). So, to me, the missing piece is a place to do the first one (media over QUIC) and my impression is this is more or less what the RUSH folks asked for.

We really should not try putting everything into one pot here.

-acbegen

> 
> 
> El dom., 31 oct. 2021 14:22, Ali C. Begen <[email-masked]> escribió:
> 
>

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 31 Oct 2021 07:30:43 -0700

Ali said:

"If it is a similar experience in terms of latency and quality, how can it
be any better (or different) than the current one?"

[BA] Here is one of the papers that covers use of QUIC in streaming:
The QUIC Fix for Optimal Video Streaming (arxiv.org)
<https://arxiv.org/pdf/1809.10270v1.pdf>

"I think what you are trying to say is that at low latency scenarios, you
can selectively drop some media frames hoping that the viewer will not be
aware of the dropped frames and at the same time, you may stall less""

[BA] Yes, the paper did seem to show a decline in video stalls.

On Sun, Oct 31, 2021 at 7:09 AM Ali C. Begen <[email-masked]>
wrote:

> > Because a semi reliable version focused on quality will provide a
> similar experience to hls ll in terms of latency and quality.
>
> If it is a similar experience in terms of latency and quality, how can it
> be any better (or different) than the current one? I think what you are
> trying to say is that at low latency scenarios, you can selectively drop
> some media frames hoping that the viewer will not be aware of the dropped
> frames and at the same time, you may stall less. If so, this is a 30-year
> old debate and everybody has a view on this. These tricks are naturally a
> good fit for interactive type of applications but I don’t agree with a
> statement that implies we can equally use them in streaming applications at
> the same scale we have today with simpler designs like DASH or HLS (the
> servers only respond to the requests and dont mess with the data).
>
> > Anyway,  given said that, the work within this mailing list should not
> be about comparing protocols, or stating how the quic variants are better.
> I am just using them as examples for agreeing on the scope.
>
> I am not disagreeing quic can be more efficient and/or faster than TCP. It
> should normally be as it has more flexibility. There is tons of data that
> shows that. DASH or HLS over H3 may also perform better than their
> counterparts over H2 or HTTP/1.1. There is already some preliminary data on
> that, too.
>
> Sending media over QUIC or putting the media into RTP and then sending
> over QUIC are utterly different things than sending media over H3 that runs
> over QUIC.
>
> I see people who would like to do the first or the second, which are fine
> goals. Studying the third and documenting how it can be improved is also a
> very fine goal. The second one belongs to AVT and I am not sure whether the
> third one deserves a new WG (MOPS is at least a good place to start working
> on that). So, to me, the missing piece is a place to do the first one
> (media over QUIC) and my impression is this is more or less what the RUSH
> folks asked for.
>
> > > Regarding that,  HLS LL alternative seems to be clearly in the scope
> of the semi-reliable quality focus variant.
> >

---

From: "Ali C. Begen" <[email-masked]>
Date: Sun, 31 Oct 2021 18:21:00 +0300

Thanks. Indeed there are many streaming with quic papers out there (i have
a few of my own). But just like i said before, to get that partial
reliability you need to handle media frames not group of frames or
fragments or segments. Once you start going down that hole, it is all a
different story and the use of http cdns goes out of the window. If you are
sending the same media to millions, this matters.

You probably remember RTSP better than i do. RTSP  or initial 3gpp mbs
solutions all considered media delivery with partial reliability (and yes
over udp not quic but the same argument still holds). And tell me who uses
RTSP at the same scale as http streaming today.

Again, i am all for studying dash/hls over h3 but that seems the least
popular topic on this mailing list :)

On Sun, Oct 31, 2021 at 5:30 PM Bernard Aboba <[email-masked]>
wrote:

>> I am not disagreeing quic can be more efficient and/or faster than TCP.
>> It should normally be as it has more flexibility. There is tons of data
>> that shows that. DASH or HLS over H3 may also perform better than their
-acbegen
Using iThumbs

---

From: Christian Huitema <[email-masked]>
Date: Sun, 31 Oct 2021 08:41:04 -0700

> communications. Also, P2P operation might be required.

First, maybe just a nit, but there is not a single one "QUIC congestion 
control". There is a variant of TCP-RENO described in RFC 9002, but 
different implementations have used different algorithms. Both Cubic and 
BBR are widely deployed. Some implementations let the application select 
the algorithms from a menu, or even provide a plug-in API for selecting 
an application provided algorithm. Remember that QUIC is designed as an 
"in app" protocol, and that the application has a lot more flexibility 
than with an "in kernel" protocol.

The issue goes in fact beyond congestion control to include multiplexing 
and scheduling. Suppose an application carrying a mix of media, some 
real-time in nature and some not. For example, a conference application 
might have audio and video as well as document sharing. At least in 
theory, transporting those as a mix of QUIC streams and QUIC datagrams 
allow the application to manage allocation of the transport resource, 
and for example reduce video quality when pushing a copy of a document 
is more important, or vice-versa. In practice, that can easily go wrong. 
Which is why it might be good to share experience and suggestions...

-- Christian Huitema