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

[Roman Shpount <[e-mail]>]

Hi Spencer,

I wanted to see if my explanation made any sense or if you have any
additional questions.

Best,
_____________
Roman Shpount


On Sun, Jun 26, 2022 at 1:17 AM Roman Shpount <[e-mail]> wrote:

> Hi Spencer,
>
> I will try to explain this again. What you are missing here is ICE-TCP
> (RFC 6544).
>
> Let's say a browser generates an offer. It would look something like this
> (I am skipping a bunch of attributes here, but this should be enough to
> convey the point):
> m=audio 55493 UDP/QUIC/RTP/AVPF 111 63 103 104 9 0 8 106 105 13 110 112
> 113 126
> c=IN IP4 192.168.80.1
> a=candidate:88276966 1 udp 2122260223 192.168.80.1 55493 typ host
> generation 0 network-id 2
> a=candidate:227749246 1 udp 2122194687 192.168.86.29 55494 typ host
> generation 0 network-id 1 network-cost 10
> a=candidate:1270940438 1 tcp 1518280447 192.168.80.1 9 typ host tcptype
> active generation 0 network-id 2
> a=candidate:1125175694 1 tcp 1518214911 192.168.86.29 9 typ host tcptype
> active generation 0 network-id 1 network-cost 10
>
> What we have here are two TCP candidates. The only protocol used there is
> the same one used over UDP, except with framing defined in RFC4571. It
> cannot be anything else since ICE can switch between any of those
> candidates during the nomination process, and communications should
> continue. It is not unusual for the first one or two packets to be
> delivered over TCP and subsequent packets over UDP. It cannot happen if the
> switch is between RTP-over-QUIC and DTLS-RTP. Furthermore, there is no way
> to define a switch between two unrelated protocols based on the type of ICE
> candidate used.
>
> Now, let's say the client is behind the UDP-restricted network. This means
> one of the TCP candidates gets nominated. Only the TCP candidate is left if
> another offer is sent after the nomination. This means the offer will look
> like this:
> m=audio 9 TCP/QUIC/RTP/AVPF 111 63 103 104 9 0 8 106 105 13 110 112 113 126
> c=IN IP4 192.168.80.1
> a=candidate:1270940438 1 tcp 1518280447 192.168.80.1 9 typ host tcptype
> active generation 0 network-id 2
>
> You cannot use UDP/QUIC/RTP/AVPF since the connection is over TCP, not
> UDP. This is why you need to register this protocol name.
>
> I do not think any work needs to be done by the QUIC working group. No
> work was required for DTLS or SCTP. This is an ICE-specific issue and is
> quite different from a typical QUIC to HTTP/2 fallback.
>
> I hope this explains the issue. Otherwise, we can go into more detail
> during the IETF meeting.
>
> Best Regards,
> _____________
> Roman Shpount
>
>
> On Wed, Jun 22, 2022 at 5:57 PM Spencer Dawkins at IETF <
> [e-mail]> wrote:
>
>> Hi, Roman,
>>
>> On Sun, May 22, 2022 at 11:49 PM Roman Shpount <[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 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 <
>>> [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]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/avt
>>>>
>>>