Closed mirjak closed 2 months ago
I think it suffices to point out that endpoints MAY abandon one path if another path uses the same 4 tuple -- because of course they MAY abandon any path at any time. The main problem I see is the possible collision. Path 1 and 2 share the same 4 tuple, client abandons 1 and at the same time server abandons 2, leave the connection with no path. Maybe we need to say something like "in these conditions, always abandon the one with the lowest path-ID".
[...] The main problem I see is the possible collision. Path 1 and 2 share the same 4 tuple, client abandons 1 and at the same time server abandons 2, leave the connection with no path. Maybe we need to say something like "in these conditions, always abandon the one with the lowest path-ID".
Just to clarify, if I understand correctly, the problem of both sides closing paths is independent of whether we allow multiple paths over the same 4-tuple, or not? We have the same problem if path 1 and 2 were using different 4-tuples?
We merged #400 that removed the restriction to only have one path per 4-tuple. However, I'm leaving this issue open for now to potentially discuss if further guidance is needed.
I think one aspect of multiple paths over the same 4-tuple is that they may actually not be equal. For example one could have two paths, where the packets for one path is using a different DSCP than the other, or enable L4S. These two packets can thus see significant different forwarding behaviours. So it is not necessary true that they are equivalent.
At IETF-120 @huitema agreed to take a first try on more guidance and use case consideration as also indicated by @gloinul above.
Currently the draft says that only one path per 4-tuple is allowed. This was needed previously to better distinguish between migration and a new path. With use of the explicit path ID this is not needed anymore. Should we therefore allow for multiple paths over the same 4-tuple (using different path IDs)?
Note that from a congestion control point of view that could give you a benefit as each path has an own congestion control. However, we could recommend to use coupled congestion control or even simply divide the cwnd by the number of paths. Or we do nothing here because you can really enforce a certain congestion control behavior and effectively anybody could just multiple the cwnd by some factor even with only one path.
Also note that if we want to only allow for one path per 4-tuple, we would probably need to describe a way to enforce that by either ignoring an path validation attempt or actively closing one of the two paths.