From nobody Mon Jan 11 17:23:00 2021 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E44B3A033F for ; Mon, 11 Jan 2021 17:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEwRV7E7dIhr for ; Mon, 11 Jan 2021 17:22:57 -0800 (PST) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5283A02BD for ; Mon, 11 Jan 2021 17:22:56 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id t3so1313665ilh.9 for ; Mon, 11 Jan 2021 17:22:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3iAUnEpKc8tPNnrJ4Q8Tw/wnnPZT62E40zM3nIDmJuQ=; b=GYtABIh8HcD/k9PRfuIUFQ1vWqM1NsPhxpSBYFzXCTw8ZORxLYU1P4aZ7oQVyzyi5A LrQROX7PnLH9e3XoArXvlgZIS12M8ZZJrbkN5DN4znQN3l4pIWCuHsr+kgaDVbfYokVa d3IFyGunbG9JFVZ4MRLzloedgCdgQH+KMkcFLbi76H27+2GGPjVT1FtMQGuiWFuc2f94 UjYR5ly50ZEDQt2eK5ktmNf+Rudrqnh5NzK/kmkF4gLN8tlajB+V/ClqNd2UU7QeS05E z5oGL+2anrGkOviHMKQq88jaqNNElOCS110y1vyvzAqKdA3Un9Li8Y2kkCFB2E7DtH4k WCBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3iAUnEpKc8tPNnrJ4Q8Tw/wnnPZT62E40zM3nIDmJuQ=; b=myV+wpneZouobmu03ZJNpXBK/vmi8bje8VTak7R4AQV4sfg/TKFNfjkxq/GET+JQ/r 4ANDUtA+8MTUfHJ27pF+YK7zfCyDcB9gOnq/gsBV8n7hAPvpaVay4PyJVKcYdgPsBBkZ O9Kwreg2tZ3ax4KSh0AaGvTTk4AVLwkfVn7Lrj3yZZbTIqvJ0FdXLPxK9TAUjO3ZjqQo 30wNB6rpBjZe18KibkBkGThtTQiemM6ir8dvlIpUE9N2z4QaWOhPUAHNF/GR2Vtw8yaR UXPnLqLAWnOZvu4cd0BHVbzQAarT12VcUhxt6g2hKFz0wsW9Jdtz6NN8+ddV3PS+p+Vm N69g== X-Gm-Message-State: AOAM530IcRTNi+NPWP2QejyizSLIRksSMz19GeOtrDtyNgttzBnN+Wx0 VLdBh26Fg3HvuQkxQkTPITAwN4F10vkclspI0rMVgjNk+TM= X-Google-Smtp-Source: ABdhPJydiPwGnwFsIfTj5ZN21r5oQ2YmKiA/+IevRbxK/7ukeQEHmfNe3XzYLV/dZmdBMHB6y+dNNr3yVNXWmI3p9Gs= X-Received: by 2002:a05:6e02:68b:: with SMTP id o11mr1689235ils.237.1610414576046; Mon, 11 Jan 2021 17:22:56 -0800 (PST) MIME-Version: 1.0 References: <6B05568D-1905-4416-904C-2EEC25491920@gmail.com> <03ba27b1-3d27-d66b-4fc0-a952c24c993d@huitema.net> In-Reply-To: <03ba27b1-3d27-d66b-4fc0-a952c24c993d@huitema.net> From: Martin Duke Date: Mon, 11 Jan 2021 17:22:44 -0800 Message-ID: Subject: Re: New Plaintext QUIC-LB Design To: Christian Huitema Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000bf194205b8a9dced" Archived-At: X-BeenThere: quic@ietf.org 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: Tue, 12 Jan 2021 01:22:59 -0000 --000000000000bf194205b8a9dced Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Perhaps I should make some edits for clarity! On Mon, Jan 11, 2021, 16:52 Christian Huitema wrote: > I am looking at the text of section 4.2, and I am not sure how I would > implement that. What should be the value of the config rotation bits in C= ID > created by the server? > Any config includes the corresponding CR bits, and when generating the CID it would use those bits. The confusing part is that, for this algorithm, a usable SID has to be extracted from any CID, hence all the weird stuff about CIDs with undefined configs. Aside from that, it's like PCID: any server-generated CID uses the CR bits in the config, optional length encoding, SID, server-use octets. Should the 6 other bits in the first octet be set to a CID Len or to a > random value? > It depends on the rest of the config, as with the other algorithms. > Issss the timer set when the server ID is first added to the table, or is > the timer reset each time a packet is received with that CID? In the latt= er > case, is it reset when any packet is received, or only when a "first > initial" packet is received? > When any packet is received with that SID (not CID), the expiration is refreshed. > -- Christian Huitema > On 1/11/2021 4:14 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > > Sorry, the following text is out of context - it was a suggestion that I > decided not to persue. > > On 12 Jan 2021, at 01.10, Mikkel Fahn=C3=B8e J=C3=B8rgensen > wrote: > > If the DCID is not understood by the LB, the LB chooses a random target > server but does not store any state. The expectation being that the serve= r > will assign its own DCID on the return path. > > The LB will understand how to route the server assigned DCID. The problem > being that this generally requires shared state - which Low-Config aims t= o > avoid in exchange of local state. > > > --000000000000bf194205b8a9dced Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Perhaps I should make some edits for clarity!
On Mon, J= an 11, 2021, 16:52 Christian Huitema <huitema@huitema.net> wrote:
=20 =20 =20

I am looking at the text of section 4.2, and I am not sure how I would implement that. What should be the value of the config rotation bits in CID created by the server?

Any config includes the corresponding CR bits, a= nd when generating the CID it would use those bits.
=
The confusing part is that, for this algorithm,= a usable SID has to be extracted from any CID, hence all the weird stuff a= bout CIDs with undefined configs.

Aside from that, it's like PCID: any server-generated CID use= s the CR bits in the config, optional length encoding, SID, server-use octe= ts.

Should the 6 ot= her bits in the first octet be set to a CID Len or to a random value?

=
It depends on the rest of = the config, as with the other algorithms.

Issss the timer se= t when the server ID is first added to the table, or is the timer reset each time a packet is received with that CID? In the latter case, is it reset when any packet is received, or only when a "first initial" packet is received?

<= /div>
When any packet is received= with that SID (not CID), the expiration is refreshed.

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

-- Christian Huitema

On 1/11/2021 4:14 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote:
=20 Sorry, the following text is out of context - it was a suggestion that I decided not to persue.

On 12 Jan 2021, at 01.10, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:

If the DCID is not understood by the LB, the LB chooses a random target server but does not store any state. The expectation being that the server will assign its own DCID on the return path.

The LB will understand how to route the server assigned DCID. The problem being that this generally requires shared state - which Low-Config aims to avoid in exchange of local state.


--000000000000bf194205b8a9dced--