Is enable_multipath TP remembered?

[kazuho]

RFC 9000 section 7.4.1 states that the definition of a new transport parameter MUST specify whether storing the transport parameter for 0-RTT is mandatory, optional, or prohibited, however it seems to me that is not specified for enable_multipath.

Regarding what we should specify, I do not have a strong preference. To my knowledge all the changes introduced by Multipath QUIC affects 1-RTT packet number space. So I think it would be possible to say that the transport parameter is not remembered. Though I'm not sure if that's the behavior we want.

[marten-seemann]

When we wrote RFC 9000, the only justification for remembering a TP was that this TP would make any difference when sending 0-RTT packets, i.e. up until completion of the handshake. Unless we want to make it possible to send 0-RTT packets on multiple paths (which would require some more involved changes, especially regarding the CIDs to use), we should prohibit remembering this TP.

[kazuho]

@marten-seemann I think we are in agreement that the answer to the question depends on if what's sent in 0-RTT is going to be different.

The problem here is that applications might want to send different 0-RTT data depending on if MP can be used. Multipath is different from other transport parameters in sense that it expects applications (rather than just QUIC stacks) to be written specifically for it.

So that can be the justification for defining the TP as remembered. Though, the other solution here would be to delegate the detection to ALPN; i.e., applications that require use of multipath MUST use ALPN in way that the handshake will fail unless MP is available.

[mirjak]

I also thought that you don't have to remember it because you can anyway only open and use new path after the handshake.

@kazuho I'm not sure if there would be really a dependency on the selection of other transport parameters. Or actually I hope not. Do you have an example?

[kazuho]

@mirjak I think we don't necessarily have to define enable_multipath as remembered, but the following is what an application developer might do, assuming that it is remembered.

An application developer creates a protocol that requires the use of two paths, one being Wifi and cellular. Different information are sent on each path, as their cost model is different.

Once the 1-RTT handshake is complete, this application sets up two paths, exchanging their characteristics using signal defined in the application protocol.

Now, what can this application do when doing 0-RTT resumption?

As active_connection_id_limit TP is remembered, this application can send those signals that assume support for multipath in 0-RTT packets, if enable_multipath is a remembered TP.

If not, they would not be able to.

As said, my point isn't that we have to define enable_multipath as remembered.

Rather, my point is that, assuming that we will define the transport parameter as not remembered, we should note that application cannot send 0-RTT data under the assumption that multipath support will be available in the resumed connection.