Describe how RTP and non-RTP traffic sharing multiple QUIC connections on a single 5-tuple would work

[SpencerDawkins]

We're starting with the idea that these types of traffic might not be using the same model for congestion control, but there's likely much more.

[aboba]

When bulk transfer is enabled along with media, often the desire is for the bulk transfer not to interfere with the media. To prevent that, the bulk transfer uses delay-based congestion control, same as for the media. The bulk transfer will go slower, but that's often what the user wants.

[SpencerDawkins]

@aboba - now that we're focusing on "providing guidance" about congestion control and rate adaptation, I think that saying what you said in your comment is the right thing to say in the document.

[SpencerDawkins]

We may want a clear description of the many levels of multiplexing we can be doing (at the same time). It's turtles all the way down.

[samhurst]

This is a slight tangent to the topic at hand, but I have thought a few times about this myself, and I keep coming back to the idea that multiplexing multiple application protocols within a single QUIC connection is better solved in a distinct standard as it has applicability beyond facilitating bulk data transfer alongside streaming media.

For example, I can see a use case where you could have streaming media, live chat and file sharing all in a single connection. I really don't want to negotiate a connection with an rq ALPN on a simple device, only to have to add all the edge cases where a peer could start trying to bundle bulk transfer in the same connection. Instead, I'm thinking about a QUIC protocol extension which on a connection negotiated with ALPN a, then says I'd like to also send application protocol b. There's then some extension (or replacement for) the STREAM frame that stipulates which application protocol the contents of a given stream are destined for. I think connection-level flow control will still be tricky, but I'd imagine such an extension would contain provisions for flow control on each stream dependent on which application protocol it is assigned to (this definitely needs more thought).

I am surprised an ID for something like this hasn't cropped up yet and I don't know if anyone would be interested in writing one beyond myself. There's always the "you can do it in WebTransport" argument but not everything is a conversation between a web browser and a web server.

[mengelbart]

Sorry, hit comment early...

So the current draft says

If a receiver cannot associate a flow identifier with any RTP/RTCP or non-RTP stream, it MAY drop the data stream.

If that is not ideal, we could define another ALPN that only allows media streams, but that would make things more complicated. When we discussed multiplexing, one of the requirements was to enable use cases where one would like to send non-RTP data on the same connection.

There's then some extension (or replacement for) the STREAM frame that stipulates which application protocol the contents of a given stream are destined for.

That sounds like what we do with the flow identifier, but without using a QUIC extension or a new frame.

I don't know if an extension that allows to change the application protocol would be useful. If I understand you correctly, you would then need some other way of negotiating the new protocols on top.

We could use a STREAM frame extension (or some other form of indicating what a stream contains) that allows multiplexing different application protocols, but I would consider that a different issue from the ALPN negotiation.

[aboba]

Not sure why the RTP over QUIC spec should have normative statements relating to non-RTP/RTCP data. This would be like RFC 3550 attempting to define the behavior of WebRTC data channel. Yes, WebRTC data channel can be multiplexed with RTP/RTCP, but unless something has done wrong, WebRTC data channel packets will never be forwarded to the RTP/RTCP stack.

It's the same here. RTP/RTCP is an application running over the P2P QUIC transport, which takes care of delivering RTP/RTCP data to the RTP stack. If data is being sent, P2P QUIC multiplexing makes sure that it is not delivered to RTP/RTCP.

Also, there is no need for multiple ALPNs. Just as WebRTC only defines one ALPN, in P2P QUIC there is only one ALPN.

[mengelbart]

I think I agree mostly with what you're saying, but I am a bit lost about the P2P QUIC part.

We decided to define multiplexing using the flow identifier and the rtp-mux-quic ALPN because, as far as I know, there was nothing like P2P QUIC defined that would do these things for us. If that changed or will change, should we consider dropping multiplexing with non-RTP/RTCP data and relying on the P2P QUIC multiplexing and ALPN instead?

[SpencerDawkins]

@aboba and @mengelbart - I do think we have an semi-infinitely large number of levels of multiplexing in RoC, and anything that we don't have to specify is going to help us focus on what we absolutely DO need to specify.

[SpencerDawkins]

This discussion has been helpful, but has conflated

• RTP/RTCP being multiplexed with RTP/RTCP and
• other protocols being multiplexed with RTP/RTCP.

We think we have described RTP/RTCP being multiplexed with RTP/RTCP, and #86 is still open for this part of the discussion.

@mengelbart will create a new issue for other protocols being multiplexed with RTP/RTCP.

[SpencerDawkins]

RTP/RTCP being multiplexed with RTP/RTCP is already addressed in the document.

Other protocols being multiplexed with RTP/RTCP will be addressed in #159.