Re: Connection ID lengths 1, 2 and 3
Marten Seemann <martenseemann@gmail.com> Sun, 15 July 2018 16:52 UTC
Return-Path: <martenseemann@gmail.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 66375130DF9 for <quic@ietfa.amsl.com>; Sun, 15 Jul 2018 09:52:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 lnF0liKOPQCr for <quic@ietfa.amsl.com>; Sun, 15 Jul 2018 09:52:11 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 A344A1294D0 for <quic@ietf.org>; Sun, 15 Jul 2018 09:52:11 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id v26-v6so35548420iog.5 for <quic@ietf.org>; Sun, 15 Jul 2018 09:52:11 -0700 (PDT)
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=aFbNQSutZCBLx2kgxkB1+XlSY7qZ0MkJ+c87qluDwp4=; b=j+PcWXSBTihxb5WFR/Q4KoQMdzio95PeWGgSId8Ba7d644sv9AY25YMKY5B7RAbA3I v2WhRUrjY7aM9SSzrzTNlUclTd6KOYQuFmE3gNf3dzQyqWbBRxcCbiF3wB4foNBuMkGm v/5+DsE3Ahtnc43r8GQ2jXsDPk6wu1kaKnGHsg4L5LQxq8u+9SqeyOdEqAL2gorTuZ/y LqrU4quMowDbIF1U+qRgvvq4TnnLy0jmc3gU37YBEC8l3sIkbjvMPo+hwLSg/EELaXK/ 4nlPd9EvpLhvNSrFgpgD/3XrPUPJe9n3EwkNwljJIzs4T1s7SwZJ10WDJv4H8swHVP/R F0gw==
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=aFbNQSutZCBLx2kgxkB1+XlSY7qZ0MkJ+c87qluDwp4=; b=Y5UvxtoL2urIK43ygvKZKwPoYPmzy6noYG8ob3EikFQC8oj+VT8KoziMsX3lcOCydb pVmUG8dQ1l4rqdM0n05MxrYeO7qbdWxFVi7tiBVwgkWUiZL3IePcSLH59lJTytDZSoMn pVFLyZGltFhYet4qHSJORGHee9F88+GhFbwQNfAF/0rT7ST5BN8Ej9cE9Ro2k1opc3ga fVKE/5EV5V8rnAouAjbaVzUEvED4PCw+XZQfAKgtPMf6QqprU75ev8ZcyyPwFPkF8hFC ljDCM7xvTf9gvnmkdvJ6oBca99oT3hspA2W63cBbW7rKQWhXLmo13EiGq1DdtRwrYAg5 sI9Q==
X-Gm-Message-State: AOUpUlFv8yD0sHlwxdiqwTgVFYiy8kaYWssVE8Be3JydQshsgDnha+Ia nOrYwt+M5BwESw9zXjY8Z2aCEv6sv3RzBl191g0=
X-Google-Smtp-Source: AAOMgpdqigk+iVqFyKOhv+oJD7BAK+++4b02PcsbmwKbmSCdJ9NgdDFG+CNcJAR8W2ORGT75UGL8S100kBsfr4ZmTKE=
X-Received: by 2002:a5e:de42:: with SMTP id e2-v6mr13438533ioq.235.1531673530803; Sun, 15 Jul 2018 09:52:10 -0700 (PDT)
MIME-Version: 1.0
References: <1F436ED13A22A246A59CA374CBC543998B86DF5E@ORSMSX111.amr.corp.intel.com> <CAKcm_gPmp=5pcM-UFWWU4UvNuuCOwbcj7s1=Qb4GW3cGhF3Bbw@mail.gmail.com> <0EA7393D-B7EC-4755-B13E-5177E24AA57A@intel.com>
In-Reply-To: <0EA7393D-B7EC-4755-B13E-5177E24AA57A@intel.com>
From: Marten Seemann <martenseemann@gmail.com>
Date: Sun, 15 Jul 2018 17:51:59 +0100
Message-ID: <CAOYVs2q5C370LN4X-xJ4NuMxjt5ALsz4vFwczj6N2j5skvuFKw@mail.gmail.com>
Subject: Re: Connection ID lengths 1, 2 and 3
To: "Deval, Manasi" <manasi.deval@intel.com>
Cc: Ian Swett <ianswett@google.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b72ab905710c8881"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/yV6AttoKQ3DbxiVeHbcTigv4TdI>
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 16:52:15 -0000
I don't think we should reduce the number of sizes available. Sending bytes on the wire is orders of magnitude more expensive than performing a simple transformation to a parsed value. I'd prefer if we could discuss this separately, since this is quite the opposite of what I was originally proposing. To reiterate my argument, changing the invariants such that the values 1, 2 and 3 can be used would be a big benefit for p2p applications, since they would be able to use super-short connection IDs. Since this is a change that requires a change to the invariants, we need to make this decision very soon, if we want to enable this use case of QUIC. On Sun, Jul 15, 2018 at 12:41 PM Deval, Manasi <manasi.deval@intel.com> wrote: > I would still prefer if we can reduce the number of sizes supported. > > Could a scheme where we support only 5 cids be used? Use a 3 bit size , > shift left by 2 and not use the last 2 sizes of 24 and 28. > > > Thanks, > Manasi > > > > On Jul 15, 2018, at 10:45 AM, Ian Swett <ianswett@google.com> wrote: > > If one uses existing fast crypto primitives to encode connection ID, then > 16 bytes is a natural size, and there was interest in having an extra byte > for metadata(key rotation/length signaling/etc). > > Unfortunately, that leaves us with a gap somewhere, and a gap at the > beginning seemed the most natural at the time. > > On Sun, Jul 15, 2018 at 10:35 AM Deval, Manasi <manasi.deval@intel.com> > wrote: > >> Another issue I noticed with the size of connection id was with regards >> to parsing the header field. The current steps are: >> >> · Parse DCid length, >> >> · Add 3, >> >> · Parse DCid length >> >> · Add 3, >> >> · Read DCID >> >> · Read SCID. >> >> >> >> I really appreciate the fixed size length fields so we can know both >> destination and source Cid lengths in parallel. Implementing this in >> hardware has the following challenges though: >> >> a. There are 12 unique length types for each of the CiDs. This >> means either more stages of serial processing, which would be slower. Or it >> means more logic for parallel processing. >> >> b. In addition to this, the arithmetic logic to add 3 is a little >> more specialized than a logical operation, e.g.shift left. >> >> >> >> Therefore, I would like to understand the basis for having 12 different >> lengths and if there is a chance to simplify this logic, we can have a 3 >> bit length and shift left 1, so we have lengths of 0,2,4… 14. Would the >> loss of longer CiD values from 15 to 18 be an issue? >> >> >> >> Thanks, >> >> Manasi >> >> >> >> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Mikkel Fahnøe >> Jørgensen >> *Sent:* Tuesday, July 03, 2018 6:06 AM >> *To:* QUIC WG <quic@ietf.org>; Marten Seemann <martenseemann@gmail.com> >> *Subject:* Re: Connection ID lengths 1, 2 and 3 >> >> >> >> That is correct. Especially in low-power sensor mesh networks. >> >> >> >> >> >> On 3 July 2018 at 14.45.30, Marten Seemann (martenseemann@gmail.com) >> wrote: >> >> First of all, I realise that I'm bringing this up late in the process, >> and maybe too late, since this would require a change to the invariants. >> >> >> >> The connection IDs can be either 0 bytes or anything between 4 and 18 >> bytes (inclusive). Lengths of 1, 2 and 3 bytes are not possible. >> >> For p2p applications, and for server deployments that are not doing >> connection ID based load balancing, it would be interesting to use shorter >> connection IDs. One might imagine that a peer encodes the length of the >> connection ID into the first few bits, and then starts using 1 byte >> connection IDs first, and successively moves to longer lengths only when >> handling more connections. A p2p host handling several thousand >> simultaneous connections (which will be enough for many p2p protocols) >> would never have to use anything longer than 2 byte connection IDs. >> >> >> >> In the connection ID length field in the Long Header, we only have to 4 >> bit to encode a range of 19 values (we want 0 byte connection IDs, and we >> want to support 18 byte connection IDs), so *some* values have to be left >> out. However, leaving out 1, 2 and 3 seems a bit unfortunate, as there will >> be more use cases for these values than e.g. for 13, 14 and 15 bytes. >> >>
- Re: Connection ID lengths 1, 2 and 3 Mikkel Fahnøe Jørgensen
- Connection ID lengths 1, 2 and 3 Marten Seemann
- RE: Connection ID lengths 1, 2 and 3 Deval, Manasi
- Re: Connection ID lengths 1, 2 and 3 Ian Swett
- Re: Connection ID lengths 1, 2 and 3 Deval, Manasi
- Re: Connection ID lengths 1, 2 and 3 Marten Seemann
- Re: Connection ID lengths 1, 2 and 3 Deval, Manasi
- Re: Connection ID lengths 1, 2 and 3 Mikkel Fahnøe Jørgensen
- Re: Connection ID lengths 1, 2 and 3 Eric Rescorla
- Re: Connection ID lengths 1, 2 and 3 Deval, Manasi
- Re: Connection ID lengths 1, 2 and 3 Eric Rescorla