Subject: [quicwg/base-drafts] Packet number echo with fixed-length, 32-bit packet and echo numbers (#393)

From: Brian Trammell <[email-masked]>
Date: Mon, 13 Mar 2017 04:14:15 -0700

Version of #391 (replacing #368), adds optional packet number echo to the short header, but makes both packet number and packet number echo fields in the short header 32 bits. Implemented largely by removing complexity from #391.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * manually rebase packet number echo on post-#361 master
  * missing [optional brackets] on echo
  * remove all variable-length-ness from packet number echo, manually rebased on full #361

-- File Changes --

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

-- Patch Links --

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

---

From: Marten Seemann <[email-masked]>
Date: Mon, 13 Mar 2017 07:25:18 -0700

marten-seemann commented on this pull request.

 ### Initial Packet Number
 
 The initial value for packet number MUST be a 31-bit random number.  That is,
 the value is selected from an uniform random distribution between 0 and 2^31-1.
 {{?RFC4086}} provides guidance on the generation of random values.
 
-The first set of packets sent by an endpoint MUST include the low 32-bits of the
-packet number.  Once any packet has been acknowledged, subsequent packets can
-use a shorter packet number encoding.
+
+### Packet Number Echo {#packet-number-echo}
+
+If present, the Packet Number Echo field contains the least significant 32 bits
+of the highest packet number seen in the opposite direction before this packet
+was sent. This allows devices along the path to estimate round-trip times and
+observe indications of loss, for passive performance measurement of QUIC flows
+equivalent to present techniques using TCP sequence and acknowledgement numbers
+and/or timestamps.
+
+The Packet Number Echo field SHOULD be present on 1-RTT packets containing at
+least one ACK frame (see {{frame-ack}}). For efficiency's sake, it MAY be

Is there any reason hat the Echo should be in packets containing ACK frames? Since the Echo is only used by middleboxes, for whom the payload is opaque anyway, it shouldn't matter which packet the Echo is sent on.
Even though it doesn't reveal a lot about the packet contents, I'd prefer to not divulge any information about the frame types contained in a packet, unless there's a compelling reason to do so. 

-- 
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/393#pullrequestreview-26561797

---

From: Marten Seemann <[email-masked]>
Date: Mon, 13 Mar 2017 07:29:10 -0700

+omitted if a 1-RTT packet containing an ACK frame has already been sent during a
+time interval equal to the sender's current estimate of the RTT.

This is actually a big difference. When a peer is sending stream data, the receiver will generate an ACK for every two packets received. On high bandwidth links, this means that a lot of ACKs are sent per RTT.
I think we should be explicit about this and just require one Echo per 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/393#pullrequestreview-26562837

---

From: Marten Seemann <[email-masked]>
Date: Mon, 13 Mar 2017 07:32:09 -0700

> @@ -676,42 +682,38 @@ CONNECTION_CLOSE frame with the error code QUIC_SEQUENCE_NUMBER_LIMIT_REACHED
 (connection termination is described in {{termination}}.)
 
 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.
+wire, only the least significant 32 bits of the packet number are transmitted
+over the wire. The actual packet number for each packet is reconstructed at the
+receiver based on the largest packet number received on a successfully
+authenticated packet.

Is there any reason for a receiver to reconstruct the echoed packet number? If I understand this PR correctly, this value is of no interest for the end points, but only for middleboxes. 

-- 
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/393#pullrequestreview-26563695

---

From: Brian Trammell <[email-masked]>
Date: Mon, 13 Mar 2017 07:32:31 -0700

> On 13 Mar 2017, at 15:25, Marten Seemann <[email-masked]> wrote:
> 
> @marten-seemann commented on this pull request.
> 
> In draft-ietf-quic-transport.md:
> 
> >

The intention here was to make it easy to determine when to place an echo on any given packet. Since the echo enhances the information available in a TCP ACK, a QUIC ACK seemed the most analogous place to do this. You're right, though; there's no reason for anything on path to know that a given packet contains ACK frames or not. So "at least once per RTT" is sufficient.

> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub, or mute the thread.
> 

-- 
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/393#issuecomment-286124585

---

From: Brian Trammell <[email-masked]>
Date: Mon, 13 Mar 2017 07:33:37 -0700

> On 13 Mar 2017, at 15:32, Marten Seemann <[email-masked]> wrote:
> 

This text refers to the packet number, not the echo.

-- 
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/393#issuecomment-286124890

---

From: Marten Seemann <[email-masked]>
Date: Mon, 13 Mar 2017 07:37:09 -0700

My bad. As Brian pointed out, this change refers to the actual packet number. I assumed it referred to the Echo, since there were changes in this PR (which probably need a separate issue then, don't they?). 

-- 
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/393#discussion_r105674920

---

From: janaiyengar <[email-masked]>
Date: Mon, 13 Mar 2017 12:38:33 -0700

janaiyengar commented on this pull request.

or alternatively, you could remove the largest_acked out of the ACK frame and require this on all packets that carry an ACK frame.

-- 
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/393#discussion_r105752434

---

From: Brian Trammell <[email-masked]>
Date: Wed, 15 Mar 2017 00:18:49 -0700

thinking about it a bit more, I think the "do we want variable length packet numbers?" discussion is completely orthogonal to the "do we want packet number echo?" discussion, so let's talk about this in #391 for now...

-- 
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/393#issuecomment-286660594