Do we need to allow transport parameter "initial_max_path_id" to be set to 0?

[Yanmei-Liu]

Record issue discussed in PR #376 : Do we need to allow transport parameter "initial_max_path_id" to be set to 0?

In the current draft:

An endpoint that receives a value less than 1 MUST close the connection with an error of type TRANSPORT_PARAMETER_ERROR.

There're 3 scenes when handshaking:

• Endpoints want to enable multipath extension, and allowing new paths immediately after handshake is finished(and MP_NEW_CID is announced): Endpoints set TP "initial_max_path_id" to at least 1;
• Endpoints don't want to enable multipath extension: Endpoints don't send TP "initial_max_path_id" at all.
• Endpoints don't want to allow for new paths when handshake finished, but keep the possibility to create new paths in the future: Endpoints might want to set TP "initial_max_path_id" to 0, but use MAX_PATH frame to allow for new paths when necessary;

If people have such scenarios which need to allow transport parameter "initial_max_path_id" to be set to 0, please comment in this issue.

[marten-seemann]

This would be consistent with how flow control works for streams data and for the number of streams. You can start with 0, and increase the limit later on by sending the respective flow control frame.

[huitema]

I get the consistency with streams, but we already have 1 path set by the handshake. So I think we should either insist on at least 1, or define that max path ID is less than or equal to max paths -- currently it is defined as strictly less than.

[huitema]

I think this would go with the renaming of the parameter as max_path_id.

[mirjak]

Yes, with max_initial_path_id 0 would many only one path with path id 0 is allowed. I think that is fine and we don't need an error case here. Makes things simpler.

[mirjak]

I'm closing this issues as this is now addressed in PR #376