search

quicwg / multipath

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

Editorial: fix requirement of opening a new path #418

Open Yanmei-Liu opened 1 month ago

Yanmei-Liu commented 1 month ago

Fix issue #407

Yanmei-Liu commented 1 month ago

I don't think this change is necessary. It is also not purely editorial. We discussed that before. We recommend that NEW_CONNECTION_ID frames be sent in order of increasing path ID, but we can never guarantee that they will be received in order. Suppose the server send (C1, pathID 1) and (C2, pathID 2), and that C1 is delayed, maybe by packet loss. Your new text will say that the client MUST wait until C1 is received to open a new path. That's wrong.

Also, it is better to have all the discussion of order, etc., in exactly one place. The previous text is better.

@huitema But in Section 3.5 we use "Similarly, endpoints SHOULD consume Path IDs in a continuous way, i.e., when creating paths." I think in the case of retransmission, endpoints should choose to wait for C1 to create the new path, using C2 would break the "SHOULD".

BTW, this issue and pull request is to solve the true requirement of new path initialization is the use of new Path ID. I changed the description of "the smallest unused Path ID" to "an unused Path ID". Please check again.