Draft: draft-ietf-quic-load-balancers

Commentary: and 
 I 'd suggest ' Fallback ' or another word than arbitrary . A definition of Arbitrary is : " Based on random choice or personal whim , rather than any reason or system . " In fact , there are sensible constraints on this algorithm to ensure routing works correctly for non - compliant CIDs and connections do n't fail . 
 Agreed . 
 In PR I suggested non - routable , though I realize non - conformant may also be an option . The sentence which caused me to suggest non - routable is : I 'm happy to write a PR if others find non - compliant potentially confusing as well . 
 I like it . Let 's go with it . 
 Thanks , this is a lot easier to read for me .
The config rotation bits (config-rotation) may not correspond to
an active configuration.  Note: a packet with a DCID that
indicates 5-tuple routing (see config-failover) is always
compliant.
All other DCIDs are compliant.
Load balancers MUST forward packets with compliant DCIDs to a server
in accordance with the chosen routing algorithm.
Load balancers SHOULD drop short header packets with non-compliant
DCIDs.
The routing of long headers with non-compliant DCIDs depends on the
server ID allocation strategy, described in sid-allocation.  However,
the load balancer MUST NOT drop these packets, with one exception.
Load balancers MAY drop packets with long headers and non-compliant
DCIDs if and only if it knows that the encoded QUIC version does not
allow a non- compliant DCID in a packet with that signature.  For
example, a load balancer can safely drop a QUIC version 1 Handshake
packet with a non-compliant DCID, as a version 1 Handshake packet
sent to a QUIC-LB compliant server will always have a server-
generated compliant CID.  The prohibition against dropping packets
with long headers remains for unknown QUIC versions.
Servers that receive packets with noncompliant CIDs MUST use the
available mechanisms to induce the client to use a compliant CID in
future packets.  In QUIC version 1, this requires using a compliant
CID in the Source CID field of server-generated long headers.
There are conditions described below where a load balancer routes a
packet using an "arbitrary algorithm."  It can choose any algorithm,
without coordination with the servers, but the algorithm SHOULD be
deterministic over short time scales so that related packets go to
the same server.  The design of this algorithm SHOULD consider the
version-invariant properties of QUIC described in QUIC-INVARIANTS to
maximize its robustness to future versions of QUIC.
An arbitrary algorithm MUST NOT make the routing behavior dependent
on any bits in the first octet of the QUIC packet header, except the
first bit, which indicates a long header.  All other bits are QUIC
version-dependent and intermediaries SHOULD NOT base their design on
version-specific templates.
For example, one arbitrary algorithm might convert a non-compliant
DCID to an integer and divided by the number of servers, with the
modulus used to forward the packet.  The number of servers is usually
consistent on the time scale of a QUIC connection handshake.  Another
might simply hash the address/port 4-tuple.  See also version-
invariance.
The config rotation bits (config-rotation) may not correspond to
an active configuration.  Note: a packet with a DCID that
indicates 5-tuple routing (see config-failover) is always
routable.
All other DCIDs are routable.
Load balancers MUST forward packets with routable DCIDs to a server
in accordance with the chosen routing algorithm.
Load balancers SHOULD drop short header packets with unroutable
DCIDs.
The routing of long headers with unroutable DCIDs depends on the
server ID allocation strategy, described in sid-allocation.  However,
the load balancer MUST NOT drop these packets, with one exception.
Load balancers MAY drop packets with long headers and unroutable
DCIDs if and only if it knows that the encoded QUIC version does not
allow an unroutable DCID in a packet with that signature.  For
example, a load balancer can safely drop a QUIC version 1 Handshake
packet with an unroutable DCID, as a version 1 Handshake packet sent
to a QUIC-LB routable server will always have a server-generated
routable CID.  The prohibition against dropping packets with long
headers remains for unknown QUIC versions.
Servers that receive packets with unroutable CIDs MUST use the
available mechanisms to induce the client to use a routable CID in
future packets.  In QUIC version 1, this requires using a routable
CID in the Source CID field of server-generated long headers.
There are conditions described below where a load balancer routes a
packet using a "fallback algorithm."  It can choose any algorithm,
without coordination with the servers, but the algorithm SHOULD be
deterministic over short time scales so that related packets go to
the same server.  The design of this algorithm SHOULD consider the
version-invariant properties of QUIC described in QUIC-INVARIANTS to
maximize its robustness to future versions of QUIC.
A fallback algorithm MUST NOT make the routing behavior dependent on
any bits in the first octet of the QUIC packet header, except the
first bit, which indicates a long header.  All other bits are QUIC
version-dependent and intermediaries SHOULD NOT base their design on
version-specific templates.
For example, one fallback algorithm might convert a unroutable DCID
to an integer and divided by the number of servers, with the modulus
used to forward the packet.  The number of servers is usually
consistent on the time scale of a QUIC connection handshake.  Another
might simply hash the address/port 4-tuple.  See also version-
invariance.
A QUIC-LB configuration MAY significantly over-provision the server
ID space (i.e., provide far more codepoints than there are servers)
to increase the probability that a randomly generated Destination
Connection ID is non- compliant.
A QUIC-LB configuration MAY significantly over-provision the server
ID space (i.e., provide far more codepoints than there are servers)
to increase the probability that a randomly generated Destination
Connection ID is unroutable.
When forwarding a packet with a long header and non-compliant DCID,
load balancers MUST forward packets with long headers and non-
compliant DCIDs using an arbitrary algorithm as specified in
arbitrary-algorithm.
When forwarding a packet with a long header and unroutable DCID, load
balancers MUST forward packets with long headers and unroutable DCIDs
using an fallback algorithm as specified in fallback-algorithm.
Note that when the load balancer's table for a configuration is
empty, all incoming DCIDs corresponding to that configuration are
non-compliant by definition.
If the config rotation bits do not match a known configuration,
the load balancer routes the packet using an arbitrary algorithm
(see arbitrary-algorithm).
Note that when the load balancer's table for a configuration is
empty, all incoming DCIDs corresponding to that configuration are
unroutable by definition.
If the config rotation bits do not match a known configuration,
the load balancer routes the packet using a fallback algorithm
(see fallback-algorithm).
If there is a matching configuration, but the CID is not long
enough to apply the algorithm, the load balancer skips the first
octet of the CID and then reads a server ID from the following
octets, up to the server ID length.  If this server ID matches a
known server ID for that configuration, it forwards the packet
accordingly and takes no further action.  If it does not match, it
routes using an arbitrary algorithm and adds the new server ID to
that server's table entry.
If the sole reason for non-compliance is that the server ID is not
in the load balancer's table, the load balancer routes the packet
with an arbitrary algorithm.  It adds the decoded server ID to
table entry for the server the algorithm chooses and forwards the
packet accordingly.
If there is a matching configuration, but the CID is not long
enough to apply the algorithm, the load balancer skips the first
octet of the CID and then reads a server ID from the following
octets, up to the server ID length.  If this server ID matches a
known server ID for that configuration, it forwards the packet
accordingly and takes no further action.  If it does not match, it
routes using a fallback algorithm and adds the new server ID to
that server's table entry.
If the sole reason for unroutability is that the server ID is not
in the load balancer's table, the load balancer routes the packet
with a fallback algorithm.  It adds the decoded server ID to table
entry for the server the algorithm chooses and forwards the packet
accordingly.
The Block Cipher CID Algorithm, by using a full 16 octets of
plaintext and a 128-bit cipher, provides higher cryptographic
protection and detection of non-compliant connection IDs.  However,
it also requires connection IDs of at least 17 octets, increasing
overhead of client-to-server packets.
The Block Cipher CID Algorithm, by using a full 16 octets of
plaintext and a 128-bit cipher, provides higher cryptographic
protection and detection of unroutable connection IDs.  However, it
also requires connection IDs of at least 17 octets, increasing
overhead of client-to-server packets.
If a Retry Service is integrated with a QUIC-LB compliant load
balancer, it can verify that the Destination Connection ID is
compliant, and only admit non-Initial packets with compliant
DCIDs.  As the Connection ID encoding is invariant across QUIC
versions, the Retry Service can do this for all short headers.
Nothing in this section prevents Retry Services from making basic
syntax correctness checks on packets with QUIC versions that it
understands (e.g., enforcing the Initial Packet datagram size minimum
in version 1) and dropping packets that are not compliant with the
QUIC specification.
If a Retry Service is integrated with a QUIC-LB routable load
balancer, it can verify that the Destination Connection ID is
routable, and only admit non-Initial packets with routable DCIDs.
As the Connection ID encoding is invariant across QUIC versions,
the Retry Service can do this for all short headers.
Nothing in this section prevents Retry Services from making basic
syntax correctness checks on packets with QUIC versions that it
understands (e.g., enforcing the Initial Packet datagram size minimum
in version 1) and dropping packets that are not routable with the
QUIC specification.
If these assumptions are invalid, this specification is likely to
lead to loss of packets that contain non-compliant DCIDs, and in
extreme cases connection failure.
If these assumptions are invalid, this specification is likely to
lead to loss of packets that contain unroutable DCIDs, and in extreme
cases connection failure.