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

[Joerg Ott <[e-mail]>]

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

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.

We do not expect a particular QUIC library to infer any semantics or
protocol behavior from the ALPN used.

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


On 01.06.22 00:14, David Schinazi wrote:
> Understood. However this "tight integration" does not impact the choice 
> of ALPN. There's nothing preventing a higher layer protocol from 
> reaching into the depths of its underlying transport, no matter what 
> state of affairs might be prefered by OSI :-)
> 
> On Tue, May 31, 2022 at 3:08 PM Bernard Aboba <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     David said:
> 
>     "I think HTTP/3 vs P2P is a false dichotomy, there's nothing
>     preventing a browser from implementing a QUIC server stack and an
>     HTTP/3 server stack."
> 
>     [BA] Correct - but draft-engelbart-rtp-over-quic seems to be
>     assuming "tight integration" between QUIC and the RTP stack (e.g. so
>     that QUIC ACK info can be used rather than RTCP messages). The
>     WebTransport API (regardless of what protocol might run underneath)
>     doesn't provide that ACK info because in a browser an ACK at the
>     QUIC layer wouldn't necessarily imply reception by the application.
> 
>     On Tue, May 31, 2022 at 5:53 PM David Schinazi
>     <[e-mail] <mailto:[e-mail]>> wrote:
> 
>         I think HTTP/3 vs P2P is a false dichotomy, there's nothing
>         preventing a browser from implementing a QUIC server stack and
>         an HTTP/3 server stack.
>         David
> 
>         On Tue, May 31, 2022 at 2:49 PM Bernard Aboba
>         <[e-mail] <mailto:[e-mail]>> wrote:
> 
>             David said:
> 
>             "The considerations I wrote that Bernard forwarded above
>             applied to any use of QUIC, be it client-to-server or p2p,
>             as QUIC does not differentiate between the two. As Lucas
>             points out, if you want to use QUIC you have to pick one
>             ALPN per connection."
> 
>             [BA] Yes, there are ALPN considerations here.
> 
>             There are also some other considerations that could differ
>             between client-to-server (WebTransport) and P2P QUIC
>             scenario. The RTP over P2P QUIC use case enables tighter
>             integration with the QUIC stack than would RTP over
>             WebTransport, where WebTransport is natively implemented in
>             the browser and RTP is provided in a Javascript or WASM
>             library.  In the RTP over WebTransport case, QUIC internals
>             (such as ACK info) might not be easily accessible, which
>             might make it necessary to duplicate info at the QUIC and
>             RTCP layers.
> 
>             David said:
> 
>             "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
> 
>             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."
> 
>             [BA] Within WebRTC, we have seen most applications choose to
>             multiplex everything (STUN/TURN, DTLS, RTP, RTCP, audio,
>             video, data) on a single port. So I suspect there will be
>             interest in doing the same thing over QUIC (regardless of
>             whether we are talking about P2P QUIC or WebTransport).
> 
>             There is a debate about how best to multiplex audio/video
>             with data exchange (e.g. whether it is best to use two QUIC
>             connections multiplexed by connection ID, possibly with
>             distinct CC algorithms, or a single QUIC connection with one
>             algorithm).  Having a single connection with an appropriate
>             congestion control algorithms (e.g. SCReaM or Google CC) can
>             provide greater fairness between file transfers and media.
>             This would make a file transfer done simultaneously with
>             audio/video take longer, but that's probably what you want,
>             as opposed to having the file transfer using NewReno or BBR
>             starving media using a low-latency CC algorithm.
> 
>             That seems to argue for defining RTP-over-HTTP/3 as well as
>             RTP over P2P QUIC.  In the RTP-over-HTTP/3 case, RTP would
>             be a JS library running in a browser over WebTransport and
>             optimizations that might be
>             possible with RTP over P2P QUIC (such as use of QUIC ACKs
>             instead of RTP NACK) might not be possible.
> 
>             In either scenario, there is also the question of how you
>             distinguish data from RTP/RTCP that arrives in a
>             WebTransport Datagram or Message/Stream. One way to do this
>             (for WebTransport or P2P QUIC) might be by looking at the
>             first byte.
> 
>             On Tue, May 31, 2022 at 4:44 PM David Schinazi
>             <[e-mail] <mailto:[e-mail]>>
>             wrote:
> 
>                 [ replacing my email address, as I left Apple more than
>                 3 years ago :-) ]
> 
>                 The considerations I wrote that Bernard forwarded above
>                 applied to any use of QUIC, be it client-to-server or
>                 p2p, as QUIC does not differentiate between the two. As
>                 Lucas points out, if you want to use QUIC you have to
>                 pick one ALPN per connection.
> 
>                 David
> 
>                 On Wed, May 25, 2022 at 12:33 PM Lucas Pardue
>                 <[e-mail]
>                 <mailto:[e-mail]>> wrote:
> 
>                     Hi Joerg, David,
> 
>                     I don't have a strong stake in the upper L7 matters
>                     but FWIW
> 
>                     RFC 9000 section 7 says: "The cryptographic
>                     handshake MUST provide .. authenticated negotiation
>                     of an application protocol (TLS uses
>                     Application-Layer Protocol Negotiation (ALPN) [ALPN
>                     <https://www.rfc-editor.org/rfc/rfc9000.html#ALPN>]
>                     for this purpose)"
>                     RFC 9001 section 8.1 says: "QUIC requires that the
>                     cryptographic handshake provide authenticated
>                     protocol negotiation. TLS uses Application-Layer
>                     Protocol Negotiation [ALPN] to select an application
>                     protocol. Unless another mechanism is used for
>                     agreeing on an application protocol, endpoints MUST
>                     use ALPN for this purpose."
> 
>                     The QUIC implementations I'm familiar with will
>                     enforce these requirements. So for anyone writing an
>                     application mapping that expects interop, that
>                     really do need to explicitly define _an_ ALPN
>                     identifier OR state what exactly the alternative
>                     mechanism is.
> 
>                     Cheers,
>                     Lucas
> 
>                     _______________________________________________
>                     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] <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