Draft: draft-ietf-quic-load-balancers

Commentary: follow - on to , also fixing 
 asks if there is value in expressing server ID lengths in bits instead octets . This is a bit of implementation complexity and a lot of churn in the spec and the handful of implementations that exist , but it does give the configuration agent a little more granularity . Does anyone find the value of this granularity to be compelling ? 
 My thinking is that increasing / decreasing the server ID space by 256 is quite a large jump and could make config rotation a bit more complex . Adding an extra bit to the server ID doubles the number of IDs , which is a fairly widely used increase in data structures and algorithms . 
 While having such fine control would optimize for efficiency , splitting up bytes like this would complicate implementation . I 'm also doubt that 1B of overhead is really going to affect anything . Closing this issue due to old age ; can reopen if anyone wants to fight it out . 
 proposed a PCID design that assigns SIDs on the fly instead of having to pre - configure them . There are drawbacks but it has some nice properties . 
 This is merged , but I 'm going to take the question of what we can do with these dueling plaintext designs to the list . 
 List discussion was not helpful ; closing this with the dynamic method still in the draft .
The server chooses how many octets to reserve for its own use, which
MUST be at least one octet.
The ECMP CID Algorithm is similar to the plaintext CID algorithm, but
allows the L4 load balancer to decide which server to send traffic to
on a per-CID basis.  This still links connections to servers, but the
connection is dynamic and slightly less linkable than the plaintext
CID algorithm.  The format is depicted in the figure below.
The configuration agent selects a length for the server ID encoding.
This length MUST have enough entropy to have a different code point
for each server.
On each incoming packet, the load balancer extracts consecutive
octets, beginning with the second octet.  If these octets match an
existing server ID, the packets are routed to the new server ID.  If
the octets are not a match and the packet is an Initial packet, then
it is assumed to be a new flow and load balanced.
When a server needs a new connection ID, it selects a random CID from
another connection which is known to route identically and randomizes
the non-routing bytes of the CID.
The Low-Config CID Algorithm is similar to the plaintext CID
algorithm, but allows the load balancer to assign server IDs
dynamically so that configuration does not require bespoke server ID
assignment.  This also reduces linkability.  However, it requires
state at the load balancer that roughly scales with the number of
connections, until the server ID codespace is exhausted.
The configuration agent selects a length for the server ID encoding
that MUST have at least enough entropy to have a different code point
for each server.  It MUST be no more than seven octets.
The configuration agent also selects an LB Timeout.
The load balancer maintains a table of all assigned server IDs, which
is initialized empty.  On each incoming packet, the load balancer
extracts consecutive octets, beginning with the second octet.  If
these octets match an existing server ID, the packets are routed to
the matching server ID.  As there are no assigned server IDs at
first, the first incoming packet has a non-compliant DCID by
definition.
The server ID table is distinct for each instance of low-config CID
algorithm configuration, even if two configurations use the same
server ID length.  Thus a given server ID might correspond to a
different server in each configuration.
Note that each server will usually have many server IDs assigned to
it.
The load balancer MUST keep track of the most recent observation of
each server ID in the table and delete the entries when the time
since that observation exceeds the LB Timeout.
In QUIC version 1, incoming Connection IDs generated by clients
should be no less than 8 octets, so all non-compliant DCIDs should
not be due to insufficient length.  Load balancers that are operating
the Low-Config CID algorithm SHOULD drop incoming packets with CIDs
too short to execute it unless it can be routed using another
configured algorithm.
If the DCID is non-compliant solely because the server ID is
unassigned, the load balancers follows the procedures in routing-
algorithms and adds the server ID and assignment the table.
Identify the instance of Low-Config CID configuration with the
largest config rotation codepoint.  For example, if configurations
0b10, 0b01, and 0b00 all use the low-config CID algorithm and have
server ID lengths of 3, 5, and 7 octets, respectively, and a
packet comes in with codepoint 0b11, the load balancer would
extract 3 octets for the server ID.
Extract the appropriate number of octets.
If the server ID matches one already in the table, forward the
packet to that server.
If not, the load balancer runs the algorithm of its choosing and
adds the extracted server ID to the table corresponding to the
highest-value Low-Config CID Configuration codepoint.
The server chooses how many octets to reserve for its own use, which
MUST be at least one octet.  It also maintains a list of server IDs
it has observed and the last time it received a packet with that ID.
This list is distinct for each instance of Low-Config CID Algorithm
configuration.
When a server receives a packet, it extracts the server ID.  If the
config rotation bits in the CID encode 4-tuple routing or an
undefined configuration, it uses the highest-value Low-Config CID
config rotation codepoint and extracts the server ID as if that
configuration applied.
If the server ID is not currently in the list, the server adds it.
The server ID's entry is also updated with the most recent arrival of
that server ID.
When a server needs a new connection ID, it uses one of the server
IDs in its list to populate the server ID field of that CID.  It
SHOULD vary this selection to reduce linkability within a connection.
If a server has not received a connection ID encoding a particular
server ID within the LB timeout, it MUST retire any outstanding CIDs
that use that server ID and cease generating any new ones.
A server SHOULD have a mechanism to stop using some server IDs if the
list gets large relative to its share of the codepoint space, so that
these allocations time out and are freed for reuse by servers that
have recently joined the pool.
The Low-Config CID algorithm is dependent on client-generated
Destination CIDs in Initial Packets being at least 8 octets in
length.  If they are not, the load balancer may not be able to
extract a valid server ID to add to its table.  Configuring a
shorter server ID length can increase robustness to a change.