Subject: [quicwg/base-drafts] Border cases in packet number decoding (#674)

From: Christian Huitema <[email-masked]>
Date: Fri, 30 Jun 2017 16:59:10 +0000 (UTC)

I am afraid that the specification of packet number decoding in the transport spec is a bit ambiguous.
The transport spec says:

> The sender MUST use a packet number size able to represent more than twice as large a range than 
> the difference between the largest acknowledged packet and packet number being sent. A peer 
> receiving the packet will then correctly decode the packet number, unless the packet is delayed in
> transit such that it arrives after many higher-numbered packets have been received. An endpoint
> SHOULD use a large enough packet number encoding to allow the packet number to be recovered
> even if the packet arrives after packets that are sent afterwards.
>
> As a result, the size of the packet number encoding is at least one more than the base 2 logarithm of 
> the number of contiguous unacknowledged packet numbers, including the new packet.
>
> For example, if an endpoint has received an acknowledgment for packet 0x6afa2f, sending a packet 
> with a number of 0x6b4264 requires a 16-bit or larger packet number encoding; whereas a 32-bit
> packet number is needed to send a packet with a number of 0x6bc107.

So, let's suppose a node that is processing a packet. The packet header says that the packet number is encoded on 2 bytes, and the value is PN=0x8000. The highest received number is R=0x10000. Should the receiver expand PN to PN64=0x180000, or to PN64=0x8000?

-- 
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/674

---

From: Patrick McManus <[email-masked]>
Date: Fri, 30 Jun 2017 17:07:28 +0000 (UTC)

`A packet number is decoded by finding the packet number value that is closest to the next expected packet. The next expected packet is the highest received packet number plus one.`

what I have done is interpreted that given 16 bits of recvd = 0x8000, and expected = 0x10001 .. the packet is decoded as 0x8000 because 0x8000 is closer to 0x10001 than the other choice 0x18000

nonetheless, I would much prefer packet numbers to be concrete 64 bit numbers variably length encoded somehow.

-- 
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/674#issuecomment-312322142

---

From: ianswett <[email-masked]>
Date: Fri, 30 Jun 2017 17:13:57 +0000 (UTC)

Can you clarify what the ambiguity is?  0x8000 is closer to 0x10001 than 0x18000 is as Patrick said, so you choose 0x8000.

Minus the variable length aspect, I don't believe this is that dissimilar from how TCP decodes sequence numbers, is it?

-- 
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/674#issuecomment-312323605

---

From: ianswett <[email-masked]>
Date: Fri, 30 Jun 2017 17:31:35 +0000 (UTC)

Actually, in this case 0x18000 is closer by 2:
 0x8000 = 32768
 0x10001 = 65537
 0x18000 = 98304

But Patrick's logical reasoning is still correct.

-- 
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/674#issuecomment-312327504

---

From: Patrick McManus <[email-masked]>
Date: Fri, 30 Jun 2017 17:34:06 +0000 (UTC)

hah - yes. a little base-10 brain action.

-- 
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/674#issuecomment-312328084

---

From: Christian Huitema <[email-masked]>
Date: Fri, 30 Jun 2017 17:57:43 +0000 (UTC)

Thanks for the explanation. Right now, I am just trying to write test vectors, and I was little bit puzzled. So, to keep my example, the test vector will be:
Highest = 0xFFFF
Expected = 0x10000
PN = 0x8000
Hypothesis 1: 0x18000, delta to expected = 0x8000
Hypothesis 2: 0x8000, delta to expected = 0x8000
Do something arbitrary.
(Prefer lowest value, probably.)

Of course, this algorithm breaks down in this particular case:
Highest = 0x10000
Expected = 0x10001
PN = 0x8000
Hypothesis 1: 0x18000, delta to expected = 0x7FFF
Hypothesis 2: 0x8000, delta to expected = 0x8001
Prefer Hypothesis 1, PN64 = 0x18000

-- 
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/674#issuecomment-312333634