In some situations the ACK frames will be for CID with sequence number 1

[gloinul]

Section 5.1 "If the multipath extension has been successfully negotiated, ACK frames in 1-RTT packets acknowledge packets sent with the Connection ID having sequence number 0."

I want to note the following in RFC 9000 from section 5.1.1: "If the preferred_address transport parameter is sent, the sequence number of the supplied connection ID is 1."

To my understanding there is this case discussed in Section 4: "They can also start using multiple paths, unless both server preferred addresses and a disable_active_migration transport parameter were provided by the server, in which case a client is forbidden to establish new paths until "after a client has acted on a preferred_address transport parameter" (Section 18.2. of [QUIC-TRANSPORT])."

Isn't it necessary to use normal ACK frames while performing this migration. Thus, normal ACKS may also be used for sequence number 1? Or should one use MP_ACKS for this sequnce number space?

So text should be updated to include this exception or clarify usage of MP_ACK in this case. .

[huitema]

I think the multipath draft needs to explicitly update that section of RFC 9000.

The sender preferred path is carried as a transport parameter, and is only activated after the client has received the server's transport parameters. At that point, the client knows whether multipath has been negotiated or not. When multipath is negotiated, the following should apply:

1) The CID provided in the preferred address transport parameter is considered to have path-ID=1. We can debate whether the CID sequence number shall be zero or 1, it does not matter much, and sequence number 1 would help maintain some compatibility with RFC 9000

2) If the client creates a new path using the server provided parameters, that new path SHOULD have path-ID=1.

3) For the new path, we use MP_ACK, etc.

[huitema]

But we should only do that work after we have decided whether to use unique path ID or not. This is an area where the CID solution is in fact simpler.

[mirjak]

Current the draft says:

Also, the Path Identifier for the connection ID specified in the "preferred address" transport parameter is 0. Use of the "preferred address" is considered as a migration event that does not change the path ID.

I think that is fine actually. Do we need to say more? Can we close this issue?

[mirjak]

Closing as not applicable anymore with the explicit path ID approach.