Re: [AVTCORE] Last question about AVP profiles for RTP over QUIC (was: Re: Registering AVP Profiles for RTP over QUIC)

Hi, Roman,

On Sun, May 22, 2022 at 11:49 PM Roman Shpount <roman@telurix.com> wrote:

> As the person who proposed this, I am for this.
>
> You would probably need to register TCP/QUIC/RTP/AVPF as well, which would
> be RTP over QUICK over TCP with RFC4571 framing. See
> https://datatracker.ietf.org/doc/html/rfc8841#section-8 for a similar
> definition for SCTP.
>

I've been thinking about this one for a while (see date on your reply, vs
date on my reply).

I may be dense, but I'm thinking that it would take (significant) work for
us to convince the QUIC working group to produce another QUIC binding,
based on TCP, rather than UDP, and that in the absence of such a protocol
revision, this isn't useful for the use cases people have been talking
about, so far.

Usually, when I've had conversations about "falling back to TCP", it's been
in an HTTP/3-QUIC context, where a client's UDP packets are being blocked
or severely rate-limited, so falling back to HTTP/2 (or even HTTP/1.1) over
TCP makes perfect sense.

If UDP/QUIC/RTP/AVPF is being blocked, wouldn't an RTP endpoint just
failover to TCP/RTP/SAVPF, the same way it would if a path was blocking UDP
packets today?

Can anyone help me understand what I'm missing here?

Best,

Spencer

> The main reason for this definition is ice-tcp support. If you do a
> session update once the ice-tcp candidate is nominated, the protocol in the
> m= line should match the protocol for the only remaining candidate,
> so TCP/QUIC/RTP/AVPF would be used.
>
> Best,
> _____________
> Roman Shpount
>
>
> On Sun, May 22, 2022 at 7:41 PM Spencer Dawkins at IETF <
> spencerdawkins.ietf@gmail.com> wrote:
>
>> So, we had a spirited discussion about a few things in this thread, but
>> I'd like to reset back to my original question.
>>
>> On Wed, May 11, 2022 at 3:46 PM Spencer Dawkins at IETF <
>> spencerdawkins.ietf@gmail.com> wrote:
>>
>>> Dear AVTCORE,
>>>
>>> I've had an open PR in
>>> https://github.com/SpencerDawkins/sdp-rtp-quic/pull/9 for a while,so I
>>> could get a sense of how AVT profiles are supposed to work, and I'd like to
>>> push on that now (with a virtual interim meeting coming up next week)..
>>>
>>> The high-level summary of discussion in
>>> https://github.com/SpencerDawkins/sdp-rtp-quic-issues/issues/5 (note
>>> that this discussion is in a different repo, because reasons) has been
>>> roughly,"what's the difference between QUIC/RTP/AVPF and QUIC/RTP/SAVPF"?
>>>
>>> The arguments about not registering secure AVP profiles involve
>>>
>>>    -  the computational overhead of double encryption for all packets,
>>>    plus
>>>    - the payload overhead of 10 bytes per packet since you have 2 HMACs.
>>>
>>> The arguments about registering secure AVP profiles seem to revolve
>>> around
>>>
>>>    - Minimizing the impact of added QUIC support in existing
>>>    implementations that are using /RTP/SAVPF now.
>>>    - QUIC encryption protects payloads between QUIC endpoints, but
>>>    there are many multi-endpoint RTP topologies (
>>>    https://www.rfc-editor.org/rfc/rfc7667 has about 50 pages of them),
>>>    and when a middlebox receives  QUIC/RTP/AVPF, it's not obvious whether the
>>>    middlebox should
>>>       - forward the RTP payload using  RTP/AVPF (where the outgoing
>>>       AVPF matches the incoming AVPF), or
>>>       - forward the RTP payload using RTP/SAVPF, where the outgoing
>>>       SRTP encryption matches the incoming QUIC
>>>
>>> It seems to me that there are three choices:
>>>
>>>    - Use only QUIC/RTP/AVPF, and and require middleboxes receiving
>>>    QUIC/RTP/AVPF traffic to always forward that traffic over RTP/SAVPF
>>>    - Use only QUIC/RTP/AVPF, and and require senders to signal
>>>    middleboxes whether they should forward that traffic over RTP/AVPF or
>>>    RTP/SAVPF
>>>    - Register both QUIC/RTP/AVPF and QUIC/RTP/SAVPF, and if you have to
>>>    do double encryption on the QUIC/RTP paths to get RTP/SAVPF on the other
>>>    side of a middlebox, too bad
>>>
>>> So, my questions are,
>>>
>>>    - What am I missing here?
>>>    - Are any of the choices I'm listing obviously the *BEST* choice?
>>>
>>> My recommendation for what I was registering now, in sdp-rtp-quic, in my
>> way-too-quick talk at the interim meeting last week, was that I was only
>> registering QUIC/RTP/AVPF (if we ever figure out what SAVP and SAVPF
>> mean when RTP is carried over QUIC, we can register them later).
>>
>> We didn't have time for Q&A after my talk, but in Jabber, this happened:
>>
>> 11:50:08 Roman Shpount It should be UDP/QUIC/RTP/AVPF
>> 11:50:26 Sergio Garcia Murillo +1 to UDP/QUIC/RTP/AVPF
>>
>>
>> So, we haven't talked about this, and if I'm making commits
>> to sdp-rtp-quic, I should ask about it now.
>>
>> After a quick spin through
>> https://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-parameters-2,
>> I think this is reasonable and correct.
>>
>> So, that would give me one proto registration for UDP/QUIC/RTP/AVPF.
>>
>> I'll make this change before IETF 114.
>>
>> Any obvious objections? Please reply here, if so.
>>
>> Best,
>>
>> Spencer
>>
>>
>>> Best,
>>>
>>> Spencer
>>>
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> avt@ietf.org
>> https://www.ietf.org/mailman/listinfo/avt
>>
>