Change:
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.

Discussion:
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.