Make Packet Number a standard varint, with no inference

[martinduke]

Now that packet numbers start at 0, I am not sure there is a ton of value in truncating these numbers. There are some advantages to making it a standard 1 to 8 byte-varint:

• Reuse existing varint code instead of implementing something special that can be screwed up.
• Eliminate the need to infer the most significant bits of the PN, which is another thing to screw up that has pretty bad consequences for connection integrity (e.g. acking packets that weren't actually received)
• Eliminating the inference also makes it easier for debugging tools like Wireshark to correctly display the PN.

I assert that the fraction of connections that will need 64-bit packet numbers will be exceedingly small. There are probably very minor bit-efficiency issues (connections with 255-64K packets sent at a relatively low rate, etc), but these pale in comparison to the bytes we've put into variable length CIDs, etc.

We already encoding the PN this way in the Largest_acked field of the ACK frame, so I believe the same principles should apply.

If people agree with this assessment, I'll drop a PR.

[ianswett]

This will make users of long-lived bandwidth sensitive apps unhappy. WebRTC audio-only connections are a good example of this. Today they can commonly use a single byte packet number, and with this they'd commonly be using 4 byte PNs.

[martinthomson]

pretty bad consequences for connection integrity (e.g. acking packets that weren't actually received)

If you reconstruct the wrong packet number, all that happens is that you can't decrypt the packet. That's not fatal, it just looks like loss. The damage is limited to a reduction in throughput.

In addition to the concern @ianswett raised, a 2-bit-prefixed varint can use the one octet encoding less often. Audio is probably OK to use a one octet encoding; the one-octet/6-bit encoding can't be used at around a 640ms RTT for the most common 20ms latency, which is a pretty long hop for real-time audio. Add video and higher packet rates and lower latency encodings start to have to use 2 octets on a shorter RTT. The current encoding allows the rate or RTT to double before spilling over.

[siyengar]

Size overhead also becomes important in use cases like text messaging where the message size becomes comparable to the protocol overhead. With this change we would rollover to 2 bytes with 256 packets which in effect means 256 messages. Sending a lol to someone where the protocol overhead itself is larger than the message.

One alternative which might be interesting is var length encoding of the truncated packet number so that we don’t need the 4 byte packet number type in the short header

[martinduke]

@martinthomson Good point on the drops. I know when I'm licked. Closing.