Support Dynamic Update Roll Over Scenarios (w/ XDP)

[nibanks]

Describe the feature you'd like supported

Today, when an app wants to update to a new version of its code, it must stop the old version and then start the new one, because the UDP binding layer (i.e. socket) cannot be owned/shared simultaneously by both apps. With MsQuic+XDP we have the ability to pretty easily support these scenarios, and I think we should.

Proposed solution

The first step in supporting this is to update the XDP layer to support separate routing rules based on the QUIC header type:

1. Long header routing, with an optional CID matching mask, routes only long header packets (optionally matching the mask).
2. Short header routing, with a (not optional) CID matching mask, routes only short header packets that match the mask.

(Note, today we only support src & dest CID prefix matching)

Then, once you have this support in XDP, MsQuic can leverage them to route "new traffic" and "existing traffic" differently:

• The "primary" or "latest" version of a running app would plumb the rule to route all new traffic to it by configuring all long header packets to be routed to it.
• All versions of an app would encode an (one byte?) "app ID" somewhere into the CIDs they generate and configure all short header packets that match this ID to be routed to them.

Then, when a new version of the app is started, it picks the next app ID, and then plumbs the rule so new traffic comes to it and starts using its app ID. The previous version of the app, using the old ID, would continue to function, but get no new traffic. Ideally, a signal would be sent to gracefully terminate the old connections ASAP, and to inform the client they should just reconnect.

Additional context

Required changes

1. New rules at XDP layer to route long and short header packets separately.
2. MsQuic setting/parameter to specify the application ID.
3. MsQuic encoded application ID in the CIDs it creates.
4. MsQuic uses the presence of a configured app ID as signal to configure the appropriate rules to XDP.

Questions

• Should the app signal to MsQuic "stop routing new traffic" or should we have XDP always prefer "new rules" so when a new app comes in it automatically steals traffic from the old app?
• If we do make this an explicit signal from the app, what should the signal be? Stopping/closing the listener seems like a good fit.

[anrossi]

If we combine all the extensions which store data in the CID, the CID becomes a lot less random, and much more easy for an observer to correlate. The default CID length may need to be increased to make this less of a problem.