Re: QUIC Invariants and QUIC-LB

[Ian Swett <[e-mail]>]

Thanks for pointing these out.  To me, these constraints seem like natural
consequences of using QUIC with a load balancer.  But there are use cases
for QUIC where a load balancer isn't required(ie: P2P and many datacenter
use cases), so I'd prefer not to add more constraints to the invariants.

On Wed, May 20, 2020 at 7:28 PM Martin Duke <[e-mail]> wrote:

> 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
>