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

[Justin Uberti <[e-mail]>]

On Mon, Nov 8, 2021 at 7:20 PM Spencer Dawkins at IETF <
[e-mail]> wrote:

> Hi, Justin,
>
> On Mon, Nov 8, 2021 at 5:16 PM Justin Uberti <
> [e-mail]> wrote:
>
>>
>>
>> On Mon, Nov 8, 2021 at 2: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.
>>>
>>>
>> Yeah, this is the real meat of the discussion. At Google we built
>> something called QRTP that basically used QUIC as a secure RTP packet
>> transport, and I think this sort of thing would have a lot of value in
>> terms of making RTP apps easier to deploy. But you're not getting any new
>> functionality in the protocol, and you're still mostly in RTP-land (which
>> can be a positive or a negative depending on where you are coming from).
>>
>> IOW, we may need to choose between:
>> 1) Adapting RTP to QUIC so that RTP can be sent to 'normal' QUIC servers,
>> making it easier to deploy RTP-based applications
>> 2) Building RTP-like things on top of QUIC (e.g., RUSH) so that you can
>> get basic realtime functionality without having to use RTP
>>
>> My own sentiment is that both may have value, especially if 2) is focused
>> on a different use case than traditional RTP. We tried a couple attempts at
>> 2) and eventually concluded we were simply rebuilding RTP with a new name,
>> which led to the final QRTP direction.
>>
>
> I'm really glad that you're contributing to this discussion.
>
> I'm remembering the "media over HTTP" aspects of the RIPT BOF (
> https://datatracker.ietf.org/group/ript/documents/) that seemed to
> complicate life enormously for RIPT. I know you presented at that BOF - do
> you think doing media over QUIC is going to avoid most of the problems Mark
> Nottingham was worried about with RIPT?
>

I think two things are different this time around.
1) RIPT was trying to replace a lot of things - SIP, SDP, RTP (and possibly
more). Ultimately Jonathan was more interested in replacing the call setup
side of things (i.e., trunking) and I was more interested in replacing the
wire protocol, and I came to the understanding that we should tackle these
efforts separately. IOW, the wire protocol will be a real challenge, but I
think we can take this on if we don't let our scope go much beyond that.
2) QUIC was less mature then. Mark was reluctant to start looking at lossy
QUIC, IIRC, while QUIC itself was still a moving target. This is no longer
the case.

So I'm still bullish here. But before we jump into things it would be good
to make sure we're aligned on goals, since I'm not sure we all mean the
same thing when we say media-over-QUIC.

Justin