Stream-level and flow-level controls

[obonaventure]

QUIC defines different ways that enable a host to control the amount of data that the other host can transmit at the connection level (MAX_DATA) and at the stream level (MAX_STREAMS and MAX_STREAMS_DATA).

The MAX_STREAMS and MAX_STREAMS_DATA relate to the connection and should not be affected by the fact that it uses multiple paths.

For MAX_DATA, the situation is a bit different. There are deployments and applications that would like to restrict the amount of data or bandwidth that is sent on a given path. A typical example is a smartphone that does not want to use too much data on cellular but has no restriction on WiFi. As in MPTCP, we need a connection-level MAX_DATA that limits the amount of data which can be in flight. In MPTCP, this corresponds to the receive window and the same window is advertised over all subflows. We could not do better than this within the IETF.

In MPQUIC, there is an opportunity to send a per-path MAX_DATA to restrict the utilization of a path or define other control frames to specify the maximum allowed bandwidth per path.

We might discuss whether we should include this functionality in version 1 or leave it to another draft.

[yfmascgy]

I think it is useful to restrict the amount of data on a particular interface. But I am not sure if the best way is per-path MAX_DATA. For example, a path on a 4G interface can be teared down and setup multiple times during the lifetime of a connection. I guess the real purpose here is to put a limit on the total amount of data sent an interface, rather than a path with a particular path ID ? It seems difficult to calculate a per-path quota in advance, since we don't know how many times we are going to abandon and re-establish a path on that interface.

[huitema]

MAX DATA is not at all equivalent to the flow control in TCP. For example, it only applies to the amount of bytes sent in stream frames, would not apply for example to video sent in Datagram frames, let alone ACKs and other control frames. It counts only the new stream bytes, which means a packet sent multiple times would only be counted once.

We know that we will need complementary drafts. The per path control seems like something for one of these drafts, maybe some form of advance scheduling.

[qdeconinck]

To me, it seems that additional mechanisms are required to implement the scenario where you want to limit the number of total bytes (not unique ones) over a given path, and in particular DATAGRAM frames are not subject to flow control. As this looks like a form of path prioritisation, maybe should we delegate this in a separate draft?

[mirjak]

Yes, I think this is related to scheduling and probably also prioritisation and QoS signalling, which should go into a separate draft.

[obonaventure]

Agreed with your responses. I would suggest to add a sentence in the current draft indicating something like.

When used with multipath QUIC, the stream and flow level control mechanisms defined in RFC9000 apply to the entire connection. This document does not specify how restriction or prioritization can be applied to specific paths.