Re: [Moq] Agenda topics for side meeting on Tuesday

[Bernard Aboba <[e-mail]>]

"One aspect is that WebRTC was specifically designed to be a P2P solution.
Which I understand is a disadvantage for certain use cases."

[BA] It turns out that several use cases (including Remote Desktop and Game
Streaming) aren't just client/server.  For example, while at home you may
want to remote the desktop of a machine at work in addition to potentially
being interested in a desktop in the cloud.  Similarly, you may be
interested in playing a game on a phone from your game console, not just
playing it from the cloud.

So it turns out that many developers of these use cases actually prefer P2P
APIs to client/server APIs, because the former allows them to handle both
P2P and client/server use cases with a single code base.  These are expert
developers, so they do not fear ICE.  They are now using the RTCDataChannel
API, and while they are potentially interested in migrating to P2P QUIC,
WebTransport is a difficult sell, because they'd still need RTCDataChannel
for P2P scenarios.

Luke said:

"For example, sending each frame as its own stream, which is how Facebook's
RUSH works."

[BA]  This is certainly a lot easier to implement with WebCodecs +
WebTransport.  Now that WebCodecs supports scalable video coding, you can
even vary transport reliability (e.g. maximum transmission time) based on
the type of frame being transmitted.  So far, people playing with this seem
to be getting good results, but I haven't seen a detailed performance
evaluation in challenging scenarios (e.g. high loss or variable RTT).

On Mon, Nov 8, 2021 at 5:17 PM Luke Curley <[e-mail]> wrote:

> Twitch is using WebTransport and QUIC streams for live video distribution
> (Warp). I gave a presentation at Demuxed about it recently (including
> plugging this ML) and would love to start the conversation here too. I've
> got a draft and I'm just working on getting approval to publish it now.
>
> I don't think there's a good way to map RTP to QUIC. It's tempting because
> there's a lot of standards behind RTP, but any approach involves disabling
> huge swaths of functionality on either front. QUIC and RTP have
> incompatible ideas on how to perform fragmentation, congestion control,
> flow control, reliability, feedback, etc. My project briefly used RTP over
> QUIC but we abandoned it when it became too cumbersome.
>
> There are some compelling ways to map live media to QUIC and fully
> utilizing QUIC's functionality. For example, sending each frame as its own
> stream, which is how Facebook's RUSH works. I think we have enough
> non-video people on this list that we should discuss how video works and
> what we're trying to accomplish, instead of focusing on how we can port RTP.
>
>
>
> On Mon, Nov 8, 2021, 1:05 PM Spencer Dawkins at IETF <
> [e-mail]> wrote:
>
>> So, full disclosure -
>>
>> On Mon, Nov 8, 2021 at 1:23 PM Suhas Nandakumar <[e-mail]>
>> wrote:
>>
>>>
>>>
>>> On Mon, Nov 8, 2021 at 10:11 AM Spencer Dawkins at IETF <
>>> [e-mail]> wrote:
>>>
>>>> Hi, Ian,
>>>>
>>>> On Mon, Nov 8, 2021 at 11:38 AM Ian Swett <[e-mail]> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I've looked at the following uses cases fairly closely for QUIC in the
>>>>> past.
>>>>>
>>>>>    - Live Video Ingestion - Existing protocols don't fully meet our
>>>>>    needs (ie: performance vs reliability, standardization, etc), and this is
>>>>>    becoming a real problem.
>>>>>    - Live Video Delivery - Currently we're pushing the edge of what
>>>>>    HTTP can do efficiently, including some non-standard extensions.  This is
>>>>>    also not optimized for QUIC or HTTP/3, which could improve performance.
>>>>>    - WebRTC over QUIC, ie: RTP over QUIC + Datachannels over QUIC -
>>>>>    There could be a number of benefits of WebRTC over QUIC.  A number of
>>>>>    people who were interested in this are now focused on WebTransport, but
>>>>>    there's still the matter of what you send over WebTransport, so I think
>>>>>    there's some work to be done in addition to finishing WebTransport.
>>>>>
>>>>>
>>>> Thanks for this - it's very helpful, and it will definitely be on the
>>>> list for tomorrow's meeting.
>>>>
>>>>
>>>>> As with QUIC, I see we have a number of different working groups
>>>>> different parts or applications could land in.  I worry that could cause
>>>>> fragmentation if each sub-domain solves their problem without collaborating
>>>>> closely with others.  I'm not sure if a new WG(ie: QUIC-style) is necessary
>>>>> here, but I do think caution should be taken to ensure we don't reinvent
>>>>> the wheel 3+ different ways.
>>>>>
>>>>
>>>> Yes, exactly. It's sad when three people working in isolation solve a
>>>> similar problem in three different ways that have to be implemented three
>>>> times, but it's doubly sad when they all show up in QUIC either asking for
>>>> advice on three similar solutions, or even proposing three similar but
>>>> incompatible extensions! 😈
>>>>
>>>
>>> One common theme that might needs addressing is : what sort of API knobs
>>> can be exposed by transport (QUIC) to help apps know about losses/recovery
>>> and influence the choice of congestion control . If some aspects of this
>>> can be done in a standard way, it would definitely help
>>> streaming/interactive use-cases.
>>>
>>
>> Yes, exactly (it's listed as a consideration in
>> https://www.rfc-editor.org/rfc/rfc9049.html#name-support-in-endpoint-protoco
>> .
>>
>> Having said that, I fully expect that we're going to end up with at least
>> some pain points that are outside the typical IETF working group's charter.
>> The ones I'm especially aware of, are
>>
>>    - The kind of tight integration between codec operation and awareness
>>    of path characteristics we've been talking about at length, in the thread
>>    Christian started at
>>    https://mailarchive.ietf.org/arch/msg/moq/jk9eDELqs_gyg1kSGAmhhzJ-_ts/.
>>    What I think is normal, is that we tend to have ICCRG looking at congestion
>>    control mechanisms (quoting today's ICCRG session) "until they're ready to
>>    come to the IETF. So I think this is worth pursuing, but chartering it in
>>    the IETF will probably be more complicated than adopting a draft i(say)
>>    encapsulating RTP in QUIC.
>>    - I'll say more about this in a reply to another note in this
>>    (increasingly awesome) thread, but there are things we've been talking
>>    about that are likely required in order to build a product, but aren't
>>    candidates for standardization, for various reasons.
>>
>> But I still think they're worth talking about during our meeting
>> tomorrow, because if we can agree on a strategy for them, we can take them
>> off the "media over QUIC" table without dropping them on the floor.
>>
>> Best,
>>
>> Spencer, who isn't even the MOQ list admin, and so is definitely not
>> running anything for the rest of the MOQ fans!
>>
>>
>>> Best,
>>>>
>>>> Spencer, who should be apologizing to Lucas for even thinking such a
>>>> thing!
>>>>
>>>>
>>>>>
>>>>> Thanks, Ian
>>>>>
>>>>> On Mon, Nov 8, 2021 at 7:13 AM Spencer Dawkins at IETF <
>>>>> [e-mail]> wrote:
>>>>>
>>>>>> So, three things I should say before the Tuesday side meeting.
>>>>>>
>>>>>> First - this side meeting will be under Notewell, because it's
>>>>>> focused on input to the IETF.
>>>>>>
>>>>>> Second - I'm planning to record the session, just so I can verify
>>>>>> what we said, so that I can produce decent minutes. If anyone objects,
>>>>>> please also volunteer to take excellent notes!
>>>>>>
>>>>>> Third - James and I are most familiar with the RTP over QUIC
>>>>>> proposals, but we recognize that there will be commonalities between
>>>>>> various proposals, so  we're perfectly happy to talk about other use cases
>>>>>> and requirement sets. So, letting us know what you're thinking about, as
>>>>>> requested below, will be super useful.
>>>>>>
>>>>>> Please Do The Right Thing.
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Spencer
>>>>>>
>>>>>> On Sun, Nov 7, 2021 at 12:36 PM Spencer Dawkins at IETF <
>>>>>> [e-mail]> wrote:
>>>>>>
>>>>>>> Dear MOQ fans,
>>>>>>>
>>>>>>> It's time to put together an agenda for the Tuesday meeting. I'd
>>>>>>> like for this meeting to be a working session, not a forum for
>>>>>>> presentations, so please keep that in mind.
>>>>>>>
>>>>>>> As a high-order bit, I think we've spent a lot of time thinking
>>>>>>> about use cases here, and I'd like to push down another level, and make
>>>>>>> sure we understand what the work for the IETF (and possibly for the IRTF)
>>>>>>> is.
>>>>>>>
>>>>>>> I know what the protocol work is for my use cases:
>>>>>>>
>>>>>>>    - Mapping RTP onto QUIC (many options exist, so picking one or
>>>>>>>    more would be helpful) This is squarely in scope for AVTCORE
>>>>>>>    - Mapping RTCP onto QUIC (which may be the same approach as used
>>>>>>>    for RTP, or may include things like using QUIC facilities instead of RTCP
>>>>>>>    facilities, where those QUIC facilities exist).. Again, this is squarely in
>>>>>>>    scope for AVTCORE
>>>>>>>    - SDP description for RTP/RTCP over QUIC. This is squarely in
>>>>>>>    scope for MMUSIC, as soon as we figure out the details in AVTCORE.
>>>>>>>
>>>>>>> What is the IETF/IRTF work for your use cases?
>>>>>>>
>>>>>> --
>>>>>> Moq mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/moq
>>>>>>
>>>>> --
>>>> Moq mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/moq
>>>>
>>> --
>> Moq mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/moq
>>
> --
> Moq mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/moq
>