The current prototype when validates client generates a random connection ID which client should use as destination connection id for its next retry request which will contain a validation token. Server does make sure the random connection id is not used before it sends it back to client. The idea is the server should respond with connection reset to client which uses colliding destination connection ID and comes as the second.
again the devil is in detail here: how we tell difference between collision and delayed/retrasnmitted retry packet?
perhaps the best answer is let's don't bother. It is fine to do nothing and let colliding client to time out.
This issue refers to draft PR #25842.
The current prototype when validates client generates a random connection ID which client should use as destination connection id for its next retry request which will contain a validation token. Server does make sure the random connection id is not used before it sends it back to client. The idea is the server should respond with connection reset to client which uses colliding destination connection ID and comes as the second.
again the devil is in detail here: how we tell difference between collision and delayed/retrasnmitted retry packet?
perhaps the best answer is let's don't bother. It is fine to do nothing and let colliding client to time out.