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

[Spencer Dawkins at IETF <[e-mail]>]

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?

Best,

Spencer