quicwg / multipath

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

Static path IDs? #321

Closed kazuho closed 3 weeks ago

kazuho commented 3 months ago

With the new design of having explicit path identifiers, do we need a mechanism for issuing and retiring path IDs at all? They seem to be an unnecessary complexity to me.

The simpler design would be to say that if an endpoint is capable of handling N paths simultaneously, it would use path IDs between 0 and N-1 for the lifetime of the connection, regardless of how many times paths are migrated, either voluntary or involuntary.

When a receiver receives packets on a new path, it has to perform path validation and reset CC regardless of if the received packets carry a new path ID or a old one. Therefore, I think there is not much effort in having the complexity of issuing and retiring path IDs within the protocol.

The downside of reusing path IDs is that endpoints have to remember the last packet number it sent / received on paths that become idle. But that cost would likely be smaller than having the cost of maintaining a dynamic list of path IDs that are alive.

mirjak commented 2 months ago

I think this is a mostly a duplicate of #297. I propose to have the discussion there!

Can we close this issue and use #297 instead?

mirjak commented 1 month ago

I closed #297 and we should continue the discussion here. Please have a look at the discussion in #297 about use of the path ID for the unique nonce.

mirjak commented 3 weeks ago

as we already decided to not re-used path IDs in issue #297 and I see no further discussion here, I will close this issue now. Please re-open if you think more discussion is needed