Re: [PATCH net-next v2 07/15] quic: add connection id management

[Xin Long <lucien.xin@gmail.com>]

On Fri, Aug 22, 2025 at 1:11 PM Jason Baron <jbaron@akamai.com> wrote:
>
> Hi Xin,
>
> On 8/18/25 10:04 AM, Xin Long wrote:
> > !-------------------------------------------------------------------|
> >    This Message Is From an External Sender
> >    This message came from outside your organization.
> > |-------------------------------------------------------------------!
> >
> > This patch introduces 'struct quic_conn_id_set' for managing Connection
> > IDs (CIDs), which are represented by 'struct quic_source_conn_id'
> > and 'struct quic_dest_conn_id'.
> >
> > It provides helpers to add and remove CIDs from the set, and handles
> > insertion of source CIDs into the global connection ID hash table
> > when necessary.
> >
> > - quic_conn_id_add(): Add a new Connection ID to the set, and inserts
> >    it to conn_id hash table if it is a source conn_id.
> >
> > - quic_conn_id_remove(): Remove connection IDs the set with sequence
> >    numbers less than or equal to a number.
> >
> > It also adds utilities to look up CIDs by value or sequence number,
> > search the global hash table for incoming packets, and check for
> > stateless reset tokens among destination CIDs. These functions are
> > essential for RX path connection lookup and stateless reset processing.
> >
> > - quic_conn_id_find(): Find a Connection ID in the set by seq number.
> >
> > - quic_conn_id_lookup(): Lookup a Connection ID from global hash table
> >    using the ID value, typically used for socket lookup on the RX path.
> >
> > - quic_conn_id_token_exists(): Check if a stateless reset token exists
> >    in any dest Connection ID (used during stateless reset processing).
> >
> > Signed-off-by: Xin Long <lucien.xin@gmail.com>
> > ---
>
> Thanks Xin for all your work on this!
>
> For QUIC-LB, where the server endpoint may want to choose a specific
> source CID to enable 'stateless' routing, I don't currently see an API
> to allow that? It appears source CIDs are created with random values and
> while userspace can get/set the indexes of the current ones in use, I
> don't see a way to set specific CID values?
>
> For reference here is a proposal around it -
> https://datatracker.ietf.org/doc/draft-ietf-quic-load-balancers/
>
> In the reference above, the source CID is encrypted to help protect
> traceability if the connection migrates. Thus, if the kernel were to
> support such a feature, I don't think it wants to enforce a specific
> encoding scheme, but perhaps it might want to be a privileged operation,
> perhaps requiring CAP_NET_ADMIN to set specific source CIDs.
>
Hi, Jason,

We currently support only the finalized QUIC RFCs. Drafts like
'Load Balancers' and 'Multipath' aren’t covered yet. I think
we will plan the APIs after they are standardized.

Thanks for pointing out this RFC.