Re: QUIC Invariants and QUIC-LB

Ian Swett <> Thu, 21 May 2020 14:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A42D63A09D9 for <>; Thu, 21 May 2020 07:31:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Io-AHm1zuMVQ for <>; Thu, 21 May 2020 07:31:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A53373A09A2 for <>; Thu, 21 May 2020 07:31:43 -0700 (PDT)
Received: by with SMTP id m12so5767860wmc.0 for <>; Thu, 21 May 2020 07:31:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IENYFnBe4gG6KnDhV6rWc1m1V5DOVHZxDvDG9cMzRrA=; b=oHqqQptazd7MD6CAObgQnlX8WbjHf5eM4A/rA4KFLkNPBCgQVW0fF82zXeagbm869e zxVUubSEH8jsxsvIemPfZo5EiEpqsObFafib9rG8anfBIlGbYXLlTRYuX8CNdpsmS4Uh Wz35mm7qdb9GUerd+pnBl+dCoryDz2ZVGeg8VMF7f4XOg1tcMVrzzPxXQ/IcNZzurXZP 9KvFlfNBjQfqXJudLqIocV8gfZHDnFbPVnlnotZZIXPbQxgOUCqU3ht2LRLMAV33pj0p LDtyHOxTEnMKO0MrerPrKy++PgHZk3k/Kv5WMRxpUf67tSU5oQBbRt1ddnRbEAcgaLeo TnsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IENYFnBe4gG6KnDhV6rWc1m1V5DOVHZxDvDG9cMzRrA=; b=tLmzXEs6BoFE62y+KFj+/Me/LP/g0ICnDOTQ0Wq0SX4YQTVJtS4j/j29LBLv4RkJj5 iEO8Pr37fwHlKMEbyi7JHZLBWzqIvOnTUBfotDGDr2AoGDnxrL9n+yxAGbqQkWqLB2Ly sW47lnUSjGTpqy1ypc8DatA1k1u9BNuT/TRfyOWmxbWVmbexPNJeNO2VdzRNDxQNoLk4 F0ZVTwCUXxmvwMz8O3s1Pk0GK8KwcgvqtIovpN2y1JKM4L7xKjn25HaqHdWwHPgwIzFB 8G5dWWU0bOrY6pEQ7FOahpMchaO9bXX7dROijO5S/ASDnn2gxtI0yADIiM268hkH6Is7 MaWQ==
X-Gm-Message-State: AOAM532nsQDY4b7v5CJSjJotaF2dRkNtWTISNvfK1w9kloQ9QSoPz4WC UttC+cLI1ygzQDn/ZaGKyUcCl+j8Ohjpjhq+71/kKQ==
X-Google-Smtp-Source: ABdhPJxgak6wofQWiAfxFCGzJ3W6AQM+i5DtT6fSp0Xz4O+80fY+Q+nBM7Y46MBLvyThmmcbFNoleg2rG+H91k6FL30=
X-Received: by 2002:a1c:541e:: with SMTP id i30mr9068024wmb.120.1590071501939; Thu, 21 May 2020 07:31:41 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ian Swett <>
Date: Thu, 21 May 2020 10:31:28 -0400
Message-ID: <>
Subject: Re: QUIC Invariants and QUIC-LB
To: Martin Duke <>
Content-Type: multipart/alternative; boundary="0000000000000af7e105a6295f3a"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 May 2020 14:31:46 -0000

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