Subject: Re: [quicwg/base-drafts] don't allow 0 as a packet number (#832)

From: janaiyengar <[email-masked]>
Date: Thu, 16 Nov 2017 06:23:21 +0000 (UTC)

With the new packet number encoding, we end up needing only 62 bis for the packet number, which means you can use a signed int for representing it and < 0 as a sentinel value. I'll be ok with either 0 or 1 as the initial value.

Can we agree on something here and wrap this issue up? I'll be happy whichever way we go, but let's choose one and move on.

-- 
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/832#issuecomment-344827895

---

From: janaiyengar <[email-masked]>
Date: Thu, 16 Nov 2017 06:25:47 +0000 (UTC)

To be clear: Given we can have a < 0 sentinel value, I'm fine with 0 as the initial number.

-- 
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/832#issuecomment-344828280

---

From: pravb <[email-masked]>
Date: Thu, 16 Nov 2017 06:39:16 +0000 (UTC)

Let's explicitly disallow wraparound then with the recognition that we then put a limit on the amount of data a QUIC connection can transfer whereas there is no such limit in TCP. I think if a received packet causes a change in the connection state machine then we don't need a Boolean or stats counter to detect this and we do not need any sentinel values. Also I can't think of any other use cases for sentinel values so if anyone else has any ideas please speak out soon.

-- 
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/832#issuecomment-344830311

---

From: janaiyengar <[email-masked]>
Date: Thu, 16 Nov 2017 06:51:05 +0000 (UTC)

Thinking about this a bit more and chatting with @ianswett, not randomizing will risk ossification of the initial packet number.  I'm wondering if it's valuable to randomize anyways, just to avoid issues, and in the interest of making more fields unpredictable. Thoughts?

-- 
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/832#issuecomment-344832127

---

From: MikkelFJ <[email-masked]>
Date: Thu, 16 Nov 2017 08:07:43 +0000 (UTC)

In the context of connection migration I just sent a mail to the QUIC WG list suggesting to avoid gaps such that the packer numbers cannot effectively be exhausted. One option is to encode/encrypt packet numbers, the other was to reset packet numbers during migration. Encoding would deal with ossification issues. Randomizing early would work against keeping the packet number space large, though not as much as for migrations since it is a one off.

-- 
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/832#issuecomment-344845807

---

From: Martin Thomson <[email-masked]>
Date: Thu, 16 Nov 2017 08:19:18 +0000 (UTC)

The ossification question is why - I think - we added the randomization in the first place.  We should pick something.

Happy to prohibit wrapping as @pravb requests.

-- 
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/832#issuecomment-344848231