Subject: Re: [quicwg/base-drafts] On-path calculation of RTT (#631)

From: Christian Huitema <[email-masked]>
Date: Wed, 05 Jul 2017 00:24:47 +0000 (UTC)

Any idea how to resolve this issue? The thread is silent now. We have three plausible options:

1) Do nothing. This means that monitoring RTT will be hard, and will have to rely on heuristics.
    What we described in the discussion as "using machine learning to derive information from 
    traffic patterns." It is probably doable, albeit error prone and somewhat expensive.

 2) Adopt the dedicated bit design.

 3) Change the design to have dedicated packet types instead. Currently we have "1-RTT Protected
    (key phase 0)" and "1-RTT Protected (key phase 1)". We could have "1-RTT Protected (key phase 0)
    with spin 0" and "1-RTT Protected (key phase 0) with spin 1". For the short packet form, we could 
    either keep the bit, much like we have the epoch bit, or create two packet types for the spin values,
    so we don't burn the bit.

The behavior of option 3 would be about the same as the current PR, but would only enable measurement on 1RTT packets.

Personally, I don't care much. But if we are going to mess with the packet format, it is probably better to decide sooner rather than later.

-- 
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/631#issuecomment-312970044

---

From: Brian Trammell <[email-masked]>
Date: Wed, 05 Jul 2017 08:21:05 +0000 (UTC)

Since (1) would be a significant step back from the heuristics currently used for TCP latency, and we have a proof of concept that shows it is avoidable while honoring other goals we have for linkability resistance across five-tuple migrations (see #231, #598), I'm not very enthusiastic about doing nothing.

I think there are a couple of additional points in the design space beyond (2) and (3):

(4) Simple packet number echo as in (#269) would also support RTT measurement via demonstration of receipt, regardless of whether the packet number is encrypted or not.

(5) Simple echo of N (protected) bytes at offset M would also support RTT measurement via demonstration of receipt, without relying on the packet number being decodable in the header. 

I'm pretty sure it's okay to restrict measurement to 1RTT packets. Any of these seem reasonable to me. (4) may have more or less utility than (2) and (3) depending on what we decide with respect to the semantics attached to path-visible packet numbers.

-- 
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/631#issuecomment-313035480

---

From: ianswett <[email-masked]>
Date: Wed, 05 Jul 2017 16:19:38 +0000 (UTC)

I'm happy with either 2 or 3 and prefer them over 1, 4 or 5, 

2 or 3 provides middleboxes both end to end RTT and downstream RTT, whereas 4 and 5 only allow measurement of downstream 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/issues/631#issuecomment-313152952

---

From: ianswett <[email-masked]>
Date: Wed, 05 Jul 2017 16:27:11 -0700

I did think of one quirk with 2 or 3 we likely need to add some text for, which is what do about upstream reordering.  Even if the hosts are fixing reordering, if reordering is observed upstream, we either need to:
1) Supply a heuristic on how to filter it out.
2) Expose packet number so the middlebox can fix reordering.
3) Assume it doesn't matter in aggregate.

For #1, we could do a two packet edge trigger instead of 1 if packet number doesn't end up being exposed.  Based on looking at traces and the metrics I've seen, I think that would fix the vast majority of reordering.

As long as packet number is exposed, I'd suggest we use that to fix the problem.

-- 
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/631#issuecomment-313253817

---

From: Martin Thomson <[email-masked]>
Date: Wed, 05 Jul 2017 17:18:39 -0700

Right now, without packet number encryption, those are available.  If they go away, then the heuristic approach is fine, and there is no harm in also saying that significant reordering might be impossible to detect, so anyone doing measurements has to accept the possibility that their measurements will have some noise.  

@ianswett's suggestion to use multiple packets as a heuristic is fine, but you might only do that if you notice a large change in RTT (a severe drop is likely to appear in the case that you get reordering, for instance).

-- 
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/631#issuecomment-313261126

---

From: mirjak <[email-masked]>
Date: Mon, 10 Jul 2017 05:26:30 -0700

If we keep exposing the packet number, I’m actually still in favor of having the packet number echo. I don’t think the overhead is an issue because you don’t have to send it on every packet, however, if you send it you can also use it as a confirmation signal where needed without adding extra bits. Also I’m in favor of exposing the packet number because this gives the network a simple estimate of re-ordering and so-far-on-the-path packet loss. While it is good to discuss these issue/properties separately, I don’t think these things are completely independent for the resulting wire format design (at least as long as overhead is a concern).

-- 
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/631#issuecomment-314090367

---

From: ihlar <[email-masked]>
Date: Thu, 20 Jul 2017 12:08:03 +0000 (UTC)

Magnus Westerlund sent a proposal to the mailing list where the n least significant bits of the packet number are strictly increased by 1. We could let this portion of the packet number remain visible to the path, it would wrap quite frequently (based on the value of n) but the information would be good enough for most cases of reordering that otherwise might mess up the spin bit signal.

Magnus original proposal:
https://mailarchive.ietf.org/arch/msg/quic/tCcEECogBErU1_SWGZ9odtYAGEc

-- 
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/631#issuecomment-316683560