Re: Connection ID lengths 1, 2 and 3

["Deval, Manasi" <[e-mail]>]

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