Draft: draft-ietf-quic-load-balancers

Commentary:   points out via email : He 's right . We should just call it a configuration ID and be clearer on what 's what .
The first two bits of any connection-ID MUST encode the configuration
phase of that ID.  QUIC-LB messages indicate the phase of the
algorithm and parameters that they encode.
A new configuration may change one or more parameters of the old
configuration, or change the algorithm used.
It is possible for servers to have mutually exclusive sets of
supported algorithms, or for a transition from one algorithm to
another to result in Fail Payloads.  The four states encoded in these
two bits allow two mutually exclusive server pools to coexist, and
for each of them to transition to a new set of parameters.
The first two bits of any connection ID MUST encode an identifier for
the configuration that the connection ID uses.  This enables
incremental deployment of new QUIC-LB settings (e.g., keys).
Configuration Agents SHOULD make an effort to deliver new
configurations to load balancers before doing so to servers, so that
load balancers are ready to process CIDs using the new parameters
when they arrive.
Configuration Agents SHOULD deliver new configurations to load
balancers before doing so to servers, so that load balancers are
ready to process CIDs using the new parameters when they arrive.
If a server has not received a valid QUIC-LB configuration, and
believes that low-state, Connection-ID aware load balancers are in
the path, it SHOULD generate connection IDs with the config rotation
bits set to '11' and SHOULD use the "disable_migration" transport
parameter in all new QUIC connections.  It SHOULD NOT send
NEW_CONNECTION_ID frames with new values.
It also possible to use these bits for more long-lived distinction of
different configurations, but this has privacy implications (see
multiple-configs).
If a server has not received a valid QUIC-LB configuration, and
believes that low-state, Connection-ID aware load balancers are in
the path, it SHOULD generate connection IDs with the config rotation
bits set to '11' and SHOULD use the "disable_active_migration"
transport parameter in all new QUIC connections.  It SHOULD NOT send
NEW_CONNECTION_ID frames with new values.
CR: Config Rotation bits.
CID Len: Length Self-Description (if applicable).  Encodes the length
of the Connection ID following the First Octet.
During the period in which there are multiple deployed configuration
IDs (see config-rotation), there is a slight increase in linkability.
The server space is effectively divided into segments with CIDs that
have different config rotation bits.  Entities that manage servers
SHOULD strive to minimize these periods by quickly deploying new
configurations across the server pool.
To avoid this, the configuration agent SHOULD issue QUIC-LB
configurations to mutually distrustful servers that have different
keys (for the block cipher or stream cipher algorithms) or routing
masks and divisors (for the obfuscated algorithm).  The load
balancers can distinguish these configurations by external IP
address, or by assigning different values to the config rotation bits
(config-rotation).  Note that either of these techniques exposes
information to outside observers, as traffic destined for each server
set can be easily distinguished.
To avoid this, the configuration agent SHOULD issue QUIC-LB
configurations to mutually distrustful servers that have different
keys (for the block cipher or stream cipher algorithms) or routing
masks and divisors (for the obfuscated algorithm).  The load
balancers can distinguish these configurations by external IP
address, or by assigning different values to the config rotation bits
(config-rotation).  Note that either solution has a privay impact;
see multiple-configs.