search

quicwg / multipath

In-progress version of draft-ietf-quic-multipath
Other
49 stars 17 forks source link

Client and server differences not correctly handled in sentence. #411

Open gloinul opened 1 month ago

gloinul commented 1 month ago

Section 3.5: "In order to let the peer open new paths, it is RECOMMENDED to proactively issue a Connection ID for at least one unused Path ID, as long as it remains compatible with the peer's Maximum Path ID limit."

Isn't this specific to the server role. The client can open a new path if there is known address, the server has provided CIDs for a new path ID and the client itself has declared CIDs for the next path. The server can only enable this process by providing CIDs for the next path.

mirjak commented 1 month ago

In this extension, only the client can open a new path. However, there sentence above it not wrong. So I actually proposed to not change anything here.

gloinul commented 1 month ago

Even if it is the client that needs to send a path challenge, the server can block open new paths by not increasing the Maximum Path ID limit. And it is that this sentence refer to my understanding. Thus, due to the client initiating, this text is applying to the server role. The client when it want to open a path it would in case of max_path_Id limited increase it. I think this text would anyway be touched if the proposal in #342 for MAX_PATHS_BLOCKED.