Re: [AVTCORE] Review of draft-engelbart-rtp-over-quic (David Schinazi)

[David Schinazi <[e-mail]>]

I just realized why there is a disconnect here: I misunderstood something
initially from Bernard's request and Bernard only forwarded part of my
initial message so it didn't become apparent. I'm pasting the initial
exchange further down.
Based on Bernard's question, I thought that draft-engelbart-rtp-over-quic
was trying to multiplex RTP and WebTransport over the same QUIC connection.
That's my mistake, the draft isn't trying to do that. That wouldn't work
because of the ALPN points made above, but that's not what you're trying to
do in the first place.
If instead, you want to run RTP over WebTransport, then that's possible
from a protocol perspective, but you'd need an implementation of
WebTransport that would provide you more detailed information than what is
provided to Javascript today.

Apologies for the confusion,
David

=========

On Sun, May 22, 2022 at 1:30 PM Bernard Aboba <[e-mail]>
wrote:

> [BA] Thank you for your review of RFC 7983bis.
>

[DS] Happy to help!

[BA] Could you have a brief look at  RTP over QUIC (ietf.org)
> <https://www.ietf.org/id/draft-engelbart-rtp-over-quic-03.html>? This
> draft is going to be considered for adoption in AVTCORE WG, and it would be
> desirable for RTP over QUIC to also be usable with WebTransport.
>

[DS] I quickly skimmed this and I think the authors misunderstand a
fundamental point: you cannot multiplex two separate application protocols
over one QUIC connection. During the QUIC handshake, an ALPN token is
negotiated and that protocol is the only one in use for the lifetime of
this connection. If you want to simultaneously run RTP-over-QUIC and
WebTransport, you have two options:
1) define RTP-over-HTTP/3. That way you have one QUIC connection with
ALPN=h3 and then you can run as many RTP or WebTransport sessions on top.
2) use two distinct QUIC connections, one for RTP and one for
WebTransport-over-HTTP/3. They can be on the same socket and demultiplexed
using the QUIC connection ID

[BA] Things that might be worth looking at include the use of the flow
> identifier (which they are assuming can be used by an application to
> differentiate RTP sessions as well as to differentiate data from media).
>

[DS] If you go the RTP-over-QUIC route, then the document that defines it
gets to define what the payload of datagram frames contains. They can
choose to use a flow identifier and can define its semantics to be whatever
they want. They can also skip flow identifiers and use something else
instead.

David

=========


On Thu, Jun 2, 2022 at 2:48 AM Lucas Pardue <[e-mail]>
wrote:

> Hi Joerg,
>
> Responding to one aspect in line:
>
>
> On Thu, 2 Jun 2022, 09:40 Joerg Ott, <[e-mail]> wrote:
>
>> [ oops, sorry, David, my Thunderbird autocompletion seems to have too
>> good a memory :-) ]
>>
>> Let us try to disentangle this so that we don't accidentally talk past
>> each other.
>>
>> A quick note before I continue: the main point of the discussion right
>> now appears to be about multiplexing RTP and non-RTP sessions within a
>> single QUIC connection and what the implications of this would be.  We
>> don't feel strongly about going either way, we just try to understand
>> what is feasible and what is not.  And then write this down clearly in
>> line with what the WG wants.
>>
>> The main contention in this thread appears to be about if it would be
>> even possible to signal a mix of protocols on top of a single QUIC
>> connection because the ALPN would need to identify which protocol to
>> run on top.
>>
>> Now:
>>
>> It is well understood that an ALPN is needed to identify a connection's
>> target "instance" and thus indicate the protocol to be carried on top,
>> be it h3 or something else.
>>
>
> I'd disagree a little with that interpretation. The ALPN token, by my
> operating knowledge, denotes the specific pairing of an application
> protocol bound to a secure protocol. For instance, there isn't a generic
> "http" ALPN that can be used across TLS and QUIC, but rather each version
> of HTTP describes a wire format and how it is expected to be mapped on to
> the layer beneath it. That gives us "h2" and "h3", that are used
> unambiguously.
>
> One might argue that it should be obvious what the app:security binding is
> at the point when the ALPN extension is exchanged - the security handshake.
> However, we've unfortunately decided in the IETF to use ALPN tokens in
> other places outside the handshake, such as the Alt-Svc header, the SVCB
> [2], the ALPN header [3], and possibly more.
>
>
>> The reason I brought up the -- admittedly simplistic -- p2p vs. c-s
>> dichotomy is that, in client-server interactions, we signal the protocol
>> to be used with the initial contact to the server in the first packet we
>> send.  That is, the semantics of the application protocol are derived
>> exclusively from the (IANA-registered or otherwise uniquely defined
>> ALPN).
>>
>> In contrast, in the p2p real-time multimedia case, we usually do have an
>> established signaling channel (SIP/SDP, HTTPS/SDP, whatever) via which
>> the two endpoint negotiate which transports they want to use and how to
>> use those.  That is, a complex SDP specification could clearly determine
>> how many QUIC (or other) connections to open and how to use those and it
>> could also define which ALPN to use for this very setup.  Whether this
>> would be ephemeral ALPN or whether one would define (just for the sake
>> of example) "rtp" (for a single RTP session), "rtp-mux" (for multiple
>> multiplexed RTP sessions), and "rtp-udp-mux" (for mixed RTP and non-RTP
>> sessions) would be up to be defined.  So, we could have well-defined
>> ALPNs if needed and we would of course expect the QUIC library to ensure
>> that ALPNs are checked and handled properly.  Your favorite quic_bind ()
>> would be parameterized accordingly.  It seems that RFC 8833 defines an
>> ALPN ("webrtc") for both RTP and data channels (in this case muxed in
>> DTLS records) as one example for multiple protocols on top.
>>
>
> QUIC requires authenticated application protocol negotiation. So even if
> you have an out of band mechanism like SDP, each QUIC handshake needs
> something in band to support that.
>
> For the reasons I set out above, I would discourage people from defining
> new generic ALPN tokens, or to overload an existing one to cover usage of
> an application protocol over QUIC. For example, avoid using "rtp", "webrtc"
> etc to mean anything special if it were seen in a QUIC handshake.
>
> Where we do agree though is that an ALPN token can be used to clearly
> express an application mapping over QUIC that allows multiple concurrent
> application protocols in the same QUIC connection. The document defining
> that ALPN token is then required to explain exactly how that wire format
> works.
>
>
>
>> We do not expect a particular QUIC library to infer any semantics or
>> protocol behavior from the ALPN used.
>>
>
> I agree here, a transport library has no business snooping on that.
>
>
>> I may be missing the obvious but this wouldn't seem to be at odds with
>> what both Lukas and you said.
>>
>> Finally about the tight integration: the draft doesn't assume but allows
>> such.  You may have an integrated design, you may have a very expressive
>> "API" to gain access to QUIC stats (as we are gradually describing in
>> more detail), or you may have a fairly standard QUIC library without
>> such access and do your own RTP/RTCP stats on top.
>>
>> Jörg
>>
>
>
> Cheers
> Lucas
>
> [1] https://www.rfc-editor.org/rfc/rfc7838.html
> [2]
> https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-10.html#section-7.1
> [3] https://datatracker.ietf.org/doc/html/rfc7639
>
>>