Re: New Plaintext QUIC-LB Design

Dmitri Tikhonov <> Mon, 11 January 2021 22:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 000B13A1369 for <>; Mon, 11 Jan 2021 14:06:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 3Nn4eCG2H4IZ for <>; Mon, 11 Jan 2021 14:06:41 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 63DFF3A135F for <>; Mon, 11 Jan 2021 14:06:41 -0800 (PST)
Received: by with SMTP id w79so287603qkb.5 for <>; Mon, 11 Jan 2021 14:06:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=8QsuKXlH0sM46VGTvEr4wNe1Hj2cb6JEQG7IwVYd1ts=; b=G5PTSBw9Iv9FtN5xO2JFa5d782yEsClyL+WuKcrj4JCN0ISHZH+XUkBfosnvBN327V 9bVm3MaMN723AhZBXLIimiE0ccQKRFYVruaSVFJ7SRIoDKu0DMbwrc5pxwUV3KZ+x2K+ fWifvWMhdd/Rd3ghsCfwj+Dou2emrEtZCaPd7HZs/6AJDkyF8QT//lYhPe0T3O81HQNz fBMA73gMDfwdUXZJ8xa5CHvEKIEVZ8zQAdgtetvAbT5MonBmSzax9Pk+XekMhMHvn/Zz JWnm5iqClUEbWFqsG9x+DASJzepjRxgsM3/7h7rsi1WINCTMNsEK2rNzvEZsBho8bDwe Y2ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to; bh=8QsuKXlH0sM46VGTvEr4wNe1Hj2cb6JEQG7IwVYd1ts=; b=XpPdKqrJ04rYZvjApuUK59Kw86dSFimfMPUmpUaT++sEJfqg2e0Mc2qc2flOQQoC2N QtVzY6K/daLMPOa/RTXBBcnI+d9ayQc2vOGmmIuR/1YNwT9h/LdAGvPPJyC7Scc6eJIi rR66UBMJxOQOr/gIbGYexEwXULpylnktmYrUIKvDqN0hwa5advEVSmgD+ZJfB9UgPz9V 7YQA3gOvca6PWcVsB7AC1y9QM/u3QIcstuEkbRnqzlKiker+Z8xPGdaGTHuJ6Oc87vfj 0xxbvnT4myK25n9M3Svuk4M0Rf0s58M4Ic+0f7xwb4uLvBOy7qFAz5Z88u5OGh2pZuDg C3nA==
X-Gm-Message-State: AOAM530PgQ5nGyi1/0faC6nUY+dWMiXYp3HUQBWiNfZ5FnQSaueWby8v G/0m0jJkE2xzXTNpER3Pd+rnT0Atu8W9mA==
X-Google-Smtp-Source: ABdhPJwksH3zSyYCxWocTFuPK2a7EwtlSh1RkLUT2qSwBMs60MNZAmHFBT002URQp2BwN0VJrWPjiA==
X-Received: by 2002:a37:6810:: with SMTP id d16mr1471195qkc.194.1610402799897; Mon, 11 Jan 2021 14:06:39 -0800 (PST)
Received: from okhta ( []) by with ESMTPSA id a206sm569280qkc.30.2021. for <> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Jan 2021 14:06:39 -0800 (PST)
Date: Mon, 11 Jan 2021 17:06:33 -0500
From: Dmitri Tikhonov <>
Subject: Re: New Plaintext QUIC-LB Design
Message-ID: <20210111220633.GA698997@okhta>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
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: Mon, 11 Jan 2021 22:06:43 -0000

Hi Martin,

On Mon, Jan 11, 2021 at 01:40:41PM -0800, Martin Duke wrote:
> Ian proposed a radical new plaintext CID algorithm for for quic-lb. I
> already merged it into the draft alongside the current one, to make things
> clearer. See Section 4.2 of the draft
> <>.
> I suspect this may not be the final result, but this is another one of
> those value judgments I'd like input on.

This is the correct link:

> As a practical matter, Ian's proposal is also an easier transition path for
> Google's load balancers, and presumably others as well. Their
> implementation experience suggests that the memory load is manageable.

Well, then it looks like they are going to do it anyway, so you might as
well put it into the draft!

> *So we have three options*:
> 1) Stick with PCID and ditch this.
> 2) Replace PCID with this proposal.
> 3) Have two standard unencrypted algorithms to capture the tradeoff -- I
> would prefer not to complicate things in this way unless there is real
> disagreement about how to resolve the tradeoffs.

In a bit of synchronicity (may the force be with you!), I was reading the
LB I-D just as your email arrived.  I vote for option (3): the two PCID
can coexist in the document.

  - Dmitri.