Draft: draft-ietf-quic-load-balancers

Commentary: Fixes 
 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 ) , I just think that there is no need for quic lb considering sni
Retry services MUST forward all non-Initial QUIC packets, as well as
Initial packets from the server.
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
is underway.  The choice of mode MAY be made on a per-packet basis,
through a stochastic process or based on client address.
A retry service MUST forward all packets for a QUIC version it does
not understand.  Note that if servers support versions the retry
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.
The no-shared-state retry service requires no coordination, except
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').
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.
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
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.
A retry service MUST forward all packets for a QUIC version it does
not understand.  Note that if servers support versions the retry
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.
The no-shared-state retry service requires no coordination, except
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').
The configuration agent distributes a list of QUIC versions to be
served by the Retry Service.
A server behind a non-shared-state retry service MUST NOT send Retry
packets.
A server behind a non-shared-state retry service MUST NOT send Retry
packets for a QUIC version the retry service understands.  It MAY
send Retry for QUIC versions the Retry Service does not understand.
ODCIL: The original destination connection ID length.  Tokens in
NEW_TOKEN frames SHOULD set this field to zero.
ODCIL: The original destination connection ID length.  Tokens in
NEW_TOKEN frames MUST set this field to zero.