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

[Lucas Pardue <[e-mail]>]

Hey Joerg,

Thanks for working through that with me and I think we're aligned. The ALPN
codespace is wide, I think we have room to come up with some type of new
value that is clear and expressive for the various needs.

Something to to consider also, an approach that has worked well in the past
for HTTP/2 and HTTP/3.  Encode a draft version identifier in the ALPN
itself, this allows for endpoints to overcome  breaking changes to the wire
format while things are evolving.

Cheers
Lucas

On Mon, 6 Jun 2022, 23:41 Joerg Ott, <[e-mail]> wrote:

> Hi Lukas,
>
> just to wrap this up:
>
> [snip]
>
> >     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.
>
> Ok, I wasn't much aware of the ALPN use outside the security handshake
> and hence considered this to be implied.
>
> I suppose with this correct interpretation we are in agreement.  Should
> not change anything else but confirm that we will need to have a
> separate registration for media-over-quic (as we cannot reuse 'webrtc'
> which assumes SRTP over DTLS IIRC).
>
> >     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.
>
> Agreed.  As I noted above, I wasn't aware of the binding to a specific
> security mechanism, so would certainly not suggest a reinterpretation
> but do a clean new registration.
>
> > 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.
>
> Cheers,
> Jörg