Change:
Writing it, I'm not sure that this makes anything conceptually clearer, but I'm open to merging it.
The clear text stream cipher and block cipher formats are specified as: I think that this difference is not necessary. In the block cipher format, the first bytes are effectively used as a nonce: using the same value and the same server ID would result in the same initial 16 bytes, with exactly the same privacy effect as failing to properly initialize the nonce in the stream-cipher case. I wish we could unify these two formats, to: With just three parameters: The scope of encryption would be 0 bytes for the clear text format, 16 bytes for the block cipher format, and a value greater than server-ID length and lower than the length of the CID for the stream cipher format. This will of course require that the first bytes of the server-use field act as a nonce. Alternately, we could have: Which achieves the same unification result, but is maybe a bit more explicit.
I think this would simplify things, yes. Though it might be worth it to separate the server-use bit into a nonce and server-use, since one has uniqueness constraints and one doesn't.
Thinking of that a bit more, it is possible to further simplify. In the case of the stream cipher, the "nonce" part cannot be more than 16 bytes long. This means that the nonce will include: All of the "server-use" bytes if the are fewer than 16 such bytes The initial 16 bytes of the "server use" field if there are more With that, for all schemes we will require just two parameters, the length of the SID and the length of the CID. This simplifies configuration and APIs. At that point, the "nonce" requirement is not particularly onerous. There is already an operational requirement that CID as a whole be unique -- conflicting values would lead to packets delivered to the wrong context. If we use "all the bytes" then the server-use field is effectively a nonce. The requirement only applies to the cases where the server use field is larger than 16 bytes. We can mention it, the same way we should mention it for the block cipher. There is a small technical weakness, because the uniqueness of the CID could also result from the randomness of the first byte. This could be fixed by using the first byte in the encryption passes: use first-byte + server ID when encrypting the nonce if the server ID is fewer than 16 bytes. (Is there really a use case for a 16 bytes server ID? Would 15 bytes be sufficient?)
I like how this is developing. I should clarify that the "CID length" is actually the minimum length of the CID -- that's all the LB will look at. The server can pad it out to 20B but that's not relevant to the algorithm. Regarding the first byte: if using length-self-encoding, there will be little or not entropy there. I don't think the case for a 16B SID is compelling.

Discussion:
these allocations time out and are freed for reuse by servers that have recently joined the pool. <ins> 4.4. All connection IDs use the following format: Each configuration specifies the length of the Server ID and Nonce fields, with limits defined for each algorithm. 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. 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 configuration parameters.  Limits on the length of the nonce are different for each algorithm. 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. 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. </ins> 5. Encryption in the algorithms below uses the AES-128-ECB cipher.

5.1. The Plaintext CID Algorithm makes no attempt to obscure the mapping <del> of connections to servers, significantly increasing linkability.  The format is depicted in the figure below. </del> <ins> of connections to servers, significantly increasing linkability. </ins> 5.1.1. For static SID allocation, the server ID length is limited to 16 <del> octets.  There are no parameters specific to this algorithm. </del> <ins> octets.  The nonce length MUST be zero. </ins> 5.1.2.

When a server needs a new connection ID, it encodes one of its assigned server IDs in consecutive octets beginning with the second. <del> All other bits in the connection ID, except for the first octet, MAY be set to any other value.  These other bits SHOULD appear random to observers. </del> 5.2.

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

5.3.1. <del> If server IDs are statically allocated, the server ID length MUST be no more than 12 octets, to provide servers adequate entropy to generate unique CIDs. </del> <ins> The server ID length MUST be no more than 12 octets.  The server ID length and nonce length MUST sum to exactly 16 octets. </ins> The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption.

5.3.3. <del> When generating a routable connection ID, the server MUST choose a connection ID length between 17 and 20 octets.  The server writes its server ID into the server ID octets and arbitrary bits into the remaining bits.  These arbitrary bits MAY encode additional information, and MUST differ between connection IDs.  Bits in the eighteenth, nineteenth, and twentieth octets SHOULD appear essentially random to observers.  The first octet is reserved as described in first-octet. The server then encrypts the second through seventeenth octets using the 128-bit AES-ECB cipher. </del> <ins> The server encrypts both its server ID and a nonce in 16-octet block with the configured AES-ECB key. </ins> 6.

server ID allocation method, and the relevant parameters for that algorithm. <del> All algorithms require a server ID length.  If server IDs are statically allocated, the load balancer MUST receive the full table of mappings, and each server must receive its assigned SID(s), from the configuration agent. For Stream Cipher CID Routing, the servers and load balancer also MUST have a common understanding of the key and nonce length. </del> <ins> All algorithm configurations can have a server ID length, nonce 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. </ins> <del> For Block Cipher CID Routing, the servers and load balancer also MUST have a common understanding of the key. </del> <ins> If server IDs are statically allocated, the load balancer MUST receive the full table of mappings, and each server must receive its assigned SID(s), from the configuration agent. </ins> Note that server IDs are opaque bytes, not integers, so there is no notion of network order or host order.