Re: Connection ID lengths 1, 2 and 3

[Ian Swett <[e-mail]>]

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 <[e-mail]>
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:[e-mail]] *On Behalf Of *Mikkel Fahnøe
> Jørgensen
> *Sent:* Tuesday, July 03, 2018 6:06 AM
> *To:* QUIC WG <[e-mail]>; Marten Seemann <[e-mail]>
> *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 ([e-mail])
> 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.
>
>