From nobody Mon Jan 11 18:50:48 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 3B97E3A0C99 for ; Mon, 11 Jan 2021 18:50:47 -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 WnfOMlsyDYSV for ; Mon, 11 Jan 2021 18:50:46 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 D4CFA3A0C97 for ; Mon, 11 Jan 2021 18:50:45 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id y19so1030167iov.2 for ; Mon, 11 Jan 2021 18:50:45 -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=WUgIBIpBUDkMo2jacxF9gm03zruAcaPn6llobstpYoo=; b=rTrfoVx5pBUbQVLcC3uJ/5uFLwZNaQVI5ufZTKT6Git/HjSSBVJpnUU9+oKK8j8FQK UGbZbjR85N1/3a1xasJWQ20FFGeBq41vavdaGjDhazFJxKIfTKq/BkDXmG27AlyvcMkz mk7EZbwoDh0Fy/OL20t5NGpo8siX9sCgyh+fz6e5WW/5JwmiKfVIVQiWsuA64NtS/vtn a2tGu/pbCPVsnIdXU88g5eqhOKW9atiixgqPNf5bk+V+cZd0uiHLvoat0ewphpjdVFrd j7Qhlm3IYqwGGc3E96hXcx46O36YaooTU4oV4bhxU/rm+BG3aASEqI0N1r6h+aR+1O5A fx0A== 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=WUgIBIpBUDkMo2jacxF9gm03zruAcaPn6llobstpYoo=; b=dEDI5hF62fHoL+PgmWJ8poYkLqEE6Bb+9yKU8LIHahnSEXKCW77YXaQ+ghLrMNG5E3 XqFe32qWj1n3UwCHIUWwcTY0+6phv5sOMcO0ojv0IB3gdzMnPwRXpgXOUIhGsdCaeagB z72JFbMx2KbhnlWN7He4u69VbzyHRHYjUpMULsrhDuaFkb4lEDqboJUPwPdvCPCr5FgY zTCP0armooIh5y5KgfuUXPlXGnKUXb7aUct0YjCdCbLqxlog4FsXEG2xvO6YFA+JFrSF W2Fnih24k9Uy7XrInmBKGoSagBx1I8KRI63CJCplNPJdsIFCsGMwuY+mE3wAaux4dJBx YOIg== X-Gm-Message-State: AOAM5306gckEQ8CBkBCcJR+Gavddr0JR68OLJ0ibWR5ACWPkUxuEL3eY PkQNwcav31DHpFfvhkfbXD6yFG2ZIG25ANlpuDnDmrnnaIE= X-Google-Smtp-Source: ABdhPJyYOz1yn6+BWehySYEzgkXikj6xUUIhz3tZI9CkBg2to3K9JoiZm0f5Lf6z1tgpVcvsSqrNpxe6XIx2AzgddOA= X-Received: by 2002:a05:6638:1247:: with SMTP id o7mr2244347jas.31.1610419844868; Mon, 11 Jan 2021 18:50:44 -0800 (PST) MIME-Version: 1.0 References: <6B05568D-1905-4416-904C-2EEC25491920@gmail.com> <03ba27b1-3d27-d66b-4fc0-a952c24c993d@huitema.net> <527d1ec7-c354-5756-6f02-c8058c560b3a@huitema.net> In-Reply-To: <527d1ec7-c354-5756-6f02-c8058c560b3a@huitema.net> From: Martin Duke Date: Mon, 11 Jan 2021 18:50:34 -0800 Message-ID: Subject: Re: New Plaintext QUIC-LB Design To: Christian Huitema Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000caf5e305b8ab16cd" 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 02:50:47 -0000 --000000000000caf5e305b8ab16cd Content-Type: text/plain; charset="UTF-8" Yes. Do you have an alternate suggestion? On Mon, Jan 11, 2021 at 5:54 PM Christian Huitema wrote: > > On 1/11/2021 5:22 PM, Martin Duke wrote: > > 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 CID >> 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 latter >> 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. > > OK. So we can have the following: > > 1) Server learns of Server-ID = X. > > 2) Server creates new CID with that server ID, uses it to complete > handshake. > > 3) Client maintains a long running connection with that CID. > > 4) Server keeps receiving messages with CID pointing to server-ID = X > > 5) server-ID=X never expires. > > Is that by design? > > -- Christian Huitema > > > --000000000000caf5e305b8ab16cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes. Do you have an alternate suggestion?

On Mon, Jan 1= 1, 2021 at 5:54 PM Christian Huitema <huitema@huitema.net> wrote:
=20 =20 =20


On 1/11/2021 5:22 PM, Martin Duke wrote:
Perhaps I should make some edits for clarity!

On Mon, Jan 11, 2021, 16:52 Christian Huitema <huitema@huitema.net> 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 CID 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 latter case, is it reset when any packet is received, or only when a "fir= st initial" packet is received?

When any packet is received with that SID (not CID), the expiration is refreshed.

OK. So we can have the following:

1) Server learns of Server-ID =3D X.

2) Server creates new CID with that server ID, uses it to complete handshake.

3) Client maintains a long running connection with that CID.

4) Server keeps receiving messages with CID pointing to server-ID =3D X

5) server-ID=3DX never expires.

Is that by design?

-- Christian Huitema


--000000000000caf5e305b8ab16cd--