Re: QUIC Invariants and QUIC-LB

Martin Duke <> Fri, 22 May 2020 15:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D1A463A0B96 for <>; Fri, 22 May 2020 08:52:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 qPx93bpycUIj for <>; Fri, 22 May 2020 08:52:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2384B3A0B95 for <>; Fri, 22 May 2020 08:52:55 -0700 (PDT)
Received: by with SMTP id 18so11152725iln.9 for <>; Fri, 22 May 2020 08:52:55 -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=/1LFp5K1MGapkgLIjGcn60Yfyq+g6lEIxa6jafLMJCw=; b=lqKPoRbzYTn3RYLME6ZlOLnT5UJWoKiux9LXVm4mQ2EKiQw6I5PEJBxX0xvXkBWUiw TP0HAngD7Quxir4b+Af2OUznIcbHXyIjW2gecD/yTMn8+8BXUr2PAIRTXuWlv6VijieC iasIjxcMBObVGbCeoVOzjMr031Pl2DZvBNv0e3sZeMHoaobFFknMgy0GeF98qzWfrlb5 XhkWtT4Ler58UXXbMm+Xzcoegi8jMouTo7uK4Fb1Or4/+5i5OK1ofFBvfZWh76iJKMBc 10Y80cTZOw282NinAf2rSHJCpJLp+1sIKr6G7+qVKR/STxU1Lne9glOZVdSAus+DSODw 6aCA==
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=/1LFp5K1MGapkgLIjGcn60Yfyq+g6lEIxa6jafLMJCw=; b=V0uWVc/I9+Imw5Ry05GN3JIKxfN9NaUpB7bc3/bc0AecHG5JDw9PptuKewcES3DhrJ BieKQPS1YvPFWFeOccRyBEk+td6U0mv2CEufrDYMG6k+26rflsu1a61XSysHKdqSC9UD SXW0y09D7xA5sZTYWilHSwc/bH95JEnf0DPGHWtibBdnpGqTYoxsc/jY60oGZ9mJUTby JZCSCLsIyMlwRQoNG9Zn853XSxc8urqLGGRotAkYOWCYUObPgAE6y0fc6KkF5ZY9f8XT WCH7d/1i8bBcZ4Y0NvEILHahVCmAN1gE/f+xxv9d9vPFty5/7w8AzuW4m/ri0MtMlGD+ c9/g==
X-Gm-Message-State: AOAM5304JrvX4OQUna7a0rmw2U/1+c83naF8SGG8VJSU9rm68y3QGS4i AJonr5FGDV1ev41/aKISoGKgmFwRgz4UWfWDmRI=
X-Google-Smtp-Source: ABdhPJxhUQ9e13don9l/1M7HijrNZGqJIcANfMxItuc0C+R4+3qNBt38G1uR68BhUlICvqmlrra3MAfYyFDOq3S8FvE=
X-Received: by 2002:a92:5c89:: with SMTP id d9mr14126023ilg.237.1590162772474; Fri, 22 May 2020 08:52:52 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Martin Duke <>
Date: Fri, 22 May 2020 08:52:39 -0700
Message-ID: <>
Subject: Re: QUIC Invariants and QUIC-LB
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary="000000000000351ed305a63e9fa9"
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: Fri, 22 May 2020 15:52:57 -0000

Filed to use Martin's
recommendation on fields likely to be stable.

On Thu, May 21, 2020 at 8:12 PM Martin Thomson <> wrote:

> On Fri, May 22, 2020, at 10:00, Martin Duke wrote:
> > I don't think we're going to get a 100% version-invariant QUIC-LB,
> > though we're pretty close.
> Yep.
> Based on this discussion, what I think is happening here is that we're
> defining a new set of invariants: the set of things that we can't really
> change between versions that support the same load balancers as QUIC
> version 1.  That this is a superset of the invariants work is a bit
> unfortunate, but the difference is small enough.
> > It would be nice to give LBs somewhat more specific guidance for what
> > fields they can use for packets with non-compliant DCIDs. For example,
> > if we could at least safely assume the DCID won't change until the
> > server provides one, that would be way better than forcing them to make
> > assumptions about IP and UDP fields remaining stable.
> Based on invariants + LB-invariants, I think that you have some good
> advice already:
> If you didn't create the DCID, then apply some sort of "default" routing.
> That routing will rely on the stability of a subset of fields.  I would
> select from (source IP, source port, destination IP, destination port,
> DCID) and no others.  Nothing else in the QUIC packet is good, except
> *perhaps* the version number.  Without understanding the version, SCID is
> totally out as it isn't guaranteed to be stable.  Add anything that isn't
> stable and you might get problems, so while I can see a case for including
> something like the IPv6 flow label, that's risky.
> Generally speaking, it should be enough to route based on DCID alone, or
> to route just on the source address, but the more (stable) fields you
> include the more you allow concurrent connection attempts from the same
> address.
> Finally, to speak to the first assumption, if it is a short header, and
> you decide to use the DCID for routing, then you are OK throwing the packet
> away, because you don't know how long the DCID is.  Similarly, if the DCID
> is empty and you need it, then throwing it out is justified.  But you can
> do QUICv1 without either if you only use addressing information, so that
> wouldn't need to be the same for every load balancer.