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

[Benjamin Kaduk <[e-mail]>]

On 11/23/2017 12:13 AM, Roni Even wrote:
> <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 
>

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