Draft: draft-ietf-quic-load-balancers

Commentary: THe addition to the first paragraph here seems necessary . The basic idea is that if a QUIC version violates the ( reasonable ) assumptions this section makes , then it just does n't work if you try to apply this design . You will need to update your load balancer and probably update the CID allocation / negotiation / configuration you are using . The second paragraph I 'm less sure about . I think that the intent was to say that if you follow the advice here you still get a functioning system even if the load balancer gets it wrong . So I said that . I think that I agree , provided that the tenant ( new term ? ) chooses a good connection ID for any new ones . So that 's not just Section 3.1 you need to refer to , but the whole document . 
 So what I 'm trying to say at the end of the second paragraph is this : 1 ) Say , for example you have a LB that routes the Client Inital by SNI 2 ) For other packets , it uses a QUIC - LB config with 8B CIDs . 3 ) A client Initial arrives to with an ( unknown ) QUIC version 4 ) This initial also has an 8B CID that accidentally happens to route to a tenant 5 ) Since the LB ca n't read the CHLO , it ends up using the CID to route and things fail . Maybe you got all that from the text , but I 'm making sure . This scenario is n't great but also is n't any worse than the pre - QUIC - LB status quo . shrug Still , your editorial change makes things clearer .
If these assumptions are not valid, this specification is likely to
lead to loss of packets that contain unroutable DCIDs, and in extreme
cases connection failure.
Some load balancers might inspect elements of the Server Name
Indication (SNI) extension in the TLS Client Hello to make a routing
decision.  Note that the format and cryptographic protection of this
information may change in future versions or extensions of TLS or
QUIC, and therefore this functionality is inherently not version-
invariant.  See also unroutable for other considerations about this
case.  Note that an SNI-aware load balancer, faced with an unknown
QUIC version, might misdirect initial packets to the wrong tenant.
While inefficient, this preserves the ability for tenants to deploy
new versions provided they have an out-of-band means of providing a
connection ID for the client to use.
If these assumptions are not valid, this specification is likely to
lead to loss of packets that contain unroutable DCIDs, and in extreme
cases connection failure.  A QUIC version that violates the
assumptions in this section therefore cannot be safely deployed with
a load balancer that follows this specification.  An updated or
alternative version of this specification might address these
shortcomings for such a QUIC version.
Some load balancers might inspect version-specific elements of
packets to make a routing decision.  This might include the Server
Name Indication (SNI) extension in the TLS Client Hello.  The format
and cryptographic protection of this information may change in future
versions or extensions of TLS or QUIC, and therefore this
functionality is inherently not version-invariant.  Such a load
balancer, when it receives packets from an unknown QUIC version,
might misdirect initial packets to the wrong tenant.  While this can
be inefficient, the design in this document preserves the ability for
tenants to deploy new versions provided they have an out-of-band
means of providing a connection ID for the client to use.