Stream scheduling

[markusa]

As RFC9000 provides the handling of streams, I wonder if a MP-QUIC has to consider this as well, at least in a section similar to the exisiting "Packet scheduling" one?

To become more precise, assuming within one MP-QUIC connection the availability of different streams with different demands. Maybe one stream is "best effort", while another is latency critical and expects in-order devilery. In a multipath scenario using a DSL and a cellular access, there might be the wish to send the latency critical stream through DSL prioritized over other streams, while the "best effort" stream then keeps access to the remaining DSL capacity + the cellular capacity.

[yfmascgy]

We discussed stream scheduling in the sec.7.3 of the previous draft https://datatracker.ietf.org/doc/html/draft-liu-multipath-quic-04. I agree, in practice, what you mention is important, and in our implementation, we use stream group that consists of streams of different policies. The reason we did not discuss the issue in the new draft was that we were trying to focus on the most fundamental issues of multi-path. I think the scheduling part are considered as more advanced features of multi-path, which may be addressed in an extension draft.

[mirjak]

Yes, detailed scheduling algorithms are out-of scope for this document. However, I think it could be useful that add a sentence to the packet scheduling section saying that stream-aware scheduling is likely beneficial.

[markusa]

@mirjak I wonder in generell how you want to perform path and stream scheduling without having indications about path/stream priorities and availability which can be used then from the stream/path scheduling process, also at the far-end?
Look for example at MPTCP RFC8684 MP_PRIO as well as the backup bit, or compare it to the enhanced definition for MP_PRIO in MP-DCCP https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-multipath-dccp-02#section-3.2.10.

[mirjak]

Without any additional knowledge it's a sender side decision which path to use. If you want to provide any additional input from the receiver side, this should be a separate extension.

[markusa]

Shouldn't be the exchange of path/stream prios be a fundamental part of a MP protocol?
I wonder if delegating too much, especially fundamental things, into follow-up extensions will cause confusion and complexity.

[huitema]

Different applications use streams in different ways, and that can lead to very different solutions. For example, you may have a mental model of an application use one stream for video, another for audio, and another for data, but there are applications that use one separate stream for each video frame, leading to very different ways of doing scheduling. Or, we see what Ali Baba has done for video download, using redundant transmission on multiple paths to minimize buffering of videos. That's very interesting, but is very different from simply scheduling streams on specific paths.

We are barely scratching the surface of what can be possible. Scheduling decisions depend on applications, and applications are not blocked. Information about priorities, expected completion time and the like can be carried in application protocols. Nothing stops developers of QUIC stack from providing applications with scheduling control APIs. Delaying standardization of scheduling will not stop deployments. It seems prudent to not standardize too soon.

[obonaventure]

We can adapt https://datatracker.ietf.org/doc/draft-bonaventure-iccrg-schedulers/ and submit it to the QUIC WG to discuss those issues in a separate draft.

[huitema]

I agree that this belongs in a separate draft.

[markusa]

@obonaventure happy to help here, if I can.