Subject: Re: [quicwg/base-drafts] Packet Number Echo in Public Header (#269)

From: ianswett <[email-masked]>
Date: Wed, 01 Mar 2017 06:40:03 -0800

Technically, the choice of sending it would be unilateral.

But I think if we add this, we need SHOULD(s) on the appropriate times to include this(ie: in packets containing an ack frame).  And I believe we may want this to be a MUST do.  If we believe the path is relying upon them for network management or optimization, then I think a MUST makes sense.  If we don't think the path really needs it, we shouldn't add 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/269#issuecomment-283357460

---

From: martinduke <[email-masked]>
Date: Wed, 01 Mar 2017 09:09:16 -0800

It ought to certainly be at least a SHOULD, and a MUST if no one comes up
with a situation where this might compromise privacy.

On Wed, Mar 1, 2017 at 6:40 AM, ianswett <[email-masked]> wrote:

> But I think if we add this, we need SHOULD(s) on the appropriate times to
> include this(ie: in packets containing an ack frame). And I believe we may
> want this to be a MUST do. If we believe the path is relying upon them for
> network management or optimization, then I think a MUST makes sense. If we
> don't think the path really needs it, we shouldn't add it.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/269#issuecomment-283357460>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AXRMEVbpy5D8x4AfflagYLgViP-ukfoyks5rhYNDgaJpZM4L7P3U>
> .
>

-- 
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/269#issuecomment-283403972

---

From: Brian Trammell <[email-masked]>
Date: Wed, 01 Mar 2017 09:43:58 -0800

Agreed that the goal should be MUST; my point on "unilateral" is that no negotiation is required.

Adding guidance on when/how often to echo (the sweet spot of the overhead/benefit curve) might be a little difficult to make universal, but is worth doing. It'll make a nice (if smallish) bikeshed.

-- 
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/269#issuecomment-283413894

---

From: Martin Thomson <[email-masked]>
Date: Wed, 01 Mar 2017 15:34:40 -0800

This is a lot of bytes to spend and it looks like you want a lot of those bytes spent.  That makes me think that @janaiyengar's arguments about short packet numbers are going to have fun with this.

I agree that if you pick the design you propose, unilateral certainly makes the most sense.  This isn't an optional feature.

BTW, you can't really measure RTT with this given the time between receipt and ACK, but I guess that you can narrow in on a value close to RTT and maybe that's enough.  It's about as good as you get with TCP, as you point out.

-- 
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/269#issuecomment-283507069

---

From: Brian Trammell <[email-masked]>
Date: Wed, 01 Mar 2017 15:50:45 -0800

I'm not sure that 4 (for large-window flows) to 7 (for small-window flows) bytes per RTT in the MUST (see #351) counts as "a lot of bytes". Obviously echoing on every packet with an ACK frame uses more.

You can measure RTT components on each leg (observation point to endpoint A, observation point to endpoint B) and add them together; see e.g. http://queue.acm.org/detail.cfm?id=2539132 (which uses tsval/tsecr, but it doesn't really matter what you're echoing)

-- 
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/269#issuecomment-283510362

---

From: acmacm <[email-masked]>
Date: Wed, 01 Mar 2017 16:35:01 -0800

I support packet number echo at the "MUST" level.  I can't easily correlate an ephemeral path performance indication with a privacy breach, but if someone else can connect the dots I'm willing to learn the linkage. 
In general, I support the Management draft because it has raised several issues I'm interested to follow and resolve during the remaining spec development.  (acmacm is Al Morton)

-- 
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/269#issuecomment-283518200

---

From: ianswett <[email-masked]>
Date: Wed, 01 Mar 2017 17:54:00 -0800

@martinthomson My solution to the short packet number approach is to define a codepoints for 2 byte packet numbers and 2 byte echos.  This covers the vast majority of connections which have limit the max number of outstanding packets to less than 32,000.

-- 
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/269#issuecomment-283531734

---

From: mirjak <[email-masked]>
Date: Thu, 02 Mar 2017 01:55:34 -0800

I might probably okay to always have a short (e.g. 2 byte) echo no matter how long the packet number is because RTT measuremnents are estimated only and you always have to account for potential measurement errors.

-- 
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/269#issuecomment-283608467

---

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

@ianswett yep, have added a comment to this effect to #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/issues/269#issuecomment-283725811

---

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

@mirjak I'm not sure that e.g. a 4-byte PN with a 2-byte echo makes sense: if you actually need four bytes of packet number on a high-delay link, guessing the wrong values for octets 2 and 3 might inject a lot of error. Need to think about this a bit more...

-- 
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/269#issuecomment-283728349

---

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

Note that the required size of the packet number echo is related to the peer's in-flight window, not the echoer's in-flight window. When an endpoint sends a packet echo, it should send the echo using the same size as the packet number it's echoing. So, when deciding whether to use 1, 2, or 4-byte packet number/echo, it should use the maximum of the size of the value to echo and the packet number size its inflight window requires.

-- 
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/269#issuecomment-283730467

---

From: ianswett <[email-masked]>
Date: Thu, 02 Mar 2017 10:23:56 -0800

You're correct Brian, and that's why I tend to think 1 byte packet number echos are a foot gun.

-- 
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/269#issuecomment-283736227

---

From: Al Morton <[email-masked]>
Date: Thu, 02 Mar 2017 10:28:21 -0800

Assuming that we are moving information from the encrypted side to the clear side and the recipient can use it either way, then this proposal doesn't expand the header overhead (but I may be overlooking a detail I haven't learned about yet, mea culpa if 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/issues/269#issuecomment-283737413

---

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

working on updating the PR right now: I think the correct thing to do here is to require that the packet number echo is of exactly the same size as the packet number field on the packet whose number is being echoed.

-- 
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/269#issuecomment-283737662

---

From: ianswett <[email-masked]>
Date: Thu, 02 Mar 2017 10:30:57 -0800

Al, that's an idea I considered.  In that formulation, the largest acked would be expressed outside of the encryption layer and the rest of the ack would be encrypted.  This is a bit awkward from a parsing perspective, but it's worth considering.  For better or worse, it makes this truly required.

-- 
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/269#issuecomment-283738109

---

From: Brian Trammell <[email-masked]>
Date: Fri, 17 Mar 2017 03:30:17 -0700

...see #391 for discussion of possible approaches...

-- 
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/269#issuecomment-287319744