Subject: [quicwg/base-drafts] Cleanup packet number text (#288)

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Feb 2017 00:35:44 -0800

This builds on #283 and it includes fixes the infidelities I noticed but did not fix during the process of creating that PR.

This is intended to be editorial, but it does remove the use of "in flight" as noted in #286.  I have defined "outstanding packets" to be the packets that aren't acknowledged or lost and made the formula count those packets.  I think that's probably not the right thing, and the definition in https://github.com/quicwg/base-drafts/issues/286#issuecomment-278883235 is probably closer to what is intended, but I was trying my best to avoid changing text and this seemed like the right compromise.

If I'm wrong and this isn't editorial, feel free to tell me what to write so that it can remain so.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Random initial packet number
  * Rewrite text on packet numbers

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/288.patch
https://github.com/quicwg/base-drafts/pull/288.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/288

---

From: ianswett <[email-masked]>
Date: Fri, 10 Feb 2017 12:12:56 -0800

ianswett commented on this pull request.

Nice clarifications.

-* If a sender sets PACKET_NUMBER_SIZE bits to 10, it MUST NOT have more than
-  (2^30) packets in flight.
+To enable unambiguous reconstruction of the packet number, an endpoint MUST use
+a packet number size that is able to represent 4 times more packet numbers than
+the endpoint has currently outstanding.  A packet is outstanding if it sent but
+has neither been acknowledged nor been marked as lost (see {{QUIC-RECOVERY}}).
+As a result, the size of the packet number encoding is at least two more than

size in bits?

> @@ -646,10 +657,10 @@ that the client selected.
 
 When the client receives a Version Negotiation packet from the server, it should
 select an acceptable protocol version.  If the server lists an acceptable
-version, the client selects that version and resends all packets using that
-version. The resent packets MUST use new packet numbers.  These packets MUST
-continue to have the VERSION flag set and MUST include the new negotiated
-protocol version.
+version, the client selects that version and reattempts to created a connection
+using that version.  The client MUST update packet numbers when attempting to

I'm not sure what "client MUST update packet numbers" means?  

I would change "reattempts to created a connection using that version." to "attempts to create a new connection using that version." and then remove this sentence, because I think it's clear a new connection has a new packet number space.  

I think we should specify whether the connection id should be the same?  I believe it should be, to ensure the routing is the same.

We should also specify what happens if the version negotiation packet includes the version you just tried to use.  I believe we should not try again.

-The complete packet number is a 64-bit unsigned number and is used as part of a
-cryptographic nonce for packet encryption.  To reduce the number of bits
-required to represent the packet number over the wire, at most 48 bits of the
-packet number are transmitted over the wire.  A QUIC endpoint MUST NOT reuse a
-complete packet number within the same connection (that is, under the same
-cryptographic keys).  If the total number of packets transmitted in this
-connection reaches 2^64 - 1, the sender MUST close the connection by sending a
+## Packet Numbers
+
+The packet number is a 64-bit unsigned number and is used as part of a
+cryptographic nonce for packet encryption.  Each endpoint maintains a separate
+packet number for sending and receiving.  The packet number for sending MUST
+increase by one after sending any packet.

At least one?

-- 
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/288#pullrequestreview-21329755

---

From: Martin Thomson <[email-masked]>
Date: Sun, 12 Feb 2017 16:03:27 -0800

@martinthomson pushed 1 commit.

49c2f4a  Ian had some comments

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/288/files/467b6a417318d321666b3257d9448feb978e354c..49c2f4a7e942daa238624fc5a64d925add22b535

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 13 Feb 2017 16:34:36 -0800

igorlord commented on this pull request.

> +To reduce the number of bits required to represent the packet number over the
+wire, only the least significant bits of the packet number are transmitted over
+the wire, up to 48 bits.  The actual packet number for each packet is
+reconstructed at the receiver based on the largest packet number received on a
+successfully authenticated packet.
+
+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.  For example, if the highest successfully authenticated
+packet had a packet number of 0xaa82f30e, then a packet containing a 16-bit
+value of 0x1f94 will be decoded as 0xaa831f94.
+
+To enable unambiguous reconstruction of the packet number, an endpoint MUST use
+a packet number size that is able to represent 4 times more packet numbers than
+the endpoint has currently outstanding.  A packet is outstanding if it sent but
+has neither been acknowledged nor been marked as lost (see {{QUIC-RECOVERY}}).

Do we really want to define "outstanding" by the number of packets w/o ACKs?  I'd rather define it by the number of packet numbers between the current packet number and the earliest packet w/o ACKs.

For a high bandwidth, high latency connection, if I have packet 10 "delayed", but packets 11-1033 have been acked, do I really only have 1 packet "outstanding" and therefore can use the smallest number of bits to encode the following packet 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/pull/288#pullrequestreview-21651873

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Feb 2017 16:49:33 -0800

martinthomson commented on this pull request.

@igorlord, I agree, as does Ryan.  But I'm trying to keep this PR strictly editorial and I think that this is what the original text is trying to say.  I will create a follow-up PR that makes the change you suggest.

---

From: janaiyengar <[email-masked]>
Date: Thu, 16 Feb 2017 22:24:08 -0800

janaiyengar approved this pull request.

LGTM -- the new text is much better!

-- 
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/288#pullrequestreview-22429367

---

From: janaiyengar <[email-masked]>
Date: Thu, 16 Feb 2017 22:24:17 -0800

Merged #288.

-- 
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/288#event-966337468