Clear 0-length CID is special, but I wonder if it makes sense to discuss multi path in the context of 0-length CID. Already migration is severely limited in that case.
Keeping track of that path of every packet can easily double the space needed to maintain a connection: If you store the data expicitly, it becomes a signficant overhead since a packet state can be recorded with a few bits. If you store each packet in a per path collection, you cannot coalesce ranges, causing each collection to swell, and you have multiple places to look for the packet (or just one if you know where to look). Or you can split the PN on the lower bits but that limits the number of concurrent paths artificially. Granted there might not be a 1-1 CID to path, but there could be if you design it so. Especially if you allow nat rebindings to count as a single paths in the terms of PN space and RTT etc. If we still want to have 0 length CID on multi-path we could make a sepcial allowance for very very short CIDs. I have not thought this out in all details, so maybe using a CID in this way is a bad idea, but up front I find it compelling even if not fully solved as is. There is also something to be said about routing and hardware off-load where a CID could be helpful. I just for splitting the load on multiple cores - although any packet header identifier could help with that.. It’s just that there isn’t that much space in the packet header and we don’t want to limit the number of concurrent paths unnecessarily. Mikkel On 16 November 2020 at 20.56.24, Christian Huitema ([email protected]) wrote: On 11/16/2020 10:19 AM, Mikkel Fahnøe Jørgensen wrote: Why not use the connection ID for encoding the PN? Mikkel First, using the connection ID is a trade-off between ease of management and transmission overhead. Some major client implementations use zero-length CID precisely because of that. The combination of zero-length CID on the client and long CID on the server works well, allows for migration and NAT rebinding, and provides the lowest overhead when the bulk of the transmission is from server to client. Second, the life of the CID is not quite the same as the life of a path. CID are only associated to paths when packets are sent with that CID on that path. If we go for path specific packet numbers and encryption contexts, we may well have transitions between using a given CID with the default encryption context and allocating a specific encryption context to the path. And then, there is the issue of NAT rebinding. Suppose that the receiver identifies a path by its 4 tuple, which is the only option if the CID is zero length. In the case of NAT rebinding, the packets are suddenly arriving on a new path. What key do you use for that new path? I think the only safe way to do that is to carry a PN space identifier in the packet header. My initial feeling is that using a single key and a single PN avoids all that key-management complexity. Clearly that's a trade-off: senders must keep track of which PN was sent on what path, and the ACK frames may become longer due to out-of-order arrivals. I believe this is an OK tradeoff, because managing several number spaces and several encryption keys also adds its own complexity. I prefer the single PN space design because it puts all the complexity on the sender side -- a peer that can't be bothered will just accept packets coming from whatever path, and send on a single return path following pretty much the QUIC V1 logic. -- Christian Huitema On 16 November 2020 at 19.12.02, Christian Huitema ([email protected]) wrote: Kazuho, You are proposing to use a transform, in which the AEAD "sequence" is the conjunction of a sequence number space identifier and the number within that space. I agree that doing that solves the uniqueness requirement, but I have two concerns. First, your original proposal allocates just 2 bits for the sequence number space identifier. You observe that the sequence number is encoded as a varint, which can only encode 62 bits of value, and thus we can reuse the two high order bits to encode a number space identifier. But what happens if the connection uses more than 4 number spaces? Second, we have a synchronization issue. At what point do nodes start using the "path-specific" number space? If we want to be robust, don't we need to encode a number space identifier in the packet header? -- Christian Huitema
