search

quicwg / multipath

In-progress version of draft-ietf-quic-multipath
Other
51 stars 18 forks source link

explicit path IDs: Should server preferred address have its own path ID? #317

Closed marten-seemann closed 3 months ago

marten-seemann commented 6 months ago

It's kind of weird that for the migration to the server preferred address path, the path ID is defined as 0. It might be advantageous to keep the anycast and the unicast path open for a limited amount of time.

We could consider defining this path to have path ID 1?

huitema commented 6 months ago

+1. I was under the impression that the preferred path was path-id=1 from the start.

huitema commented 6 months ago

Let's tackle that in conjunction with the server/client odd/even split. With that split, we have two options:

1) Stay strictly compatible with 9000. The client performs a path migration, very similar in nature to a NAT rebinding, and the path ID remains 0.

2) Create a specific path for the "preferred" address, in which case the client initiates a new path to that address. Since this is a client initiated new path, the path ID should be an even number, probably 2.

mirjak commented 4 months ago

I think this is a migration event as also in RFC9000. What would be the benefit of using a new path ID? When would it be useful to have the anycast and unicast address in use at the same time?

mirjak commented 3 months ago

Double-checked that this is clearly specified with path ID 0 as discussed here:

Also, the Path ID for the connection ID specified in the "preferred address" transport parameter is 0. Use of the "preferred address" is considered as a migration event that does not change the Path ID.

Closing now.