Subject: RE: Spin bit discussion - where we're at - use case exsist!!!

From: Roni Even <[email-masked]>
Date: Thu, 23 Nov 2017 06:13:25 +0000

<snip>
> 
> 1) A description of the use case(s) that motivate this proposal. We
> understand that the goal is to measure RTT, but some people are still unclear
> as to why that's necessary to operate a network. Detailed scenarios and
> ideally real-world examples (e.g., from TCP) would help tremendously.
> Saying "I need to debug the network" is not enough detail.
> 
[Roni Even] I submitted such a document but I assume that nobody read it since I would expect that this bullet will at least mention it !!!

See https://tools.ietf.org/id/draft-even-quic-troubleshooting-video-delivery-00.tx 

Please read the document 

Roni

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 28 Nov 2017 10:21:52 -0600

> See https://tools.ietf.org/id/draft-even-quic-troubleshooting-video-delivery-00.tx 

Okay, I went and read the document.  I'm not really sure how much it
helps me understand the scenarios in question.

The high level takeways from my read of the document seem to be:

o Streaming video is common, and a common source of end-user complaints
when it doesn't work well.  (It also uses a lot of bandwidth.)

o A measurement point in the middle of a TCP flow can use TCP segment
numbers to estimate RTT for the upstream and downstream halfs of the
flow, i.e., a video streaming flow that is largely server-to-client
gives a more reliable RTT downstream RTT estimate (i.e., between
measurement point and client).  RTT estimates can be noisy due to
delayed acks and packet loss.

o Such a measurement point can also estimate upstream/downstream loss by
examining the sliding window and observing retransmits. For the
server-to-client video flow, the downstream loss estimate is again the
more reliable one

o Home wifi is a common source of problems, and wifi has a unique
signature of high RTT combined with low loss.  I guess the idea is
supposed to be that a measurement point close to the home network can
"blame" the wifi if it sees high RTT but not much loss on the flow in
question?

o Network operators can use big data analytics to detect deviations from
normal network metrics and isolate faulty network segments.  The above
RTT and loss metrics at measurement points are used as examples but no
claim is made that other metrics would not provide equally functional
input for analytics.

o The network operator can use RTT/loss estimates from a measurement
point near the server as evidence to try to convince the server operator
that the server('s network) is misbehaving.

While the discussion of how a measurement point can use segment numbers
and window information to estimate RTT and loss is useful, I'm not
overly concerned about that discussion and am willing to take it as a given.

I think what might help me understand the utility of these measurements
is a detailed walkthrough of what would happen in some (hypothetical)
case where I as a user call up my ISP and complain that youtube is
misbehaving, assuming I can get to a point where I'm talking to a human
at the ISP that can perform/view this sort of measurement data.  What
information does the ISP need from me?  What's the first thing to do --
insert a measurement point as close to my home router as possible to
rule (out/in) my wifi?  Or do we start off by engaging multiple
measurement points?  Does the "big data" analytics at the network
measurement center come into play at all for this walkthrough or is it
completely separate?

It's also still unclear to me to what extent RTT/loss as input to the
network measurement center's analytics is used because it's easy and
works vs. what research has been done with using other metrics as input
to the analytics.

Thanks,

Ben

---

From: Roni Even <[email-masked]>
Date: Wed, 29 Nov 2017 12:13:18 +0000

Hi,
Some clarifications:
 The measurements are not done to resolve complains but to discover problems ahead of times so the operator can provide their user better QoE.
If the end user complain about the problem it is good if the ISP can tell based on the information he has if this is a problem with the content providers , the user home network or let the user know that they are aware of the problem and are trying to fix it. The ISP put probes in the edge if the ISP network.

Some more comments inline
Roni

> -----Original Message-----
> From: Benjamin Kaduk [mailto:[email-masked]]
> Sent: יום ג 28 נובמבר 2017 18:22
> To: Roni Even; QUIC WG
> Subject: Re: Spin bit discussion - where we're at - use case exsist!!!
> 
> >> understand that the goal is to measure RTT, but some people are still
> >> unclear as to why that's necessary to operate a network. Detailed
> >> scenarios and ideally real-world examples (e.g., from TCP) would help
> tremendously.
> > [Roni Even] I submitted such a document but I assume that nobody read it
> since I would expect that this bullet will at least mention it !!!
> >
> > See
> > https://tools.ietf.org/id/draft-even-quic-troubleshooting-video-delive
> > ry-00.tx
> >
> > Please read the document
> >
> 
[Roni Even] In some cases linear video is a paid service and the end user expect good user experience (QoE) that may be also based on SLA between the content provider and the ISP.

> delayed acks and packet loss.
[Roni Even]  you are right, the implementations take this into account by doing   linear smoothing or moving minimum filter. We did not go into that since the document describes the use case and not the algorithms.
> claim is made that other metrics would not provide equally functional
[Roni Even] we describe what are the current practices .  RTT and packet loss are the basic measurements allowing the calculations of different metrics metrics, for exemle for QoE in IPTV there are ITU-T dcuments like G.1011 and G.1080 recommending metrics for QoE.   As for other measurements which one does he have in mind that will be simple for passive monitoring.

> measurement center come into play at all for this walkthrough or is it
[Roni Even] See above
> works vs. what research has been done with using other metrics as input
[Roni Even] What we are looking at is how to get relevant information at the transport level which is the lowest level that goes end to end. There are defined metrics on the IP layer but to get better analysis we need the end to end metrics at hte transport level.