Re: QUIC Invariants and QUIC-LB

Martin Thomson <> Fri, 22 May 2020 03:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3731E3A0AB1 for <>; Thu, 21 May 2020 20:12:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=M1RdArQp; dkim=pass (2048-bit key) header.b=HhPdu6Ay
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NrwgAMU7S6Aw for <>; Thu, 21 May 2020 20:12:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CA05E3A09FA for <>; Thu, 21 May 2020 20:12:06 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id F19B7B05 for <>; Thu, 21 May 2020 23:12:05 -0400 (EDT)
Received: from imap2 ([]) by compute2.internal (MEProxy); Thu, 21 May 2020 23:12:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=8wRhhtf12gcbV/JFVUKHOEr+Gjgpx7k fFA3uTZpQfZo=; b=M1RdArQp7I8WP9BKsKSs0emHXgPSi/Xy/AeEqhQ+AoEzBKj otYvc6F8gKHeMVI++f8NbLTXkNKsl6wP8FUv792qHXiHPx4cPFK2QFHAJJCN1DmN CXuglCh2a38WbBLymxlJrLOWSqIZV6fz445cYL2egDAtw99OzweXHgMNVpZPmInX esutdJKnPLRDHNdd8R5CASWRMKLGfPR7JNGHN/c6jrKjWqVpgRgUC4cZ6v466wCL ij4MwsKr48pzOe+7jbIZG10aOa1Kx1U3URtGHTsZZIgZg8BnXhIfndtVymeMTEg4 S0FqKX6EN5JwgxCXxrAXcc1VHuR2DprsePiHzlw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=8wRhht f12gcbV/JFVUKHOEr+Gjgpx7kfFA3uTZpQfZo=; b=HhPdu6Ayi4GXDl+IObxKp0 l1CmHpdLZp8DQDNR2tkdGDCJws60n/lY73Y0Vj89rHLTfpZStsZzUa9Ao2sndZw5 2LMHRN2FgGF1WtpQywjvzbhio+gixgBSZ/MPoFUbjj5fPnhZSzu+AJYefp2qMXRe gtRXa7N+phWDNx2TyFyRb0xubC7770TZweGpCzmw04D14YgvkWY7T6rVxbgCXsVT hVH63eazwoUBooKjeB/1q18BKKAPDUa1VPZr163tNB8i1cm5+xuzUOCjwotaX9WJ PGdQcoa16EO5vgGQQcsKcGb95f+T4lwHt1rPdFc5jyPCYXnQuev/Asbc9GaMs7LQ ==
X-ME-Sender: <xms:BUPHXmNCTssdS4S43zL8QoQcHsweXZEPQo7lS2nVaRwvOXi1VbBA-Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudduvddgieehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht
X-ME-Proxy: <xmx:BUPHXk9SMTWqcnU_IEJ1rVXhBHxlOl71jcloePqtQUCQ3_wxO1CoeA> <xmx:BUPHXtRdJ1DRuJtVlKucxNFfYo4v69NSxpCo6whnV3P5oXZh2TYnRQ> <xmx:BUPHXmvXYhtkcqLrn4obAxRsf95VMkb0P2oZkX3pyJIpCgvzec5Mdg> <xmx:BUPHXt-tEU4NT-rvzgYOLbPdkzYuK3Dk3wXse4vgjoDmN2MmQKgzpg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4B334E00B3; Thu, 21 May 2020 23:12:05 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-487-g38013f6-fm-20200519.001-g38013f6c
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <>
Date: Fri, 22 May 2020 13:11:47 +1000
From: "Martin Thomson" <>
Subject: Re: QUIC Invariants and QUIC-LB
Content-Type: text/plain
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 03:12:09 -0000

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.


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.