IETF Logo Mail Archive

Re: Connection ID lengths 1, 2 and 3

"Deval, Manasi" <manasi.deval@intel.com> Sun, 15 July 2018 20:37 UTC

Return-Path: <manasi.deval@intel.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 8AF2D130E63 for <quic@ietfa.amsl.com>; Sun, 15 Jul 2018 13:37:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 ZvbLENu23ZEe for <quic@ietfa.amsl.com>; Sun, 15 Jul 2018 13:37:13 -0700 (PDT)
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (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 DCC05130DDC for <quic@ietf.org>; Sun, 15 Jul 2018 13:37:12 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jul 2018 13:37:12 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.51,358,1526367600"; d="scan'208";a="71598477"
Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by fmsmga004.fm.intel.com with ESMTP; 15 Jul 2018 13:37:00 -0700
Received: from orsmsx115.amr.corp.intel.com (10.22.240.11) by ORSMSX106.amr.corp.intel.com (10.22.225.133) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 15 Jul 2018 13:37:00 -0700
Received: from orsmsx111.amr.corp.intel.com ([169.254.12.141]) by ORSMSX115.amr.corp.intel.com ([169.254.4.162]) with mapi id 14.03.0319.002; Sun, 15 Jul 2018 13:37:00 -0700
From: "Deval, Manasi" <manasi.deval@intel.com>
To: Eric Rescorla <ekr@rtfm.com>
CC: Marten Seemann <martenseemann@gmail.com>, Ian Swett <ianswett@google.com>, IETF QUIC WG <quic@ietf.org>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Subject: Re: Connection ID lengths 1, 2 and 3
Thread-Topic: Connection ID lengths 1, 2 and 3
Thread-Index: AQHUEsvAi91oX8DVaUqbcldKc5Rk06R97QgAgBGLlvCAAOSi4IAAh0AA//+rWH+AAHgzgP//jiJFgACDmQD//7fKzw==
Date: Sun, 15 Jul 2018 20:36:59 +0000
Message-ID: <08C6157C-A349-4CDB-B2AD-87215252DC25@intel.com>
References: <1F436ED13A22A246A59CA374CBC543998B86DF5E@ORSMSX111.amr.corp.intel.com> <CAKcm_gPmp=5pcM-UFWWU4UvNuuCOwbcj7s1=Qb4GW3cGhF3Bbw@mail.gmail.com> <0EA7393D-B7EC-4755-B13E-5177E24AA57A@intel.com> <CAOYVs2q5C370LN4X-xJ4NuMxjt5ALsz4vFwczj6N2j5skvuFKw@mail.gmail.com> <4F5BCC2E-4DD0-403F-954A-FB79847E218B@intel.com>, <CABcZeBNtYcqYLMs9EHkfNo+=hBi1RhOfP-ikgzLgfBpG4xgJng@mail.gmail.com>
In-Reply-To: <CABcZeBNtYcqYLMs9EHkfNo+=hBi1RhOfP-ikgzLgfBpG4xgJng@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/T1X-ChqRwczl1QB90C7icv7NGt0>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.27
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: Sun, 15 Jul 2018 20:37:15 -0000

For now,  we have heard of a good use case for 16-18 byte long connection Id and a 1-4 byte long connection id. I am very skeptical of the requirement to support every size from 0 to 18. 

We can possibly agree to support 8 or 10 different sizes that span this range and code it in a 3 or 4 bit connection length. If we must use 4 bit, some of the values can be encoded to 0. What do you think?

Manasi




Sent from my iPhone

> On Jul 15, 2018, at 1:56 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> existing fast crypto primitives to encode connection ID

v2.23.0 | Report a Bug | By Email