Change:
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 don'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: URL 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.

Discussion:
These client-generated CIDs might not conform to the expectations of the routing algorithm and therefore not be routable by the load <del> balancer.  Those that are not routable are "non-compliant DCIDs" and receive similar treatment regardless of why they're non-compliant: </del> <ins> balancer.  Those that are not routable are "unroutable DCIDs" and receive similar treatment regardless of why they're unroutable: </ins> 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 <del> compliant. </del> <ins> routable. </ins> The DCID might not be long enough for the decoder to process. The extracted server mapping might not correspond to an active server. <del> All other DCIDs are compliant. </del> <ins> All other DCIDs are routable. </ins> <del> Load balancers MUST forward packets with compliant DCIDs to a server </del> <ins> Load balancers MUST forward packets with routable DCIDs to a server </ins> in accordance with the chosen routing algorithm. <del> Load balancers SHOULD drop short header packets with non-compliant </del> <ins> Load balancers SHOULD drop short header packets with unroutable </ins> DCIDs. <del> The routing of long headers with non-compliant DCIDs depends on the </del> <ins> The routing of long headers with unroutable DCIDs depends on the </ins> server ID allocation strategy, described in sid-allocation.  However, the load balancer MUST NOT drop these packets, with one exception. <del> Load balancers MAY drop packets with long headers and non-compliant </del> <ins> Load balancers MAY drop packets with long headers and unroutable </ins> DCIDs if and only if it knows that the encoded QUIC version does not <del> allow a non- compliant DCID in a packet with that signature.  For </del> <ins> allow an unroutable DCID in a packet with that signature.  For </ins> example, a load balancer can safely drop a QUIC version 1 Handshake <del> 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. </del> <ins> 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. </ins> Furthermore, while the load balancer function MUST NOT drop packets, the device might implement other security policies, outside the scope of this specification, that might force a drop. <del> 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 </del> <ins> 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 </ins> CID in the Source CID field of server-generated long headers. 4.2. There are conditions described below where a load balancer routes a <del> packet using an "arbitrary algorithm."  It can choose any algorithm, </del> <ins> packet using a "fallback algorithm."  It can choose any algorithm, </ins> 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. <del> An arbitrary algorithm MUST NOT make the routing behavior dependent on any bits in the first octet of the QUIC packet header, except the </del> <ins> A fallback algorithm MUST NOT make the routing behavior dependent on any bits in the first octet of the QUIC packet header, except the </ins> 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. <del> 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 </del> <ins> 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 </ins> 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 <del> Connection ID is non- compliant. </del> <ins> Connection ID is unroutable. </ins> Conceptually, each configuration has its own set of server ID allocations, though two static configurations with identical server

In the static allocation method, the configuration agent assigns at least one server ID to each server. <del> 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. </del> <ins> 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. </ins> 4.3.2.

Note that when the load balancer's table for a configuration is empty, all incoming DCIDs corresponding to that configuration are <del> non-compliant by definition. </del> <ins> unroutable by definition. </ins> <del> The handling of a non-compliant long-header packet depends on the reason for non-compliance.  The load balancer MUST applyt this logic: </del> <ins> The handling of an unroutable long-header packet depends on the reason for unroutability.  The load balancer MUST applyt this logic: </ins> If the config rotation bits do not match a known configuration, <del> the load balancer routes the packet using an arbitrary algorithm (see arbitrary-algorithm). </del> <ins> the load balancer routes the packet using a fallback algorithm (see fallback-algorithm). </ins> If there is a matching configuration, but the CID is not long enough to apply the algorithm, the load balancer skips the first

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 <del> routes using an arbitrary algorithm and adds the new server ID to </del> <ins> routes using a fallback algorithm and adds the new server ID to </ins> that server's table entry. <del> If the sole reason for non-compliance is that the server ID is not </del> <ins> If the sole reason for unroutability is that the server ID is not </ins> in the load balancer's table, the load balancer routes the packet <del> with an arbitrary algorithm.  It adds the decoded server ID to table entry for the server the algorithm chooses and forwards the packet accordingly. </del> <ins> with a fallback algorithm.  It adds the decoded server ID to table entry for the server the algorithm chooses and forwards the packet accordingly. </ins> 4.3.2.3.

The Block Cipher CID Algorithm, by using a full 16 octets of plaintext and a 128-bit cipher, provides higher cryptographic <del> protection and detection of non-compliant connection IDs.  However, it also requires connection IDs of at least 17 octets, increasing </del> <ins> protection and detection of unroutable connection IDs.  However, it also requires connection IDs of at least 17 octets, increasing </ins> overhead of client-to-server packets. 5.3.1.

connection attempts using any new QUIC versions that begin connections with a short header. <del> If a Retry Service is integrated with a QUIC-LB compliant load </del> <ins> If a Retry Service is integrated with a QUIC-LB routable load </ins> balancer, it can verify that the Destination Connection ID is <del> 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. </del> <ins> 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. </ins> 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 <del> in version 1) and dropping packets that are not compliant with the </del> <ins> in version 1) and dropping packets that are not routable with the </ins> QUIC specification. 7.2.

The maximum Connection ID length could be below the minimum necessary for one or more encoding algorithms. <del> non-compliant provides guidance about how load balancers should handle non-compliant DCIDs.  This guidance, and the implementation of an algorithm to handle these DCIDs, rests on some assumptions: </del> <ins> unroutable provides guidance about how load balancers should handle unroutable DCIDs.  This guidance, and the implementation of an algorithm to handle these DCIDs, rests on some assumptions: </ins> Incoming short headers do not contain DCIDs that are client- generated.

use with minimal risk of version- dependence. If these assumptions are invalid, this specification is likely to <del> lead to loss of packets that contain non-compliant DCIDs, and in extreme cases connection failure. </del> <ins> lead to loss of packets that contain unroutable DCIDs, and in extreme cases connection failure. </ins> Some load balancers might inspect elements of the Server Name Indication (SNI) extension in the TLS Client Hello to make a routing