Original text:
The DCID might not be long enough for the routing algorithm to process.  The extracted server mapping might not correspond to an active server. Load balancers SHOULD drop packets with non-compliant DCIDs in a short header.  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

Reviewer comments:
Make it clear that the server has to provide the client with a compliant DCID if the client isn't already using one.
Dear sir, As you know, there is no bit in the cid to mark whether the cid encoded the server info or not. In this case, no matter the server info encoded or not, the load balancer needs to decrypt or decode the cid. Do you think this is a useless try when the packet is the first initial packet? Do you think this is a useful idea to expand the cid format to use the first bit to mark the cid encoded or not? However, in this case, the client need to obey the rule.
In fact, there is a bit. If the first two bits are '11' that means that the server didn't encode its ID and the load balancer should use 4-tuple routing: URL The very first packet usually has a CID chosen by the client, which knows nothing about QUIC-LB. The beginning of Section 4 is mostly about how load balancers should handle these.
OK, I almost have forgot the first two Config Rotation bits can be used to mark the cid server info's validity. However, in this case, I want to know , for the very first packet, will the draft suggest the clients to generate the dcid with the first two bits "11" , if they know the QUIC-LB used. As, if so, the QUIC-LB know all packets' cid information to prevent useless decode/decrypt try for the very first packet.
No, this draft does not assume client cooperation at all. The very beginning of Section 4 explains how to handle client-generated CIDs.
Thanks for your reply. Actually, I understand your works and Section 4. However, my point is that , even this draft does not assume client cooperation at all, this draft can suggest the client to generate a cid with 11 for the very first initial packet. This is useful for QUIC-LB if client obeys the rule, if not , the Section 4 also works well.
In I'm adding CR bits as a reason for noncompliance. It's fine if the client wants to set '11' , but I don't think it's important to do that. At most all we're saving the LB is a very small decrypt operation.
Even thought the decryption has a low consumption, I insist that the cost can be avoided. I admit that the lb can't assume client cooperation at all, however, the draft can suggest the client to obey the rule: " As, it is impossible for the client to know the server information at the beginning of the QUIC conn, so the DCID in the initial can't encode the server info, in this case, the Client should make the first two bits with "11". "

Revised text:
The DCID might not be long enough for the routing algorithm to process. <ins> The config rotation bits config-rotation may not correspond to an active configuration. </ins> The extracted server mapping might not correspond to an active server. Load balancers SHOULD drop packets with non-compliant DCIDs in a short header. <ins> 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 CID in the Source CID field of server-generated long headers. </ins> 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