Re: New Plaintext QUIC-LB Design

Nick Banks <nibanks@microsoft.com> Fri, 15 January 2021 20:11 UTC

Return-Path: <nibanks@microsoft.com>
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 <quic@ietfa.amsl.com>; 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 <quic@ietfa.amsl.com>; 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 <quic@ietf.org>; 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 <nibanks@microsoft.com>
To: "martin.h.duke@gmail.com" <martin.h.duke@gmail.com>, "huitema@huitema.net" <huitema@huitema.net>
CC: "quic@ietf.org" <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: <CH2PR00MB08530052151B39B5DA674B9BB3A79@CH2PR00MB0853.namprd00.prod.outlook.com>
References: <CAM4esxRRp5=-YvcPsCdsgB=8O=_RAXq05Ldma0smGsjy95T4=g@mail.gmail.com> <6B05568D-1905-4416-904C-2EEC25491920@gmail.com> <CAM4esxSyn7uEiUsYvtiUbQ=4Qt-Bp+yLYBK+re+a+V3ea0BjcQ@mail.gmail.com> <B4D950F6-452A-4CFC-9707-DC1C9B3AB49B@gmail.com> <EB8897FC-1A57-4C45-ABDE-B87E36E519E8@gmail.com> <03ba27b1-3d27-d66b-4fc0-a952c24c993d@huitema.net> <CAM4esxToXBrKezEc3WVWpZFmNLVgVBX+==N77OyjmvEfvJ+kTA@mail.gmail.com> <527d1ec7-c354-5756-6f02-c8058c560b3a@huitema.net> <CAM4esxSVn9zdsur8E6EUGJTusE5DTkQOz7N1+VXm6aZ2v1Zzow@mail.gmail.com>, <CAM4esxS8mqf5F6ZAW_JPrwg4gHWdtk=OMtRnwfJeuOH9JhoiqA@mail.gmail.com>
In-Reply-To: <CAM4esxS8mqf5F6ZAW_JPrwg4gHWdtk=OMtRnwfJeuOH9JhoiqA@mail.gmail.com>
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: <CH2PR00MB07771BB49554B23E1A541621B3A79@CH2PR00MB0777.namprd00.prod.outlook.com>
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: <https://mailarchive.ietf.org/arch/msg/quic/uksfphh3PxDjh0OyzUGxuC5wvFk>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jan 2021 20:11:32 -0000

I also would at least explore a generalized approach before solidifying the current designs.

Thanks,
- Nick


Sent from Outlook<http://aka.ms/weboutlook>

________________________________
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 thinking I believe there's a way to generalize this approach to all three of the original algorithms, encrypted or unencrypted, so there is never a need to manually 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 algorithms I would prefer to specify three with a separate section describing the two separate ways to allocate a server ID.

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

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

On Mon, Jan 11, 2021 at 5:54 PM Christian Huitema <huitema@huitema.net<mailto: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 Christian Huitema <huitema@huitema.net<mailto: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 "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