Subject: [quicwg/base-drafts] intial packet number should be 0. (#864)

From: Patrick McManus <[email-masked]>
Date: Thu, 12 Oct 2017 20:13:52 +0000 (UTC)

Closes #850
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/864

-- Commit Summary --

  * intial packet number should be 0.

-- File Changes --

    M draft-ietf-quic-transport.md (13)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/864.patch
https://github.com/quicwg/base-drafts/pull/864.diff

-- 
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/pull/864

---

From: MikkelFJ <[email-masked]>
Date: Thu, 12 Oct 2017 13:59:22 -0700

It is not clear to me if this increment by one is only in the clear text or it applies to all packet numbers, including 1-RTT?

-- 
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/pull/864#issuecomment-336265088

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 12 Oct 2017 21:07:40 +0000 (UTC)

I don't want to pile on, but please, 1 instead of 0. It's convenient in code to have a sentinel value for an invalid packet number and the obvious choices are 0 and MAX_INT64. 0 has the nice virtual of being obvious when printed in base10, whereas MAX_INT64 is just some random big number. In addition, 0 has the property of being less than valid packet number. So this allows you to write code like:

  if current_packet.packet_number > largest_received_packet_:
    UpdateNewLargestPacket()

Without needing to explicitly handle the case where largest_received_packet_ is MAX_INT64.

-- 
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/pull/864#issuecomment-336268670

---

From: ianswett <[email-masked]>
Date: Thu, 12 Oct 2017 14:09:48 -0700

Agreed, let's make this 1.

-- 
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/pull/864#issuecomment-336269837

---

From: ekr <[email-masked]>
Date: Thu, 12 Oct 2017 14:10:41 -0700

Note that if we are starting at 0, you can just use int64_t, tear the
connection down at 2^{63} and use -1 as a sentinel.

-Ekr

On Thu, Oct 12, 2017 at 2:07 PM, Ryan Hamilton <[email-masked]>
wrote:

> I don't want to pile on, but please, 1 instead of 0. It's convenient in
> code to have a sentinel value for an invalid packet number and the obvious
> choices are 0 and MAX_INT64. 0 has the nice virtual of being obvious when
> printed in base10, whereas MAX_INT64 is just some random big number. In
> addition, 0 has the property of being less than valid packet number. So
> this allows you to write code like:
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/pull/864#issuecomment-336268670>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABD1oa0iWapAm8k0B-jcRuD5pubyXcWOks5srn-ZgaJpZM4P3j83>
> .
>

-- 
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/pull/864#issuecomment-336270299

---

From: Nick Banks <[email-masked]>
Date: Thu, 12 Oct 2017 14:11:25 -0700

We already have an issue tracking whether or not to allow 0: #832. I feel the discussion is better served if we keep it in that one place.

-- 
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/pull/864#issuecomment-336270707

---

From: Patrick McManus <[email-masked]>
Date: Thu, 12 Oct 2017 14:27:04 -0700

packet number 0 is already legal (the random range is between 0 and 2^31-1). @nibanks is right, if we want to change that do it in another issue - this PR is to remove the randomness.

-- 
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/pull/864#issuecomment-336276616

---

From: Patrick McManus <[email-masked]>
Date: Thu, 12 Oct 2017 21:27:59 +0000 (UTC)

@mikkelfj all packet numbers

-- 
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/pull/864#issuecomment-336276920

---

From: Patrick McManus <[email-masked]>
Date: Thu, 12 Oct 2017 14:38:40 -0700

`if current_packet.packet_number > largest_received_packet_:
UpdateNewLargestPacket()`

??

if current_packet.packet_number >= next_expected_packet 
 Update()

-- 
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/pull/864#issuecomment-336280209

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 12 Oct 2017 22:39:13 +0000 (UTC)

"if current_packet.packet_number >= next_expected_packet 
  Update()"

Ok fine, this is what I get for not using a real example :) >= works for the particular case I described. But there are cases in the code where we may see the same packet number multiple times but only want to do an operation when we've seen a new largest number and not if we're merely seeing the same largest number against. In those cases >= does not work.

-- 
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/pull/864#issuecomment-336297802

---

From: Marten Seemann <[email-masked]>
Date: Thu, 12 Oct 2017 22:32:18 -0700

We would have the same problems in quic-go. Excluding 0 makes the code so much easier, please make it 1.

-- 
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/pull/864#issuecomment-336354556