Subject: Latency measurement in version 1

From: Marcus Ihlar <[email-masked]>
Date: Tue, 14 Nov 2017 08:38:20 +0000

Hi,

The chairs requested feedback to the list wrt to the spin bit, here are some of my thoughts.

# The ability to perform latency measurements is more crucial than packet loss (not saying it is unimportant though). In mobile networks "random" packet loss is effectively zero, congestion related loss is preceded by spikes in latency which will be measurable with the spin bit. Hence, I would suggest we focus on spin bit and leave the packet loss for later versions.

# As version one gets deployed we will see a significant shift of traffic over to QUIC from TCP. In order for the operators to manage the traffic and make sure the desired QoE for the customers is achieved use-cases such as interdomain trouble shooting and certain types of AQM functions, we need a way to do latency measurements from day one. This requires that we have support for latency measurements in version 1.

# Version 1 will be a base line and will be widely deployed, hence if the spin bit is not included from the beginning we will not be able to perform measurement for a large amount of early adopters. Furthermore, since V1 is focusing on HTTP, we will likely see lots of V1 deployments long after V2 is available.

# On the point of whether the bit should be invariant I don´t have a strong opinion.

# If we focus on HTTP2 for QUIC version 1, most of the described corner cases as pointed out in the DT slides go away. Hence, spin bit becomes useful for all cases I can think about.

/Marcus Ihlar

---

From: Frode Kileng <[email-masked]>
Date: Tue, 14 Nov 2017 10:41:35 +0100

On 14/11/17 09:38, Marcus Ihlar wrote:
> # The ability to perform latency measurements is more crucial than 
> packet loss (not saying it is unimportant though). In mobile networks 
> “random” packet loss is effectively zero, congestion related loss is 
> preceded by spikes in latency which will be measurable with the spin 
> bit. Hence, I would suggest we focus on spin bit and leave the packet 
> loss for later versions.
>

This may be true that for  simple cases where "random" packet loss is 
close to zero and that latency spikes is a signal of loss. But there are 
other causes for loss that is hard to troubleshoot and where the spin 
bit is not enough. At least based on my own experience when called in to 
solve more complex mobile network performance issues.

Frode Kileng
Telenor Research

---

From: Frode Kileng <[email-masked]>
Date: Tue, 14 Nov 2017 10:39:08 +0100

> bit. Hence, I would suggest we focus on spin bit and leave the packet 

This may be true that for the simple cases that "random" packet loss is 

Frode Kileng
Telenor Research

---

From: Marcus Ihlar <[email-masked]>
Date: Tue, 14 Nov 2017 16:16:58 +0000

Hi, 

> On 14 Nov 2017, at 17:39, Frode Kileng <[email-masked]> wrote:
> 
> 
>> # The ability to perform latency measurements is more crucial than packet loss (not saying it is unimportant though). In mobile networks “random” packet loss is effectively zero, congestion related loss is preceded by spikes in latency which will be measurable with the spin bit. Hence, I would suggest we focus on spin bit and leave the packet loss for later versions.
>> 
> 
> This may be true that for the simple cases that "random" packet loss is close to zero and that latency spikes is a signal of loss. But there are other causes for loss that is hard to troubleshoot and where the spin bit is not enough. At least based on my own experience when called in to solve more complex mobile network performance issues.
> 
Yes, this is definitely true, spin bit won’t help us solve all problems, and there are cases where packet loss is important to detect. However, I think there is a tradeoff we need to make when it comes to what is reasonable to have in place for version 1. 
Hopefully we’ll see an increased adoption of ECN as well, which will reduce some of the cases where loss is a serious issue today (e.g shallow uplink buffers).