Subject: [quicwg/base-drafts] Explicit support for on-path calculation of loss and congestion of QUIC flows (#632)

From: Brian Trammell <[email-masked]>
Date: Wed, 14 Jun 2017 07:39:18 -0700

It might be useful for on-path devices to be able to calculate the (1) loss and (2) non-loss indication of congestion (i.e., ECN) experienced by each side of a QUIC flow from a single observation point.

Since #609 essentially marks every congestion window of a QUIC flow with an alternating spin, evaluation of the time-series of congestion window sizes could allow passive analysis of congestion window reductions, from which loss can be inferred if the assumption that the sender is using loss-based congestion control is valid.

A less inference-based solution would be something like the loss bit discussed in #279.

An even more explicit way to do this would be to implement something like [ConEx](https://tools.ietf.org/html/rfc7713) in the QUIC short header. 

-- 
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/632

---

From: janaiyengar <[email-masked]>
Date: Wed, 14 Jun 2017 11:36:42 -0700

I'm confused. Is this issue asking for a way for mboxes to do loss
estimation? I didn't hear folks really asking for this, so before digging
into solutions, I'd like to ask for motivation.

On Wed, Jun 14, 2017 at 3:39 PM, Brian Trammell <[email-masked]>
wrote:

> It might be useful for on-path devices to be able to calculate the (1)
> loss and (2) non-loss indication of congestion (i.e., ECN) experienced by
> each side of a QUIC flow from a single observation point.
>
> Since #609 <https://github.com/quicwg/base-drafts/pull/609> essentially
> marks every congestion window of a QUIC flow with an alternating spin,
> evaluation of the time-series of congestion window sizes could allow
> passive analysis of congestion window reductions, from which loss can be
> inferred if the assumption that the sender is using loss-based congestion
> control is valid.
>
> A less inference-based solution would be something like the loss bit
> discussed in #279 <https://github.com/quicwg/base-drafts/issues/279>.
>
> An even more explicit way to do this would be to implement something like
> ConEx <https://tools.ietf.org/html/rfc7713> in the QUIC short header.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/632>, or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AKjg1ETiKkbBsm_M8VfjwiPOBGSWp4APks5sD_CWgaJpZM4N5-ze>
> .
>

-- 
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/632#issuecomment-308520743

---

From: Brian Trammell <[email-masked]>
Date: Fri, 16 Jun 2017 07:41:23 -0700

Yes, this is to cover loss estimation. We didn't discuss this at the interim, but it did come up in my survey of exported, passively measured metrics. This is here for completeness.

It's less important to react to loss on a per-flow basis than it is latency, though. So as long as (1) we can assume UDP and TCP traffic are treated equivalently by the link/queue at which the loss occurs and (2) there is some TCP traffic through that link/queue, inference-based observation of TCP will continue to work.

-- 
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/632#issuecomment-309044294

---

From: Christian Huitema <[email-masked]>
Date: Sun, 18 Jun 2017 20:54:16 -0700

Brian, how important really is this loss estimation? I don't think that losses can really be estimated by watching the congestion window. The variations of that window will depend on the specific algorithm implemented by the nodes, and also on the actual load. If this is really important, we may need to dedicate a "loss bit" in addition to the "latency bit". 

-- 
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/632#issuecomment-309332680

---

From: Brian Trammell <[email-masked]>
Date: Mon, 19 Jun 2017 00:27:02 -0700

Loss measurement is currently useful in a couple of network troubleshooting and capacity planning tasks: isolating congested links (and upgrading or shifting load away from them), as well as differentiating actual loss at the link layer from congestion (and repairing lossy links). It is useful to measure these conditions both on one's own network (where you can repair them yourself) as well as isolating them to some upstream or downstream path on other networks (so you can work to shift traffic away from those networks).

Universal deployment of useful AQM + ECN would both reduce the absolute magnitude of the congestion problem as well as make loss and congestion easily distinguishable. I'm optimistic about the time horizon here, but it's still measured on the order of decades.

You're right that the inference-based method, assuming that flight size reduction is loss- or congestion-signal related, is not a very high-fidelity signal, and may be useless depending on how the sender does transmission scheduling. So if we're serious about supporting this, I think we do need to take a good look at the ConEx mechanism and see if there's a low-overhead way to support it in QUIC.

-- 
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/632#issuecomment-309360150

---

From: Lars Eggert <[email-masked]>
Date: Mon, 19 Jun 2017 00:34:27 -0700

I think it's actually a feature that loss information is NOT explicitly visible with QUIC, because packet loss ratio is a pretty useless metric in the first place. (The 5G people still dream about the "lossless" network, no matter how little sense that makes.) 

With RTT-scale delay information and if we - say - required QUIC to try and negotiate ECN, those two signals (esp. correlated) are much more useful.

-- 
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/632#issuecomment-309361550

---

From: ianswett <[email-masked]>
Date: Mon, 19 Jun 2017 06:56:05 -0700

I believe a single bit for loss would be extremely low fidelity, because losses are commonly correlated, so it may actually be more misinformation than information.

I've seen one case when this would have been nice to have, but I think there are other ways to monitor loss that are more useful(ie: I'm seeing a lot of loss at this peering point, etc).

Brian, I believe you mentioned writing up a proposal for an extended 'debug' header that would not be default enabled, but be available for detailed network debugging.  If we were to adopt that, I think loss would be helpful there.

-- 
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/632#issuecomment-309447071

---

From: Brian Trammell <[email-masked]>
Date: Tue, 20 Jun 2017 01:22:43 -0700

So it turns out I actually agree with Lars here: loss, in and of itself, is a relatively useless metric without other things to correlate with. Requiring ECN negotiation for QUIC would actually do more for the (long-term) measurability of the protocol than mandating loss exposure, in part because future QUICs may have different transmission schedulers which would react differently to loss. The question is how useful CE mark based measurement will be in the intermediate term, as we transition from relatively little marking on path to "some" marking on path.

More useful would be a generalization of the ConEx mechanism, which could certainly go into a debug header, and would allow a single point to get information about CE markings (as well as loss) both on the upstream and the downstream. Would need to look into whether any TCP-centric assumptions were built into that mechanism.

-- 
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/632#issuecomment-309680807