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

[Joerg Ott <[e-mail]>]

Hi Spencer, Roman,

> On Sun, May 22, 2022 at 11:49 PM Roman Shpount <[e-mail] 
> <mailto:[e-mail]>> 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
>     <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.

QUIC is defined to run over UDP, so a registration of TCP/QUIC/RTP/AVPF
would not be useful.

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

Right.

For RTP, 'falling back' be negotiated out of band by something like ICE.
But you would only fall back to connectivity options (and list those in
the first place) that are actually implementable.

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

Or TCP/TLS/RTP/SAVPF or DTLS/RTP if just QUIC is the problem.  Right.

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

Nothing, I would say.

Best,
Jörg


> 
> 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
>     <[e-mail]
>     <mailto:[e-mail]>> 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
>         <[e-mail]
>         <mailto:[e-mail]>> wrote:
> 
>             Dear AVTCORE,
> 
>             I've had an open PR in
>             https://github.com/SpencerDawkins/sdp-rtp-quic/pull/9
>             <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
>             <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
>                 <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
>                   o forward the RTP payload using RTP/AVPF (where
>                     the outgoing AVPF matches the incoming AVPF), or
>                   o 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 wasonly 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
>         <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
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/avt
>         <https://www.ietf.org/mailman/listinfo/avt>
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt