From nobody Fri Jan 15 12:11:33 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 B64B73A113C for ; Fri, 15 Jan 2021 12:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 btKXGgpUR9y8 for ; Fri, 15 Jan 2021 12:11:29 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650136.outbound.protection.outlook.com [40.107.65.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C980C3A113A for ; Fri, 15 Jan 2021 12:11:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GWKfeyWFwxRKFMhQt4GIR/TZGPaaqLf3Z5Uf+qFMozqqncU661CVJEHE3yhTX65BX0bQZZ7LkV9YCNOW+CW6CsBFi+BfF5yyUOkS3E8PyvdGoPm2jXzgj2KXQDbKicZU6D5tNdgMq6rNocTh2xKE3gwsqgNjIyVadedPnAsfuSTyzPjDGs2MxENXvODLnpR0Nu4P/mpQK+9uItZdzSnHDQ0mo2Ub6/g6m1ZDFeb9QTEnPW73ABv9QJ1fjuotaPrwDtlZfMhJUZy2+zanPVbiG90tKLw5BR7D0xQ4WDM4Z7hlSo2eDee0BhDxrEbKtjfirUbami+hF1jLQaPuooUdYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MW3PuWWsBSRp9JZCGkVDp7JWoiajzROUHGZwJ4/Ttok=; b=g8lljPdGgzmU2NL3XyEIDHGostOdBLKd3Gh3j8m4/jzP9mV1KMQIfd25ecAg/TpldjySevTUYvwu+KVSZXQAOOdIpoKCUvukjlSPG7cN2H+Xdl0r0b7mjiVJOeIkbkUcjFWDPRvmZMlDLot5J+6d2N+1gObqYNABjc5u1ZMJpO1OZ0gculGKMiBZEaMGuPqrCs4CkE4L+iB5zRxANtMgtdJjyblY9JisejuhyMVjsan4uHYQRVXA3mYIpSuKRgc3wdDjGze99TNIVwEJRvGT+m/lhIWV5r4JyEPdiT0rv8aIPpP+aMyvwg9vowkGCgb1AqIY4LxMiITTOXE96hEO/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MW3PuWWsBSRp9JZCGkVDp7JWoiajzROUHGZwJ4/Ttok=; b=NwPhV2wAYz2d4SyO8Goo8mFr2OL6g2S5qJkR4/ATd330jaghI32gDxdWV2O7daPQ5+QBj367JFvwp9s8qpkWpp2r9ZrMoRIS7rA+gnINCAQQKpDv9q6mKbP3kfKW/8GIY4/N8gOLPot9bg71rjJYP/aFNBHej42G/e9h807JxXg= Received: from (2603:10b6:610:ad::16) by CH2PR00MB0777.namprd00.prod.outlook.com (2603:10b6:610:6f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.0; Fri, 15 Jan 2021 20:11:15 +0000 Received: from CH2PR00MB0853.namprd00.prod.outlook.com ([fe80::69c1:d74a:ab63:370e]) by CH2PR00MB0853.namprd00.prod.outlook.com ([fe80::69c1:d74a:ab63:370e%8]) with mapi id 15.20.3807.000; Fri, 15 Jan 2021 20:11:15 +0000 From: Nick Banks To: "martin.h.duke@gmail.com" , "huitema@huitema.net" CC: "quic@ietf.org" Subject: Re: New Plaintext QUIC-LB Design Thread-Topic: New Plaintext QUIC-LB Design Thread-Index: AQHW6GJ3kyLeqvZF3Uy15kOPNm8HUaojD4yAgAADpoCAAAqkAIAAAR2AgAAKqoCAAAh5AIAACLSAgAAP1gCABdfkAIAAAa09 Date: Fri, 15 Jan 2021 20:11:15 +0000 Message-ID: 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: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-01-15T20:11:09.274Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [66.235.0.112] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b6e77d4b-5074-4c1e-424d-08d8b991b65d x-ms-traffictypediagnostic: CH2PR00MB0777: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8MJE7UuCQ+fgtBsHL/ly1bUIM0Lwo/+FbyCIqQnYxP1jCaUsnLS9KcVeoySjU60gw7g1t1kq7LXBqo9O33QSJsofgdYfAHhKlBNDMNqktF/D/3ekUV7jXIp8gswB3FUZvKZvH8MBD4D1PY/ujvVNbcla2Bm5nulIrVg1zuDd09elf+a8CpsPgA7WXMVMCAKVBYJg3CmwxXr5ZO7RfsxXKc9WkIplwEUursBVdGwLEdRPaOw445WN9LrodEf2XzdBRIGZLyYlNbCwB+Mc7u8vTrzbpqVW7wfb+461QpziV8mbInieH3Be/gW6yv0+4rbgdJPAM3s9+Q65gP1/A1r8g7GAYZJMAs23bhZRnD/v9bzXG3xM40Tmc2zrlPa/YvJHj5I3BF6SMDgSQi4jQhIfB3OSDRrumUmK+qqlpaAuERdwx9YQ6D7u8c1bU6PwP6eec9Asiax/QYXIFR/GMs57lAtI7/L4zgSVx5pf0FSgXZEMpb2ecen7f3NbYtAuYaYi9UEcV3z8DVeX9ZYeru/1g8a3xrz1vETqCffZ6NnYWp5n6kZL4Z2Eh0Uv8jbJt6Fzui0HM4xaH+u5lAL5S255VJgqqOqtlZX8MX7uxHIkCACpyIURt7aSNlJZkmI3NqitZQ9uZ0BX542ymMK+4nssrA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0853.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(346002)(136003)(376002)(39860400002)(66476007)(76116006)(186003)(52536014)(5660300002)(7066003)(83380400001)(82950400001)(8990500004)(91956017)(8936002)(66946007)(64756008)(8676002)(166002)(4326008)(55016002)(86362001)(66446008)(3480700007)(66556008)(82960400001)(316002)(33656002)(110136005)(478600001)(19627405001)(10290500003)(53546011)(7696005)(6506007)(71200400001)(9686003)(2906002)(26005)(10090945008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?yos74Bn3QEc/doKamOtCHvlcG6QC+4YtQHPO/PfJbAv+r3u5SnE7beBjJ7G3?= =?us-ascii?Q?tpKwOCT6BLp+Tw4SeokJ1UKp2I7Og66bC5i7V0odlL216cm0V4f//+60Dh8k?= =?us-ascii?Q?nC5L7deFZWPuZcTAHloeT/5ViAPL8viyjOruz58+EmeiDdDFFg6BYxhdiFgn?= =?us-ascii?Q?zU31p3XtilhwNa9ec8Y1hdRPoPdqzrtBY8g0jYEFkbIq7tJj7CugxrkqhhWP?= =?us-ascii?Q?xTM9g/JiMK0Z2h0j2itjV4cuFcwYA7uOMZ3DZv/Rxubag6DxOlrP813wssyX?= =?us-ascii?Q?kg2WveGkaaKejaivFpjdnltf4jUHsQoNZXxDXjW5NUzIWNGaT72oxnkCweGS?= =?us-ascii?Q?rrH9I4MP6sqRyjDC8tVIurfiXRI5UFHMfd8w0Q9ibZprSSsliZq9K5myDcWe?= =?us-ascii?Q?8zTNGDZ+5NqZSftxJmuUAoqh+Rvy0+MdFl31xD6JByak/p4ZygUWMTrTvCsb?= =?us-ascii?Q?KWfXCa2tMA41dmtTIS6xo7ytmz6ltC2BKjy22xaX6ilIwXt6lPtjGFfh0SeF?= =?us-ascii?Q?txkK88Va2Rnk6vc9BGKnfZAs4ejjWdTQMDCYDpB4aTBspSDDzGseCrEqeIjb?= =?us-ascii?Q?BLb0jWc7tLb/Z+Ah1qAZnvJVKtco1SdgcMDk8gBYrda1FlCuY7kKcy5aqAxx?= =?us-ascii?Q?zTlqZbW0VLQ43z78Uq1LO6MJlsvFUKsuYkm8Ux3ZZ4ybyJw6ojfinSWbSy2Q?= =?us-ascii?Q?dlOD/07tacz/eL6XSsFPB4MszJeWXgU7HzycN4IA2KVRdc5+0JiplwHgqQJ0?= =?us-ascii?Q?z4NNRNowHINEgS/SX3/XGiZOGrdxli8ENhY7drVqSURXLx/FdukL8Rz8Q83+?= =?us-ascii?Q?xopbW1YZWXWuKVT7mYhPFS7R3PVQ0655D8rH410pYl4I3ImIO+QE0QZqKK62?= =?us-ascii?Q?ATBwkSCY5j5mc1qtQD3F+S8wxqGTdpNtaScvDDue8Oj1PUkGjLKx/169DxoF?= =?us-ascii?Q?UBaEwolMbtbnLJgk9JQ0t3EQ8HD83b45GkuFSr0Wlc9y9HDNOgKTtqmLWnW3?= =?us-ascii?Q?nd0TLclWbQHuToio/9eG7CBvn70mP21c0OloBEQVG4IaIE4=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB08530052151B39B5DA674B9BB3A79CH2PR00MB0853namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0853.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b6e77d4b-5074-4c1e-424d-08d8b991b65d X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2021 20:11:15.2492 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jnjxNlb9GHhoMQkK8kYiKXyGmJBXx7EngwdPnKTGs7Y+l4eu8vAUkJVpWAV3vUwN3rn/XagC9oOR+efhR3bjug== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0777 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: Fri, 15 Jan 2021 20:11:32 -0000 --_000_CH2PR00MB08530052151B39B5DA674B9BB3A79CH2PR00MB0853namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I also would at least explore a generalized approach before solidifying the= current designs. Thanks, - Nick Sent from Outlook ________________________________ From: QUIC on behalf of Martin Duke Sent: Friday, January 15, 2021 12:04 PM To: Christian Huitema Cc: IETF QUIC WG Subject: Re: New Plaintext QUIC-LB Design To muddy this discussion a little further, after a little more thinking I b= elieve there's a way to generalize this approach to all three of the origin= al algorithms, encrypted or unencrypted, so there is never a need to manual= ly allocate server IDs. Again, the main tradeoff here is simpler configuration vs. more complexity = and state at the load balancer. As a document organization matter, rather than have six different algorithm= s I would prefer to specify three with a separate section describing the tw= o separate ways to allocate a server ID. But it is not too late to yell "stop" at this multiplicity of options if pe= ople feel the tradeoffs are clear-cut in one way or the other. On Mon, Jan 11, 2021 at 6:50 PM Martin Duke > wrote: 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 impl= ement that. What should be the value of the config rotation bits in CID cre= ated 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 extr= acted from any CID, hence all the weird stuff about CIDs with undefined con= figs. 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 rand= om 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 t= he 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 initia= l" packet is received? When any packet is received with that SID (not CID), the expiration is refr= eshed. 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 handshak= e. 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 --_000_CH2PR00MB08530052151B39B5DA674B9BB3A79CH2PR00MB0853namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I also would at least explore a generalized approach before solidifying the= current designs.

Thanks,
- Nick

Sent from Outlook

From: QUIC <quic-bounces= @ietf.org> on behalf of Martin Duke <martin.h.duke@gmail.com>
Sent: Friday, January 15, 2021 12:04 PM
To: Christian Huitema <huitema@huitema.net>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: New Plaintext QUIC-LB Design
 
To muddy this discussion a little further, after a little more thinkin= g I believe there's a way to generalize this approach to all three of the o= riginal algorithms, encrypted or unencrypted, so there is never a need to m= anually allocate server IDs.

Again, the main tradeoff here is simpler configuration vs. more comple= xity and state at the load balancer.

As a document organization matter, rather than have six different algo= rithms I would prefer to specify three with a separate section describing t= he two separate ways to allocate a server ID.

But it is not too late to yell "stop" at this multiplicity o= f options if people feel the tradeoffs are clear-cut in one way or the othe= r.

On Mon, Jan 11, 2021 at 6:50 PM Mar= tin Duke <martin.h.duke@gmail= .com> wrote:
Yes. Do you have an alternate suggestion?

On Mon, Jan 11, 2021 at 5:54 PM Chr= istian Huitema <huitema@huitema.net> 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 Christi= an Huitema <hui= tema@huitema.net> wrote:

I am looking at the text of section 4.2, and I am not sure how I would i= mplement 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 g= enerating 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 r= andom value?

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

Issss the timer set when the server ID is first added to the table, or i= s 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 "firs= t 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 hands= hake.

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

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

5) server-ID=3DX never expires.

Is that by design?

-- Christian Huitema


--_000_CH2PR00MB08530052151B39B5DA674B9BB3A79CH2PR00MB0853namp_--