From nobody Mon Jan 11 17:54:05 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 BECE53A0965 for ; Mon, 11 Jan 2021 17:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 0uvw_kPnin30 for ; Mon, 11 Jan 2021 17:54:02 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 D91303A0964 for ; Mon, 11 Jan 2021 17:54:02 -0800 (PST) Received: from xse142.mail2web.com ([66.113.196.142] helo=xse.mail2web.com) by mx136.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kz8se-00022k-OY for quic@ietf.org; Tue, 12 Jan 2021 02:53:59 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4DFDBp5hKGz12Xl for ; Mon, 11 Jan 2021 17:53:54 -0800 (PST) Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1kz8sc-0002T2-M4 for quic@ietf.org; Mon, 11 Jan 2021 17:53:54 -0800 Received: (qmail 5186 invoked from network); 12 Jan 2021 01:53:54 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.58.43.253]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Jan 2021 01:53:54 -0000 Subject: Re: New Plaintext QUIC-LB Design To: Martin Duke Cc: IETF QUIC WG References: <6B05568D-1905-4416-904C-2EEC25491920@gmail.com> <03ba27b1-3d27-d66b-4fc0-a952c24c993d@huitema.net> From: Christian Huitema Message-ID: <527d1ec7-c354-5756-6f02-c8058c560b3a@huitema.net> Date: Mon, 11 Jan 2021 17:53:53 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------855CA25505DFBB79B70A52DA" Content-Language: en-US X-Originating-IP: 66.113.196.142 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.142/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.142/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x6h2yQpzTslcOqazQkKtAFKj/EwzSHE5FGYwwjsNRPCAOW HWj/miCEq1itacMKGSLmD6wdmZPcItWbGe10hXJtyz/MWLF6jnm7fdxjsJMmvwzR/hTGZT+Rq3LO Lr56rGrocJZHhVJQHybQm8TwmCKQE5LN1n8YXzQY0mQUNzTGAwCyMkrqOaHyAipaXQfAHlJH3v3Q 7PQeNoNQjwiv3IhNPpDsdaHHqGG7YXgprtn5XLToE7g5LY8o1a6sSJrLl3xdARnv/HGR54G9CHRY hyVqYO/Ae1h1hLGGi4ebv387hThA9A+LrmkGouiRB8qN/5RbHDa6yUUKFnWNneAcuva3BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NQ/T3Op6Um662jkOH4Bxha+3WSgTJtuWU4E6Qe14xEdCo Q6PbUf9WamnPS++YeVhq2JUne37EdXOqrRyXv4wznkqScD1J03Oiru4NI1oJjEY11lqdy1V/0aEk MCdb3YpWUo4/+EUytKrR9Md9I2Rs14NeHwRbChcipVSKguS4LLNPCC/cRgvQKtcrMMueERx3t2k3 1QZ+QelBH3a5CBq2aUcc67bXYOs1vT70h1ddO12IaIzNoZzswxuMaWjBAlpwjIW8G8aLXRxo/sfv to4I7fUf9oDBqtClgM5jH/om1Q5UomG0v+rwIiID/kwKc8V5Tj9+FRkaOS/DNjANmb8tO61SbYdY AwdpaVzHW7wHO7YhEWyJzIkwSFAW0Pw8uiKeubcolFl/rX+2ReQklqJDASQX2Id+W5hjJNcdGs0+ iHjXODmj5PX/tZQU3bYnWKpb X-Report-Abuse-To: spam@quarantine11.antispamcloud.com 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:54:05 -0000 This is a multi-part message in MIME format. --------------855CA25505DFBB79B70A52DA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 --------------855CA25505DFBB79B70A52DA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


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 "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


--------------855CA25505DFBB79B70A52DA--