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

[Lucas Pardue <[e-mail]>]

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

>