Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support Client Migration (Client Side) #1946

Open
nibanks opened this issue Aug 27, 2021 · 4 comments · May be fixed by #4218
Open

Support Client Migration (Client Side) #1946

nibanks opened this issue Aug 27, 2021 · 4 comments · May be fixed by #4218
Labels
Area: API Area: Build Area: Protocol Updates Changes for new protocol changes help wanted Extra attention is needed
Milestone
Future

Comments

@nibanks
Copy link
Member

nibanks commented Aug 27, 2021

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.
@nibanks nibanks added help wanted Extra attention is needed Area: Build Area: Protocol Updates Changes for new protocol changes Area: API labels Aug 27, 2021
@nibanks nibanks added this to the Future milestone Aug 27, 2021
@nibanks nibanks pinned this issue Aug 27, 2021
@qzhuyan
Copy link
Contributor

qzhuyan commented Sep 13, 2021

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
Copy link
Member Author

nibanks commented Sep 13, 2021

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.

@qzhuyan qzhuyan mentioned this issue Sep 28, 2021
Closed
6 tasks
@nibanks nibanks mentioned this issue Sep 28, 2021
Closed
6 tasks
@nibanks nibanks mentioned this issue Nov 11, 2021
Closed
@zzhlong
Copy link

zzhlong commented Jul 28, 2022

Hello, do you support client connection migration now?

@nibanks nibanks modified the milestones: Future, Release 2.2 Aug 9, 2022
@nibanks nibanks modified the milestones: Release 2.2, Release 2.3 Feb 16, 2023
@masa-koz
Copy link

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.

masa-koz#1

@nibanks nibanks modified the milestones: Release 2.3, Future Oct 12, 2023
@masa-koz masa-koz linked a pull request Mar 29, 2024 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Area: API Area: Build Area: Protocol Updates Changes for new protocol changes help wanted Extra attention is needed
Projects
MsQuic Walkthroughs
Status: Should be written
Milestone
Future
Development

Successfully merging a pull request may close this issue.

Support Client Migration (Client Side) masa-koz/msquic
4 participants
@qzhuyan @masa-koz @nibanks @zzhlong