Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 3 May 2006 16:07:30 +0200

Henk,

|>|>+  how many packets must be sent in each window for valid decision
|>|
H>|That is a valid question and probably something to include in the
|>|draft.  (If N out of M packets arrive, how confident can I be that
|>|the loss is below X%.)  Any statistician on the list who can
|>|provide text?
|>
R>This may be done service specific: if a user/application recognises a
|>service as being "not connected/available" if he misses connectivity
|>for a time of delta T, then this is the interval we look at. Then a
|>loss rate must be defined, which would result in the "impression".
|>A statistician may be of little help. This issue is the tricky part
|>of any availability definition.
|
H|That is not what I meant.
|
|We want to check if the service is available even if the user does not
|use it at a particular time.  

Agreed.

|So, we have to send probe packets.  These
|packets will probably sent at a lower rate than the real application,
|so the question is how many we have to send.

Exactly. But the measurement rate must be meaningful for the application 
and the duration of the events we want to detect.

Could it be that you'd like to know what's the minimum number of probes 
to detect an event of duration delta T? Without consulting a statistician, 
we could go for the law of minimum sampling rates in communication, 
i.e. half the duration of the event to be detected. 

|Example: I want that packets sent by my VoIP phone arrive 
|about 99.9% of the time, or roughly 3599 seconds every hour.  I measure 
|by sending probe packets at a rate of 1/minute.  In a particular hour, 1 
|packet gets lost, or 1/60.  Is that consistent with 99.9% or not?  

No, 98,3% within one hour. Your resolution can't be better than 1,7% here. 
Further, you'll probably hang up your receiver earlier than after 60 
seconds. May 10 seconds be a good value? Then we'd need to send a probe
all 5 seconds and declare service to be unavailable, if two consecutive 
packets are lost (taking the consecutive loss definition).

Leaves us with 0,17% granularity, or 99,8% per hour. 

If you want to proof 99,9% availability within one hour, still more 
probes are required. Well, 24 hour or 30 day analysis may be preferable.

[snip]

Your proposal to work with a loss rate instead of consecutive losses is 
allright to me. The fundamental mechanisms of an availability/connectivity 
measurement must be agreed.

The data amaount of a report may be reduced (that's why I proposed 15 
minutes). 10 second reports may not be desireable. One second reports 
certainly aren't.

To give an example: Our national backbone consists of 74 PoPs. Consider a 
full meshed measurement and a requirement to report to wholesale customers.
Second intervall reports are feasible in principle of course, but not 
really nice.

Regards,

Rudiger

_______________________________________________
ippm mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm

---

From: stanislav shalunov <[email-masked]>
Date: 03 May 2006 12:28:35 -0400

> measurement must be agreed.

Guys, let's just print the value and be done with it.  I don't expect
this group will ever come to the point of agreeing on some loss
threshold that defines ``OK service''.  Neither should it.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

All revolutions are bloody.  The October Revolution was bloodless,
but it was only the beginning.               -- Dmitri Volkogonov

---

From: Henk Uijterwaal <[email-masked]>
Date: Fri, 05 May 2006 16:04:33 +0200

Hi,

>No, 98,3% within one hour. Your resolution can't be better than 1,7% here.

I understand that but that wasn't the question.  I asked if 98.3% is
consistent with the claim of 99.9%.  It is a similar problem to: if I
flip a coin a lot of times, I get heads half the time, tails the other
half.  I now flip the coin only 10 times and get 6 heads and 4tails.
Is the coin biased or is this due to the limited size of my sample.

In general, I don't want to fill my network with probe packets, so the
frequency of probe packets may be a lot lower and I still want to say
something about the network.

>minutes). 10 second reports may not be desireable. One second reports

I would not report the data for each 10 second interval to the user,
just count the number of such intervals in a longer period and report
that.

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

1160438400. Watch this space...