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

Nils,

On Mon, Nov 8, 2021 at 12:55 PM Nils Ohlmeier <nils.ohlmeier@8x8.com> wrote:

> Hi,
>
> On Nov 8, 2021, at 09:38, Ian Swett <ianswett=40google.com@dmarc.ietf.org>
> wrote:
> 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.
>
> Yes fully agreed. I think that is why lots of people are interested in
> WebTransport, because it could result in some improvements in these areas.
>
>
>    - 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.
>
> This one keeps popping up. But so far all I have heard were some hand wavy
> hopes for improvements. It would be really helpful to have a list of things
> which don’t work in WebRTC to see if switching things over to QUIC could
> really fix/improve these.
>
> One aspect is that WebRTC was specifically designed to be a P2P solution.
> Which I understand is a disadvantage for certain use cases.
> Maybe all of this boils down to not calling this WebRTC over QUIC, which
> brings a lot of expectations with it, but name it different like QUIC RTC
> or something like that.
>

It's my opinion that part of what we're doing is taking terms that don't
map directly to work in the IETF, and translating them into words that do.

You have this (IMO) EXACTLY right. I want to understand if there is a
difference between the way (for instance) SIP uses RTP, and the way WebRTC
uses RTP, that would have an effect on what we write in an "RTP
encapsulated in QUIC" draft(*). We'll get to that point faster if we don't
talk about "WebRTC over QUIC".

Best,

Spencer

 (*) I do understand that WebRTC does have specific requirements for AVP
profiles, congestion behavior, etc. But talking about "RTP over QUIC" would
still help us understand what impact those requirements would have on our
work.

> 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.
>
>
> Agreed.
>
> Cheers
>   Nils
>
>
> Thanks, Ian
>
> On Mon, Nov 8, 2021 at 7:13 AM Spencer Dawkins at IETF <
> spencerdawkins.ietf@gmail.com> 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 <
>> spencerdawkins.ietf@gmail.com> 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
>> Moq@ietf.org
>> https://www.ietf.org/mailman/listinfo/moq
>>
> --
> Moq mailing list
> Moq@ietf.org
> https://www.ietf.org/mailman/listinfo/moq
>
>
>