Starting packet number

[quicwg]

Starting packet number

[ianswett]

This is possible today, but it should be required or highly recommended.

[ianswett]

When fixing this, also fix the following inconsistency(noted by Mirja):
Section 4.2 (Regular Packets) page 10 says: "The first packet send by an endpoint MUST have a packet number of 1."
And section 7 (Packetization and Reliability) page 28 says: "That is, the first packet in both directions of the connection MUST have a packet number of 0."

[JimRoskind]

Reading the motivation (re: off-path guessing of connection ID), I'm hopeful that a client would use a good Random Number Generator (RNG) and not produce a "guessable" connection ID. The presumption of a "good RNG" is indeed central to having many clients connecting to a single server (without collision). If one would posit a poor RNG... then in addition to collisio problems, I'd be wary that a RNG used to select a "unguessable" initial packet number would be problematic. Bottom line: I don't grok the security based motivation.

The other motivation is to prevent "ossification." Can someone provide a plausible motivation for a "need" to start at a different packet number, and avoid "ossification" in this context? I would have expected that standardization in this area simplifies code, and would not be a long-term problem.

[mnot]

Discussed in Tokyo; agreement that it's a good idea. Randomise some number of the bottom bits.

[martinthomson]

Currently, we aren't sure how many bits are going to be in initial packets. When @ekr produces a proposal for the packet headers, I think that this should include a fixed-size slot for the packet number. That will make this easier to write up.

[martinthomson]

This was addressed in #283.