Subject: [quicwg/base-drafts] Packet number echo (#351)

From: Brian Trammell <[email-masked]>
Date: Wed, 01 Mar 2017 12:22:59 -0800

Initial suggestion to address #269, based on alternate header proposal from @janaiyengar 
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Partial commit of new header format
  * initial packet number echo suggestion

-- File Changes --

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

-- Patch Links --

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

---

From: Brian Trammell <[email-masked]>
Date: Thu, 02 Mar 2017 09:32:17 -0800

britram commented on this pull request.

> @@ -470,7 +472,9 @@ this version, it contains:
   * 01: 1-RTT packet (packet number size = 1)
   * 02: 1-RTT packet (packet number size = 2)
   * 03: 1-RTT packet (packet number size = 4)
+  * 07: 1-RTT packet (packet number size = 4, with packet number echo)

Can add two additional codepoints here:
```
* 05: 1-RTT packet (packet number size = 1, packet number echo size = 1)
* 06: 1-RTT packet (packet number size = 2, packet number echo size = 2)
```

(I remain skeptical of the tradeoff for varlen packet numbers, but if we're going to have them, we might as well have varlen echo as well.)

-- 
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/351#pullrequestreview-24793177

---

From: ianswett <[email-masked]>
Date: Thu, 02 Mar 2017 09:35:53 -0800

ianswett commented on this pull request.

Sadly, I think a 1 byte echo is commonly too small, whereas 2 bytes is almost always sufficient.  Given this is going to be used on the public internet, I'd define the 2 byte version but not the 1 byte version.

-- 
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/351#discussion_r103983416

---

From: Brian Trammell <[email-masked]>
Date: Thu, 02 Mar 2017 10:24:40 -0800

Makes sense to me. Doesn't this mean we should undefine one-byte packet numbers everywhere, though? (That seems like a distinct PR)

-- 
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/351#discussion_r103994124

---

From: Brian Trammell <[email-masked]>
Date: Thu, 02 Mar 2017 10:46:36 -0800

@britram pushed 1 commit.

1ecfd4f  one and two byte variants as well

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/351/files/af260749758e1a55f88f21aba339f0ba718d5a9f..1ecfd4f89076579d443919e7a0d2001ccd565684

---

From: Martin Thomson <[email-masked]>
Date: Thu, 02 Mar 2017 19:21:34 -0800

This needs to say how you decode a truncated packet number from the echoed field.  Decoding based on the largest acknowledged packet number that has already been seen is probably right.  

Al is right in observing that you could remove the number from the ACK frame to make the cost of this feature zero bytes, but it's really difficult to swallow the implementation complexity that introduces.  STOP_WAITING with its reliance on public flags is an abomination.  On the other hand, having packet numbers in both directions allows you to have an anchor point for referring to packets that travel in either direction.

You also need to change the guidance around picking a packet number size.  If you are sending an echo, then you need to use the greater of (the number of this packet - highest packet number from those you have sent and received an acknowledgment) and (the echoed packet number you intend to include - the highest acknowledged packet number that was in the most recent packet that contained an ACK) to determine how many octets to devote to the encoding so that you avoid decoding problems.  In other words, I am starting to agree more strongly with Brian that having variable length packet numbers hurts and I want that hurting to stop.

(The CI errors are in @janaiyengar's commit, which was never really intended to be complete.  Jana obviously hasn't bothered installing the commit hook.)

-- 
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/351#issuecomment-283854603

---

From: Brian Trammell <[email-masked]>
Date: Fri, 03 Mar 2017 11:57:23 -0800

re: guidance on packet number size. ouch. yes, you're right. For me, this indicates that adding packet echo implies constant size (and probably 4-byte) packet numbers in version 1.

(re: CI errors; yep, I saw these, declined to fix them as I plan to merge @janaiyengar's `header` branch again, which will presumably fix them in a way that would conflict with mine...)

-- 
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/351#issuecomment-284054749

---

From: Brian Trammell <[email-masked]>
Date: Tue, 07 Mar 2017 00:57:52 -0800

This has been replaced by #367 (with variable-length numbering) and #368 (with fixed-length, 32-bit numbering).

-- 
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/351#issuecomment-284660765

---

From: Brian Trammell <[email-masked]>
Date: Tue, 07 Mar 2017 00:57:52 -0800

Closed #351.

-- 
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/351#event-989181402