Subject: RE: Connection ID lengths 1, 2 and 3

From: "Deval, Manasi" <[email-masked]>
Date: Sun, 15 Jul 2018 14:33:12 +0000

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

---

From: Ian Swett <[email-masked]>
Date: Sun, 15 Jul 2018 10:44:46 -0400

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 <[email-masked]>
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:[email-masked]] *On Behalf Of *Mikkel Fahnøe
> Jørgensen
> *Sent:* Tuesday, July 03, 2018 6:06 AM
> *To:* QUIC WG <[email-masked]>; Marten Seemann <[email-masked]>
> *Subject:* Re: Connection ID lengths 1, 2 and 3
>
>
>
> On 3 July 2018 at 14.45.30, Marten Seemann ([email-masked])
> 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.
>
>

---

From: "Deval, Manasi" <[email-masked]>
Date: Sun, 15 Jul 2018 16:41:45 +0000

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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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.

Thanks,
Manasi

From: QUIC [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mikkel Fahnøe Jørgensen
Sent: Tuesday, July 03, 2018 6:06 AM
To: QUIC WG <[email-masked]<mailto:[email-masked]>>; Marten Seemann <[email-masked]<mailto:[email-masked]>>
Subject: Re: Connection ID lengths 1, 2 and 3

---

From: Marten Seemann <[email-masked]>
Date: Sun, 15 Jul 2018 17:51:59 +0100

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 <[email-masked]>
wrote:

> 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 <[email-masked]> 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.
>>
>>
>>
>> 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.
>>
>> 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.
>>
>>
>>

---

From: "Deval, Manasi" <[email-masked]>
Date: Sun, 15 Jul 2018 17:04:25 +0000

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  <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
I would still prefer if we can reduce the number of sizes supported.

Thanks,
Manasi

•        Parse DCid length,

•        Add 3,

•        Parse DCid length

•        Add 3,

•        Read DCID

•        Read SCID.

b.      In addition to this, the arithmetic logic to add 3 is a little more specialized than a logical operation, e..g.shift left.

Thanks,
Manasi

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sun, 15 Jul 2018 13:08:13 -0400

version is only during handshake, CID is on all packets

On 15 July 2018 at 19.04.49, Deval, Manasi ([email-masked]) 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  <[email-masked]> wrote:

On Sun, Jul 15, 2018 at 12:41 PM Deval, Manasi <[email-masked]>
wrote:

>> more specialized than a logical operation, e..g.shift left.
>>
>>
>>
>> *From:* QUIC [mailto:[email-masked]] *On Behalf Of* Mikkel Fahnøe
>> Jørgensen

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 Jul 2018 10:55:26 -0700

> have a thousand versions, we are always sending 3 extra bytes on the wire.

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

> 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
>>> more specialized than a logical operation, e...g.shift left.
>>>
>>>
>>>
>>> *From:* QUIC [mailto:[email-masked]] *On Behalf Of *Mikkel
>>> Fahnøe Jørgensen

---

From: "Deval, Manasi" <[email-masked]>
Date: Sun, 15 Jul 2018 20:36:59 +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 <[email-masked]> wrote:
> 
> existing fast crypto primitives to encode connection ID

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 Jul 2018 15:14:30 -0700

Not sure what went wrong with your quoting. You are responding to Ian
Swett, not to me.

On Sun, Jul 15, 2018 at 1:36 PM, Deval, Manasi <[email-masked]>
wrote:

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