Re: New Plaintext QUIC-LB Design

Martin Duke <> Mon, 11 January 2021 23:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BCEDF3A14FB for <>; Mon, 11 Jan 2021 15:32:14 -0800 (PST)
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 PAofCo1VcVyT for <>; Mon, 11 Jan 2021 15:32:13 -0800 (PST)
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 72A753A1413 for <>; Mon, 11 Jan 2021 15:32:13 -0800 (PST)
Received: by with SMTP id x15so1093933ilk.3 for <>; Mon, 11 Jan 2021 15:32:13 -0800 (PST)
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=oMpoOJVI7POKSrvrQBswHtNXLNa/vrjOCSzxCpGBl7U=; b=SfUVOgSgYBI30N6d0AsSNEaYO5MjgNprg5dCkwL5Laa45oh9/FGaGODMC+KF5ifIYF uBldrmethoYeelwjag7mLr6JtPyS4C2xJ5XbE9yk7pNzauCTebdUiHjQ8YMjsri/ZjjR EdnT9wATyibdblH9o/Nar0obgttFsjLJd1lbxDGP98MlS+5toTwGrP1uwDJeVppbFMsr qgQGxqHZFbP3YxMe7g2+QlMPIh9iAEz9iiEJ7v3WyIeTDsuvhGhFcc3xiFHJK8Jjfh9M tL4MYS8VTlNt6Na6URGGLi7ORntmCGE48l3o2aoAgYATpIAr9UPt/asJtHsgjSao+Qwq ZbHg==
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=oMpoOJVI7POKSrvrQBswHtNXLNa/vrjOCSzxCpGBl7U=; b=MLknBj6DLBRLPF3/cCPpsamPvIfwtlPyBxsswGKckZkLtMfnxdprrBZ4tzttevKuqZ ek9DETJbVV/B8MKfsJShZGD12jNekf8VA3JZP6Zwg1rQes5EUYAUIEGLtTt2Anw2dL26 ZOeW+BbfqBGBoD6iXBQfJ50hqQ/Vmbo1Wk4FpRN1Qf0tPWdfj/Qtu1Tq3PCwyVcOCHnb IthA3foEgY7EZ/vMaIZaToVqNSlnnrcJtU1b4WqWuigZF7CTzrX5AoT/vNK33cC0vK/Q G6i/HKkKVbceSLoAeVrBHfkFlAa+iZVOWacnTs15Gmws4Ci6r9DI3KKoBRPHIkM2j68T O4ww==
X-Gm-Message-State: AOAM531XEtpJoXeRIeE1Ozvvvn2ZkMRDlb/IdYug2M01HUVFTf1fGW3a 3rEIsAVSBrH7XXiX4zUHrQLctLDIGAy3xAduRa8=
X-Google-Smtp-Source: ABdhPJxqsZg6I+RUr+Azw7pYRCz7/TpmP7u+qdDMRTqMwbNoilAnCj8NiYTVY3j5+Pog7OywYetPucT9Y/zUc8xyvlA=
X-Received: by 2002:a92:da0f:: with SMTP id z15mr1279477ilm.287.1610407932726; Mon, 11 Jan 2021 15:32:12 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Martin Duke <>
Date: Mon, 11 Jan 2021 15:32:11 -0800
Message-ID: <>
Subject: Re: New Plaintext QUIC-LB Design
To: Mikkel Fahnøe Jørgensen <>
Content-Type: multipart/alternative; boundary="000000000000c613fb05b8a8507c"
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 23:32:15 -0000

Hi Mikkel,

Answers inline

On Mon, Jan 11, 2021 at 3:19 PM Mikkel Fahnøe Jørgensen <>

> I’m trying to read through the LB document that I haven’t looked at for
> quite a while. It isn’t very clear to me, I am sorry to say.
> I do not understand why the highest configuration value is chosen since
> this value would eventually wrap? Is there an implied wider config value
> where only the lower bits are visible, similar to packet numbers?

In general, client-generated CIDs might come in with config rotation bits
that don't correspond to an existing config. For the other algorithms, it's
randomly routed and after that the server-generated CID is used. But for
this algorithm, the server needs to extract a server ID somehow. If there's
one configuration, that's simple. If there's more than one, there has to be
deterministic behavior. The choice to use the highest is completely
arbitrary; I'm open to other suggestions that have better properties.

> Also, I do not understand how the server receives the assigned SID. Is the
> ODCID replaced in first packets, or are the packets unmodified, or is the
> SID prefixed the real packet?

No, any 8-byte CID will contain a server ID. So the client, in effect,
generates an SID and the load balancer decides which server will get it
(and then use that SID in the future)

> If the ODCID is modified, what about message authentication, also in
> future versions and with possible shared keys?

It is not modified, see above

Is the state table affected by the clients choice of ODCID (think abuse)?

Yes, if CIDs are chosen to maximize the number of different SIDs, that will
grow the table. IMO this isn't substantially different from randomly chosen
CIDs, which is of course normal behavior.