Change:
Make sure each algorithm always provides 2-3 octets for server use. The current SID limits don't do that.

Discussion:
The configuration agent selects a length for the server ID encoding. This length MUST have enough entropy to have a different code point <del> for each server. </del> <ins> for each server.  The length MUST be no more than 15 octets to provide sufficient entropy for server use. </ins> It also assigns a server ID to each server.

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 <del> length and server ID length MUST sum to 19 or fewer octets. </del> <ins> 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. </ins> 4.3.2.

The server ID will start in the second octet of the decrypted connection ID and occupy continuous octets beyond that. <del> They server ID length MUST be no more than 16 octets and SHOULD be no more than 12 octets, to provide servers adequate space to encode their own opaque data. </del> <ins> The server ID length MUST be no more than 12 octets, to provide adequate entropy in the encrypted block. </ins> The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption.

connection ID length between 17 and 20 octets.  The server writes its provided server ID into the server ID octets and arbitrary bits into the remaining bits.  These arbitrary bits MAY encode additional <del> 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. </del> <ins> information, and MUST differ between connection IDs.  The encrypted arbitrary bits MUST be unique for each CID the server generates; the easiest way to do so is to start the nonce at zero and simply increment by one for each CID. Bits in the eighteenth, nineteenth, and twentieth octets SHOULD appear essentially random to observers.  The first octet is reserved as described in first-octet. </ins> The server then encrypts the second through seventeenth octets using the 128-bit AES-ECB cipher.

10.6. <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 Block Cipher CID and at least eight octets of the Stream Cipher CID are reserved for a nonce that, if used only once, will result in unique cipher text for each Connection ID. If servers simply increment the nonce by one with each generated connection ID, then it is safe to use the existing keys until any server's nonce counter exhausts the allocated space and rolls over to zero.  Whether or not it implements this method, the server MUST NOT reuse a nonce until it switches to a configuration with new keys. 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. 10.7. </ins> The Shared-State Retry Service defined in shared-state-retry describes the format of retry tokens or new tokens protected and encrypted using AES128-GCM.  Each token includes a 96 bit randomly

In order to protect against collisions, the 96 bit unique token numbers should be generated using a cryptographically secure pseudorandom number generator (CSPRNG), as specified in Appendix C.1 <del> of the TLS 1.3 specificationRFC8446.  With proper random numbers, if </del> <ins> of the TLS 1.3 specification RFC8446.  With proper random numbers, if </ins> fewer than 2^40 tokens are generated with a single key, the risk of collisions is lower than 0.001%.