multipath
multipath copied to clipboard
quicwg
Should path numbers be continuous?
We observed an interop failure between picoquic and the Quiche implementation modified by Quentin. The picoquic client is waiting for a CID with pathID=1 before opening the second path with path number 1, but Quentin's implementation will only send paths with even numbers.
The immediate interop issue would be fixed if Picoquic used number 2 for its first path creation, but that is not a long term solution. If one implementation expects to see all number used and the other only uses one of them, we will shortly see an issue -- some CID do not get used but still contribute to the "MAX_PATHS" limits, or to the implicit number of path limit at the client. Creation of new paths will then stop, even if the number of paths in actual use remains below the limit.
Should we have a rule about not skipping path numbers?
Path validation on a particular path might fail, without the server receiving any packet for that path. When the client then validates another path, this will look like a skipped path to the server.
So to answer the question: Path IDs SHOULD be used sequentially, but you can't enforce this.
Yes, we do have the case in with the client probes path[3] and the server never gets the probe. The client should send an Abandon[3] to clear the state.
That's true, but you don't know when the PATH_ABANDON arrives. It might be lost / reordered. So you'll need to deal with what looks like non-continuous use of Path IDs anyway.
Yes. My real concern was one of the nodes issuing just some CID -- like Quentin's code only creating CID for even numbers, 0, 2, etc. We will have two limits:
- the "max paths" value, which determines the maximum but does not force the peers to send that much.
- the lower "local maximum" value, based on available memory and other local resource.
My real concern is that if nodes are not going to publish CID for all possible paths, they should start with the lowest numbers to maximize chances of finding numbers supported by both sides.
I would consider this a misbehaviour of the peer. If you refuse to use path IDs available to you, the protocol might get stuck.
I think we should recommend to issue path IDs in order, however, I don't think we can really enforce that. However, what we could consider is to allow closing paths that have not been open or even issued. We already allow closing paths that have not really been opened e.g. after a failed attempt to open a new path. If you could also close a path that was not issued, meaning you never received a CID connected to that path ID but you received CIDs for larger path ID, you can assume that path wasn't used somehow and explicitly close it to free space for a larger, new path ID (if you need one more).
