Rename "initial_max_paths / MAX_PATHS" to "intial_max_path_id / MAX_PATH_ID" ?

[Yanmei-Liu]

Record from comments:

marten-seemann 4 days ago

Probably better: initial_max_path_id. This would mirror the meaning of the frame as suggested in https://github.com/quicwg/multipath/pull/292/files#r1527500161.

michael-eriksson 4 days ago

I think it should remain initial_max_paths to be symmetric with initial_maxstreams*.

The explanation can be copied from RFC 9000:

Setting this parameter is equivalent to sending a MAX_PATHS of the corresponding type with the same value.

marten-seemann 4 days ago

My 2c: There's only so much value you get from consistency with RFC 9000. This has created a fair amount of confusion in the review of this PR, and it seems like calling it initial_max_path_id (and the corresponding renaming of the frame), would make it 100% clear what is meant, without the need for long explanations.

michael-eriksson 3 days ago

Well, then I think that the frame type should be MAX_PATH_ID to further reduce the confusion and increase the multipath specification consistency.

[mirjak]

the current draft (-07) uses MAX_PATH to announce the max number of paths and not the largest path ID that can be used. So the name matches the meaning, I would say.

Is this issue to discuss to use the max path ID instead (or was this just about aligning the naming)?

[mirjak]

This is an entire mess right now in the draft:

initial_max_path is defined like this (as the max number of path):

initial_max_path: initial_max_paths (current version uses 0x0f739bbc1b666d07): the initial_max_paths transport parameter is included if the endpoint supports the multipath extension as defined in this document. This is a variable-length integer value specifying the maximum number of active concurrent paths an endpoint is willing to build. The value of the initial_max_paths parameter MUST be at least 2. An endpoint that receives a value less than 2 MUST close the connection with an error of type TRANSPORT_PARAMETER_ERROR. Setting this parameter is equivalent to sending a MAX_PATHS ([Section 8.7](https://quicwg.org/multipath/draft-ietf-quic-multipath.html#max-paths-frame)) of the corresponding type with the same value.[¶](https://quicwg.org/multipath/draft-ietf-quic-multipath.html#section-3-2.1.1)

MAX_PATH is defined like this however:

MAX_PATHS frames are formatted as shown in [Figure 11](https://quicwg.org/multipath/draft-ietf-quic-multipath.html#fig-max-paths-frame-format).[¶](https://quicwg.org/multipath/draft-ietf-quic-multipath.html#section-8.7-2)

MAX_PATHS Frame {
  Type (i) = 0x15228c0b,
  Maximum Paths (i),
}
[Figure 11](https://quicwg.org/multipath/draft-ietf-quic-multipath.html#figure-11): [MAX_PATHS Frame Format](https://quicwg.org/multipath/draft-ietf-quic-multipath.html#name-max_paths-frame-format)
MAX_PATHS frames contain the following field:[¶](https://quicwg.org/multipath/draft-ietf-quic-multipath.html#section-8.7-4)

Maximum Path Identifier:
A count of the cumulative number of path that can be opened over the lifetime of the connection. This value cannot exceed 2^32-1, as it is not possible to encode Path IDs larger than 2^32-1. Receipt of a frame that permits opening of a path with Path Identifier larger than this limit MUST be treated as a connection error of type FRAME_ENCODING_ERROR.[¶](https://quicwg.org/multipath/draft-ietf-quic-multipath.html#section-8.7-5.2.1)

[mirjak]

I created PR #354 to fix the definition of the MAX_PATHS frame now actually indicating the largest Path ID that can be used.

However, initial_max_paths is still defined as the max number of paths (and also thereby also indicate the max path ID at the beginning when no MAX_PATHS frame was received yet). Do we want to change this?

[huitema]

Yes we do. the "initial_max_path" frame shall be the same as "the first MAX PATH frame received on the connection".

[mirjak]

I revised #354

[mirjak]

354 is merged. Frame is now MAX_PATHS and parameter is max_initial_paths. We could still discuss if this naming should be revised but at least it now consistent and more clearly described in the draft. I will close this issue for now. However, you can reopen or open a new issue if you want further discussion.