Support Client Migration (Client Side)

nibanks commented 3 years ago

Describe the feature you'd like supported

Support for QUIC clients to change their/add/remove local addresses (IP or port) should be added to MsQuic. More info at the protocol level can be found at https://datatracker.ietf.org/doc/html/rfc9000#section-9.

This feature allows the client to seamlessly switch between different networks, such as Wi-Fi and cellular, and keep the existing connection alive.

Proposed solution

Starting at the API, probably the best way to tackle this would be to add a way for the app layer to add and remove addresses. New addresses won't be used as the primary by default. But QUIC can start probing them immediately to see if they work. The app will have to "set" the current local address to make it a primary. The app shouldn't need to add it and then set it; it can just add it if it wants to immediately switch it a new one.

Internally, these different addresses would map to separate Paths. All the client side logic for probing and switching paths would need to be completed.

Additional thoughts

Should MsQuic automatically forget addresses ever?
Eventually, if the client doesn't explicitly set (bind) any local address, MsQuic should support automatically switching when the current address doesn't work. This would require a number of additional platform abstractions: querying addresses, getting notification of address changes, etc.
- This is not in scope for this task though. That would be future work.
The work should include as full test coverage as possible, using the existing datapath hooks to spoof anything necessary. Most of the work can be tested just by changing the local port of the client though.

qzhuyan commented 3 years ago

New addresses won't be used as the primary by default. But QUIC can start probing them immediately to see if they work.

Is that on QUIC protocol level?

The app will have to "set" the current local address to make it a primary. The app shouldn't need to add it and then set it; it can just add it if it wants to immediately switch it a new one.

Like this?

 MsQuic->SetParam(Handle,
                                                QUIC_PARAM_LEVEL_CONNECTION,
                                                QUIC_PARAM_CONN_LOCAL_ADDRESS,
                                                sizeof(QUIC_ADDR),
                                               &Address)))

nibanks commented 3 years ago

New addresses won't be used as the primary by default. But QUIC can start probing them immediately to see if they work.

Is that on QUIC protocol level?

Yes, at a protocol level, QUIC allows for multiple parallel paths to be probed (send/receive path challenge/response frames); but only one path may be actively used (sending all other types of data) at a time. So if the API allows an app to "add a new path" we can treat these as "backup" paths that might be used in the future, but we should immediate probe them for viability.

The app will have to "set" the current local address to make it a primary. The app shouldn't need to add it and then set it; it can just add it if it wants to immediately switch it a new one.

Like this?
 MsQuic->SetParam(Handle,
                                                QUIC_PARAM_LEVEL_CONNECTION,
                                                QUIC_PARAM_CONN_LOCAL_ADDRESS,
                                                sizeof(QUIC_ADDR),
                                               &Address)))

Exactly. This would "set" the local address to use for the active path.

zzhlong commented 2 years ago

Hello, do you support client connection migration now?

masa-koz commented 1 year ago

Hello,

I'm trying to implement an API for probing a new path on client. If possible, I would like to get review from this community.

https://github.com/masa-koz/msquic/pull/1

microsoft / msquic