Change:
Fixes URL
Some load balancers today switch based on the SNI. Obviously, this is not version-invariant. We should add some language about this. What should such an LB when it encounters an unknown version? It probably has no choice but to forward it based on CID and hope for the best.
If the differing domains trust each other, the servers could helpfully generate Retry packets to redirect the client to the right place. This assumes a bunch of shared state, and that those servers support the same version while the LB does not. Of course, if version support differs, the VN process has serious problems.
Maybe encrypt sni will be the real standard later(see URL), I just think that there is no need for quic lb considering sni

Discussion:
imposes other operational constraints.  The other requires shared key, but has no such constraints. <del> Retry services MUST forward all non-Initial QUIC packets, as well as Initial packets from the server. </del> <ins> Retry services MUST forward all QUIC packets that are not of type Initial or 0-RTT.  Other packets types might involve changed IP addresses or connection IDs, so it is not practical for Retry Services to identify such packets as valid or invalid. </ins> 5.1. Regardless of mechanism, a retry service has an active mode, where it is generating Retry packets, and an inactive mode, where it is not, based on its assessment of server load and the likelihood an attack <del> is underway.  The choice of mode MAY be made on a per-packet basis, through a stochastic process or based on client address. </del> <ins> is underway.  The choice of mode MAY be made on a per-packet or per- connection basis, through a stochastic process or based on client address. </ins> A retry service MUST forward all packets for a QUIC version it does not understand.  Note that if servers support versions the retry <del> service does not, this may unacceptably increase loads on the servers.  However, dropping these packets would introduce chokepoints to block deployment of new QUIC versions.  Note that future versions of QUIC might not have Retry packets, or require different information. </del> <ins> service does not, this may increase load on the servers.  However, dropping these packets would introduce chokepoints to block deployment of new QUIC versions.  Note that future versions of QUIC might not have Retry packets, require different information in Retry, or use different packet type indicators. </ins> 5.2. The no-shared-state retry service requires no coordination, except <del> that the server must be configured to accept this service.  The scheme uses the first bit of the token to distinguish between tokens from Retry packets (codepoint '0') and tokens from NEW_TOKEN frames (codepoint '1'). </del> <ins> that the server must be configured to accept this service and know which QUIC versions the retry service supports.  The scheme uses the first bit of the token to distinguish between tokens from Retry packets (codepoint '0') and tokens from NEW_TOKEN frames (codepoint '1'). </ins> 5.2.1. <ins> The configuration agent distributes a list of QUIC versions to be served by the Retry Service. 5.2.2. </ins> A no-shared-state retry service MUST be present on all paths from potential clients to the server.  These paths MUST fail to pass QUIC traffic should the service fail for any reason.  That is, if the

Retry tokens generated by the service MUST have the format below. <del> The first bit of retry tokens generated by the service must be zero. </del> <ins> The first bit of retry tokens generated by the service MUST be zero. </ins> The token has the following additional fields: ODCIL: The length of the original destination connection ID from the

normal QUIC signal to the client that there is an unauthorized man in the middle. <del> 5.2.2. </del> <ins> 5.2.3. </ins> A server behind a non-shared-state retry service MUST NOT send Retry <del> packets. </del> <ins> packets for a QUIC version the retry service understands.  It MAY send Retry for QUIC versions the Retry Service does not understand. </ins> Tokens sent in NEW_TOKEN frames MUST have the first bit be set to '1'.

The tokens have the following fields: ODCIL: The original destination connection ID length.  Tokens in <del> NEW_TOKEN frames SHOULD set this field to zero. </del> <ins> NEW_TOKEN frames MUST set this field to zero. </ins> Original Destination Connection ID: This is copied from the field in the client Initial packet.