QUIC Invariants and QUIC-LB

[Martin Duke <[e-mail]>]

TL;DR We are trying to make QUIC-LB as independent of QUIC version as
possible, but there are a few gaps in the invariants that make that harder.
If any of these are oversights, it would be great to add it to the
invariants.

*******
A few draft versions ago we did a pass on QUIC-LB to make it truly
QUIC-version invariant, except for the Retry Services portion.

After a little more thought, I added this section to the draft:
https://quicwg.org/load-balancers/draft-ietf-quic-load-balancers.html#name-version-invariance-of-quic-
which describes a bunch of QUIC behaviors that are not explicitly described
in the invariants draft, but that if changed might cause QUIC-LB not to be
fully robust to new versions. An obvious one is a version that described a
maximum CID length too small for some of the encodings.

A more subtle one is the handling of "non-compliant CIDs" (Sec 4). These
are CIDs that are (1) too short for the configured algorithm, (2) fail
authentication, or (3) don't map to a valid server ID. In v1, these will
only occur in the client's first flight of Initial and 0RTT packets. The
rules we have for version-independent LBs to process packets with
non-compliant CIDs are as follows:
* if a short header, drop it.
* if a long header, use any hash algorithm that will consistently get you
the same result over short time scales (i.e. a couple of RTTs, by which
time a server-generated CID will be in use)
Compliant CIDs are always processed using the decoding in the spec.

There are some assumptions baked into this advice.
(1) Short headers never contain client-generated CIDs. [QUIC-LB servers
will always provide new CIDs when given the opportunity, but a new version
could have short 0RTT headers or something]
(2) Use of client-generated DCIDs is limited to a few RTTs at most (any
more and you run the risk of the number of servers changing in this
interval, which will generally cause the hash to get a different result)
(3) There's a bunch of stuff that remains constant in the packet headers
over this short interval. I probably need to tighten up the language on
what is a suitable input for the LB's hash, but in v1 you're currently safe
using some combination of Client IP, Client Port, SCID, and DCID. If there
of these that we're willing to lock down in the invariants, I could rewrite
the guidance accordingly.

For example, if the invariants could include a statement like "A client
will use no more than one DCID that it didn't receive from the server",
that would simplify the problem space.

****

I'm fine with having this text in the QUIC-LB draft, if need be, but if
there are things that should be in the invariants but we didn't think about
them, that would be even better.

Martin