tokio-quiche: Enable active connection migration for clients of tq's QUIC server #2289
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
TheJokr
force-pushed
the
lblocher/tq-extra-cids
branch
from
1cef63e to
34e4052
Compare
Contributor
Author
|
CI failures are due to missing apt packages, Took some time to investigate, it's because we don't call |
TheJokr
force-pushed
the
lblocher/tq-extra-cids
branch
from
34e4052 to
a57fa83
Compare
This ID is redundant as we can identify a connection by its (possibly multiple) QUIC connection IDs. There is no place where we actually use the internal ID.
We can support socket-specific CID generators by moving the trait object from the top-level entrypoints to `QuicListener`, which exists separately for each socket. This allows the implementor full flexibility in terms of what properties to consider when generating CIDs for a given socket. To avoid a type parameter in `QuicListener`, we require the user to pass us an `Arc<dyn ConnectionIdGenerator>` (which is the internal representation we want to use anyway.) This also allows users to share a generator across all of their sockets.
We aim to always provide as many CIDs to the peer as the local+remote transport parameters allow. At the same time, retired connection IDs are unmapped to keep the ConnectionMap compact. To produce new connection IDs, we wire up the socket's `Arc<dyn ConnectionIdGenerator>` all the way to the IoWorker parameters.
TheJokr
force-pushed
the
lblocher/tq-extra-cids
branch
from
a57fa83 to
8f4cfe5
Compare
Now that the tokio-quiche work loop issues extra connection IDs, we can properly support active connection migration. This is not a feature available to tokio-quiche clients today, but other QUIC clients talking to tokio-quiche servers can take advantage of it.
TheJokr
force-pushed
the
lblocher/tq-extra-cids
branch
from
8f4cfe5 to
3841db7
Compare
LPardue
reviewed
Jan 15, 2026
| client_config.set_initial_max_streams_bidi(10); | ||
| client_config.set_initial_max_streams_uni(3); | ||
| client_config.set_active_connection_id_limit(2); | ||
| // We don't need to allow the server to initiate connection migration |
Contributor
There was a problem hiding this comment.
nit: QUICv1 does not permit servers to initiate migration any way, so perhaps a comment like below is more accurate
// Server's can't initiate migration but disable it explicitly anyway.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR consists of 4 separate commits. The first two are refactors to simplify bits of the internal and public API of tokio-quiche. On the public side, I removed the
socket_cookieparameter completely and made the CID generator aQuicListenerproperty. This means our users are expected to provide a generator for each socket now, with TryFrom defaulting toSimpleConnectionIdGenerator. Users that relied onsocket_cookiehave more flexibility now, as they can embed the cookie (or any other data they may require) directly in the CID generator instance. This is a breaking change.The third commit changes the IoWorker loop to top up quiche's supply of SCIDs in every iteration, as well as removing retired SCIDs from the
ConnectionMap. SCIDs are generated by the generator from theQuicListener(which was the reason for refactoring that API in the first place.) Each active connection receives its own Arc to the shared generator. This unblocks active connection migration for clients, as we already support passive migration where only the IP/port changes.Finally, the fourth commit adds a test to verify that active migration works correctly. Since active and passive migration scenarios are extremely similar, and both require low-level quiche access, I decided to add the active-migration-specific bits to the existing passive migration test case rather than copy-pasting the entire thing.