Re: [AVTCORE] Multiplexing in RTP over QUIC

[Mathis Engelbart <[e-mail]>]

Hi Bernard,

On 12/21/22 19:56, Bernard Aboba wrote:
> However, this does raise the obvious question:  "Why is it necessary to 
> be able to multiplex multiple RTP sessions over a single QUIC connection"?

I am not sure if it is necessary to be able to multiplex multiple RTP 
sessions over a single QUIC connection. With flow identifiers, it seems 
easy to support multiplexing multiple sessions while also allowing 
bundling in a single session. Applications can, of course, also still 
choose to open multiple connections. Is there any reason multiplexing 
more than one session should not be supported?

Best,
Mathis

> 
> 
> On Wed, Dec 21, 2022 at 12:48 PM Mathis Engelbart 
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     Hi Roman,
> 
>     As far as I understand BUNDLE, it allows multiplexing multiple media
>     streams in a single RTP session, which is supported in RTP over QUIC
>     using BUNDLE and a single flow identifier. Multiple RTP sessions cannot
>     be multiplexed using BUNDLE and must also use different flow
>     identifiers
>     in RTP over QUIC.
>     Using a single flow identifier for bundled RTP streams and separate
>     flow
>     identifiers for signaling and data channel replacements should work
>     fine.
> 
>     Best,
>     Mathis
> 
>     On 12/21/22 17:35, Roman Shpount wrote:
>      > Mathis,
>      >
>      > Is RTP-bundle supported by RTP over QUIC? If it is supported,
>     then more
>      > than one RTP session should be able to share the same flow
>     identifier.
>      > My expectation would be to use one QUIC flow for bundled RTP
>     sessions,
>      > and separate QUIC flows for signaling and data channel replacements.
>      >
>      > Thank You,
>      > _____________
>      > Roman Shpount
>      >
>      >
>      > On Wed, Dec 21, 2022 at 10:59 AM Mathis Engelbart
>      > <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>
>     wrote:
>      >
>      >     Hi,
>      >
>      >     Thank you for your feedback regarding multiplexing in RTP
>     over QUIC.
>      >
>      >     Following the feedback, we wrote some text to clarify how the
>     approach
>      >     using flow identifiers can support all of the requirements
>     listed in my
>      >     first mail. Flow identifiers will act as the multiplexing
>     layer on top
>      >     of QUIC that can be used equally for RTP/RTCP and non-RTP
>     streams. We
>      >     would appreciate it if you read the new text and provide
>     feedback on
>      >     this approach.
>      >
>      >     The new text can be found as a pull request in [1], or if you
>     prefer to
>      >     read the compiled document, you can find it in section 6 of [2].
>      >
>      >     [1] https://github.com/mengelbart/rtp-over-quic-draft/pull/54
>     <https://github.com/mengelbart/rtp-over-quic-draft/pull/54>
>      >     <https://github.com/mengelbart/rtp-over-quic-draft/pull/54
>     <https://github.com/mengelbart/rtp-over-quic-draft/pull/54>>
>      >     [2]
>      >
>     https://mengelbart.github.io/rtp-over-quic-draft/feat/flow-id-multiplexing/draft-ietf-avtcore-rtp-over-quic.html#section-6 <https://mengelbart.github.io/rtp-over-quic-draft/feat/flow-id-multiplexing/draft-ietf-avtcore-rtp-over-quic.html#section-6> <https://mengelbart.github.io/rtp-over-quic-draft/feat/flow-id-multiplexing/draft-ietf-avtcore-rtp-over-quic.html#section-6 <https://mengelbart.github.io/rtp-over-quic-draft/feat/flow-id-multiplexing/draft-ietf-avtcore-rtp-over-quic.html#section-6>>
>      >
>      >     Best,
>      >     Mathis
>      >
>      >     On 12/16/22 18:04, Mathis Engelbart wrote:
>      >      > Hello Everyone,
>      >      >
>      >      > In yesterday’s interim meeting, we decided to move the
>     multiplexing
>      >      > discussion for RTP over QUIC to the mailing list. To keep
>     this mail
>      >      > short, we decided to split the discussion into smaller pieces.
>      >     First, we
>      >      > would like to understand what types of multiplexing are
>     required
>      >     in RTP
>      >      > over QUIC. We would like to use this thread to ask for your
>      >     opinion on
>      >      > which requirements the document should support.
>      >      >
>      >      > We see the following four requirements we could aim to
>     support:
>      >      >
>      >      > 1. A single RTP session in one QUIC connection. Multiple
>     RTP sessions
>      >      > and RTCP will need separate QUIC connections.
>      >      >
>      >      > 2. Multiplex RTP and RTCP in one QUIC connection. (Note
>     that this
>      >      > implies that an implementer may still choose option 1.)
>      >      >
>      >      > 3. Multiplex many RTP sessions and RTCP in one QUIC
>     connection.
>      >      > Following RTP's original design, senders usually sent
>     different media
>      >      > streams in separate RTP sessions, which had to run over
>     distinct
>      >      > transport layer flows. The restriction was updated to
>     allow multiple
>      >      > media types in a single RTP session in RFC 8860. Thus,
>     requiring
>      >      > multiplexing of multiple RTP sessions may not be the most
>      >     important, but
>      >      > if RTP over QUIC can support multiplexing sessions, it would
>      >     allow using
>      >      > either multiple media types in a single session or multiple
>      >     sessions for
>      >      > different media types.
>      >      >
>      >      > 4. Multiplex RTP/RTCP and potentially other protocols in
>     one QUIC
>      >      > connection. Multiplexing non-RTP protocols could be used to do
>      >     signaling
>      >      > on the same connection or to enable use cases such as
>     WebRTC data
>      >     channels.
>      >      >
>      >      > Please let us know what you think about these options,
>      >     specifically if
>      >      > you think any of these options must or must not be included in
>      >     RTP over
>      >      > QUIC. Please also let us know if we made a mistake in the list
>      >     above or
>      >      > missed another requirement entirely.
>      >      >
>      >      > We hope it will be easier to discuss solutions to the
>     multiplexing
>      >      > problem when it becomes clear which kind of multiplexing
>     we plan
>      >     to support.
>      >      >
>      >      > Best,
>      >      > Mathis
>      >      >
>      >      > _______________________________________________
>      >      > Audio/Video Transport Core Maintenance
>      >      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >      > https://www.ietf.org/mailman/listinfo/avt
>     <https://www.ietf.org/mailman/listinfo/avt>
>      >     <https://www.ietf.org/mailman/listinfo/avt
>     <https://www.ietf.org/mailman/listinfo/avt>>
>      >
>      >     _______________________________________________
>      >     Audio/Video Transport Core Maintenance
>      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      > https://www.ietf.org/mailman/listinfo/avt
>     <https://www.ietf.org/mailman/listinfo/avt>
>      >     <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>
>