Change:
the server no longer has discretion to lengthen the CID. Also, the algorithms are more aligned so there has to be less unique text associated with each algorithm.
In any given deployment, the server use length should be consistent. The load balancer doesn't strictly need to know what it is, but obviously not doing this will lead to observable correlations.
As we've generalized the concept of a nonce, we should abolish the concept of "server use" and make it all a nonce. If the servers need to use the same length to prevent linkability, best to make it part of the configuration.

Discussion:
NEW_CONNECTION_ID frames with new values. A load balancer that sees a connection ID with config rotation bits <del> set to '11' MUST revert to 5-tuple routing. </del> <ins> set to '11' MUST revert to 5-tuple routing.  These connection IDs may be of any length; however, see cid-entropy for limits on this length. </ins> 3.3.

All connection IDs use the following format: Each configuration specifies the length of the Server ID and Nonce <del> fields, with limits defined for each algorithm. </del> <ins> fields, with limits defined for each algorithm.  When using a given configuration, the server MUST generate CIDs of length equal to the lengths of these three fields. </ins> The Server ID is assigned to each server in accordance with sid- allocation.  Dynamically allocated SIDs are limited to seven octets or fewer.  Statically allocated ones have different limits for each algorithm. <ins> The configuration agent assigns a server ID to every server in its pool, and determines a server ID length (in octets) sufficiently large to encode all server IDs, including potential future servers. </ins> The Nonce is selected by the server when it generates a CID.  As the name implies, a server MUST use a nonce no more than once when generating a CID for a given server ID and unique set of <del> configuration parameters.  Limits on the length of the nonce are different for each algorithm. </del> <ins> configuration parameters. </ins> <del> The First Octet, Server ID, and Nonce comprise the minimum length Connection ID for any given algorithm.  The load balancer need not know the full connection ID length to successfully process a packet, given that it is of minimum size. </del> <ins> The nonce length MUST be at least 4 octets.  Additional limits on its length are different for each algorithm.  See cid-entropy for limits on nonce generation. </ins> <del> The For Server Use field has any value and length chosen by the server, within the connection ID length limits in the operative QUIC version.  It SHOULD appear random and SHOULD NOT link two connection IDs to the same connection, or indicate they originate from the same server. </del> <ins> As QUIC version 1 limits connection IDs to 20 octets, the server ID and nonce lengths MUST sum to 19 octets or less. </ins> 5.

5.1.1. <del> For static SID allocation, the server ID length is limited to 16 octets.  The nonce length MUST be zero. </del> <ins> See cid-format. </ins> 5.1.2. On each incoming packet, the load balancer extracts consecutive octets, beginning with the second octet.  These bytes represent the <del> server ID. </del> <ins> server ID.  It ignores the nonce. </ins> 5.1.3. <del> The server chooses how many octets to reserve for its own use, which MUST be at least one octet. </del> When a server needs a new connection ID, it encodes one of its <del> assigned server IDs in consecutive octets beginning with the second. </del> <ins> assigned server IDs in consecutive octets beginning with the second and chooses a nonce.  This nonce MUST appear to be random (see cid- entropy). </ins> 5.2.

5.2.1. <del> The configuration agent assigns a server ID to every server in its pool, and determines a server ID length (in octets) sufficiently large to encode all server IDs, including potential future servers. The nonce length MUST be no fewer than 4 and no more than 16 octets. </del> <ins> The nonce length MUST be no fewer than 4 octets. </ins> <del> The server ID length and nonce length MUST sum to 19 or fewer octets, and SHOULD sum to 15 or fewer octets to allow space for server use. </del> <ins> The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption. </ins> 5.2.2.

When generating a routable connection ID, the server writes arbitrary bits into its nonce octets, and its provided server ID into the <del> server ID octets.  Servers MAY opt to have a longer connection ID beyond the nonce and server ID.  The additional bits MAY encode additional information, but SHOULD appear essentially random to observers. If the decrypted nonce bits increase monotonically, that guarantees that nonces are not reused between connection IDs from the same server. </del> <ins> server ID octets.  See cid-entropy for nonce generation considerations. </ins> The server encrypts the server ID using exactly the algorithm as described in stream-cipher-load-balancer-actions, performing the

5.3.1. <del> The server ID length MUST be no more than 12 octets.  The server ID length and nonce length MUST sum to exactly 16 octets. </del> <ins> The server ID length MUST be no more than 12 octets.  The nonce and server ID MUST sum to at least 16 octets. </ins> The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption.

octet to obtain the config rotation bits.  It then decrypts the subsequent 16 octets using AES-ECB decryption and the chosen key. <del> The decrypted plaintext contains the server id and opaque server data in that order.  The load balancer uses the server ID octets for routing. </del> <ins> The first octets of the plaintext contains the server id. </ins> 5.3.3. <del> The server encrypts both its server ID and a nonce in 16-octet block with the configured AES-ECB key. </del> <ins> The server encrypts both its server ID and enough octets in a nonce to form a 16-octet block using the configured AES-ECB key.  Note that any remaining octets in the nonce are transmitted as plaintext, and should consider the constraints in cid-entropy. </ins> 6.

algorithm. All algorithm configurations can have a server ID length, nonce <del> length, and key.  However, for Plaintext CID, the key is not used and the nonce length is always zero.  For Block Cipher CID, the nonce length is directly computed from the server ID length. </del> <ins> length, and key.  However, for Plaintext CID, there is no key. </ins> If server IDs are statically allocated, the load balancer MUST receive the full table of mappings, and each server must receive its

11.6. <ins> If a server ever reuses a nonce in generating a CID for a given configuration, it risks exposing sensitive information.  Given the same server ID, the CID will be identical (aside from a possible difference in the first octet).  This can risk exposure of the QUIC- LB key.  If two clients receive the same connection ID, they also have each other's stateless reset token unless that key has changed in the interim. </ins> The Stream Cipher and Block Cipher algorithms need to generate different cipher text for each generated Connection ID instance to protect the Server ID.  To do so, at least four octets of the CID are

zero.  Whether or not it implements this method, the server MUST NOT reuse a nonce until it switches to a configuration with new keys. <del> Configuration agents SHOULD implement an out-of-band method to discover when servers are in danger of exhausting their nonce space, and SHOULD respond by issuing a new configuration.  A server that has exhausted its nonces MUST either switch to a different configuration, or if none exists, use the 4-tuple routing config rotation codepoint. </del> <ins> Both the Plaintext CID and Block Cipher CID algorithms send parts of their nonce in plaintext.  Servers MUST generate nonces so that the plaintext portion appears to be random.  Observable correlations between plaintext nonces would provide trivial linkability between individual connections, rather than just to a common server. For any algorithm, configuration agents SHOULD implement an out-of- band method to discover when servers are in danger of exhausting their nonce space, and SHOULD respond by issuing a new configuration. A server that has exhausted its nonces MUST either switch to a different configuration, or if none exists, use the 4-tuple routing config rotation codepoint. When sizing a nonce that is to be randomly generated, the configuration agent SHOULD consider that a server generating a N-bit nonce will create a duplicate about every 2^(N/2) attempts, and therefore compare the expected rate at which servers will generate CIDs with the lifetime of a configuration. </ins> 11.7.