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

[Joerg Ott <[e-mail]>]

 > Forwarded from David:

Thanks, let us quickly respond to this,.

 > 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:

Maybe we have indeed different system models in our minds, so it is
good to sort this out.  I consider there are at least two:

a) The good old client-server model with a well-defined address (port
    number + ALPN) to indicate a service you want to access.  That
    service then identifies the protocols and their use underneath.
    Roughly equivalent to registered port number to service mappings.

b) The peer-to-peer-style model inherent to the "connections" between
    two, say, VoIP or video or other WebRTC clients for their direct
    point-to-point connection.  Those used dynamic port numbers signaled
    in a control connection and also their media uses were signaled in
    this way.  In these cases, the port number says nothing about the
    service, and the ALPN may but doesn't have to do strictly either.
    Or the service could be "webrtc-endpoint".  But this does not need
    say which media are going to be exchanged across the QUIC
    connection.  That is at the discretion of the applications and what
    they negotiate.

David's comment seems to imply the former, our considerations implied
the latter, which is where the misunderstanding likely comes from.

 > 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
I certainly agree that you can do both and we would not want to preclude
either.  But I don't see why this is necessarily at odds with allowing
a webrtc ALPN.

Independent QUIC connections muxed on the same port are a clean solution
but then you would need to have an independent "layer" on top that
defines relative prioritization since you run independent congestion
control loops, rather than coupled ones (when mixing RTP and non-RTP
media).

(This could still be a desirable outcome if we cannot define a
meaningfully coupled one.)

In general, I can always try to push the muxing to a lower layer but
this also comes at a cost.  The main question is where to push this
cost to and what are the pros and cons of such decision.

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

We aren't bound to use flow identifiers if we get the RTP-based
multiplexing cleanly defined.  This boils down to one question that
the working group needs to decide in the end: is there sufficient
value in this multiplexing flow identifier or not -- or should it be
optional and signaled?

Best,
Jörg