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

[Suhas Nandakumar <[e-mail]>]

On Mon, Nov 8, 2021 at 8:35 PM Justin Uberti <[e-mail]>
wrote:

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

+1 on QUIC's state back then. As a person who attempted to prototype the
RIPT over  QUIC, work back then, I wish there was DATAGRAM support in the
stack (and more matured) and also a way to bring in media recovery aspects
at the application space. We are far off from where we were back then.



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