Re: Connection ID lengths 1, 2 and 3

[Eric Rescorla <[e-mail]>]

On Sun, Jul 15, 2018 at 10:04 AM, 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.
>

Well, the current version actually has the high bit set.

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