Re: Connection ID lengths 1, 2 and 3

[Mikkel Fahnøe Jørgensen <[e-mail]>]

version is only during handshake, CID is on all packets



On 15 July 2018 at 19.04.49, Deval, Manasi ([e-mail]) wrote:

There is a 32bit version number that precedes the length field. Until we
have a thousand versions, we are always sending 3 extra bytes on the wire.

Thanks,
Manasi

On Jul 15, 2018, at 12:52 PM, Marten  <[e-mail]> wrote:

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 <[e-mail]>
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 <[e-mail]> 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 <[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.
>>
>>