Re: [AVTCORE] Multiplexing in RTP over QUIC

[Bernard Aboba <[e-mail]>]

Mathis said:

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

[BA] Indeed, RFC 8843 Section 1.2 says:
"All RTP-based bundled media associated with a given BUNDLE group belong to
a single RTP session [RFC3550
<https://www.rfc-editor.org/rfc/rfc8843#RFC3550>]."

However, this does raise the obvious question:  "Why is it necessary to be
able to multiplex multiple RTP sessions over a single QUIC connection"?

With respect to WebTransport, "pooling" is considered an optimization which
is not completely under the control of the application.





On Wed, Dec 21, 2022 at 12:48 PM Mathis Engelbart <[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]>> 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>
> >     [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
> >
> >
> >     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]>
> >      > 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
>