Path: blob/main/crypto/openssl/doc/designs/quic-design/connection-id-cache.md
34876 views
QUIC Connection ID Cache
The connection ID cache is responsible for managing connection IDs, both local and remote.
Remote Connection IDs
For remote connection IDs, we need to be able to:
add new IDs per connection;
pick a non-retired ID associated from those available for a connection and
select a connection ID by sequence number and retire that and all older IDs.
The cache will be implemented as a double ended queue as part of the QUIC_CONNECTION object. The queue will be sorted by sequence number and must maintain a count of the number of connection IDs present. There is no requirement to maintain a global mapping since remote IDs are only used when sending packets, not receiving them.
In MVP, a many-to-1 matching of Connection IDs per Connection object is required. Refer third paragraph in 5.1.
When picking a non-retired connection ID for MVP, the youngest available will be chosen.
Local Connection IDs
For local connection IDs, we need to be able to:
generate a new connection ID and associate it with a connection;
query if a connection ID is present;
for a server, map a connection ID to a QUIC_CONNECTION;
drop all connection IDs associated with a QUIC_CONNECTION;
select a connection ID by sequence number and retire that and all older IDs and
select a connection ID by sequence number and drop that and all older IDs.
All connection IDs issued by our stack must be the same length because short form packets include the connection ID but no length byte. Random connection IDs of this length will be allocated. Note that no additional information will be contained in the connection ID.
There will be one global set of local connection IDs, QUIC_ROUTE_TABLE
, which is shared by all connections over all SSL_CTX objects. This is used to dispatch incoming datagrams to their correct destination and will be implemented as a dictionary.
Notes
For MVP, it would be sufficient to only use a zero length connection ID.
For MVP, a connection ID to QUIC_CONNECTION mapping need not be implemented.
Post MVP, funnelling all received packets through a single socket is likely to be bottleneck. An alternative would be receiving from <host address, source port> pairs.
For MVP, the local connection ID cache need only have one element. I.e. there is no requirement to implement any form of lookup.
Routes
A pair of connection IDs identify a route between the two ends of the communication. This contains the connection IDs of both ends of the connection and the common sequence number. We need to be able to:
select a connection ID by sequence number and retire that and all older IDs and
select a connection ID by sequence number and drop that and all older IDs.
It is likely that operations on local and remote connection IDs can be subsumed by the route functionality.
ID Retirement
Connection IDs are retired by either a NEW_CONNECTION_ID or a RETIRE_CONNECTION_ID frame and this is acknowledged by a RETIRE_CONNECTION_ID or a NEW_CONNECTION_ID frame respectively.
When a retirement frame is received, we can immediately remove the IDs covered from our cache and then send back an acknowledgement of the retirement.
If we want to retire a frame, we send a retirement frame and mark the IDs covered in our cache as retired. This means that we cannot send using any of these IDs but can still receive using them. Once our peer acknowledges the retirement, we can remove the IDs.
It is possible to receive out of order packets after receiving a retirement notification. It's unclear what to do with these, however dropping them seems reasonable. The alternative would be to maintain the route in a deletable state until all packets in flight at the time of retirement have been acked.
API
QUIC connection IDs are defined in #18949 but some extra functions are available:
Remote Connection ID APIs
Local Connection ID APIs
Routes
Additional status and source information is also included.