Subject: [quicwg/base-drafts] Make Packet Number a standard varint, with no inference (#1502)

From: martinduke <[email-masked]>
Date: Fri, 29 Jun 2018 09:07:51 -0700

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1502

---

From: ianswett <[email-masked]>
Date: Fri, 29 Jun 2018 16:13:51 +0000 (UTC)

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1502#issuecomment-401402267