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

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 3 May 2006 09:36:33 +0200

Henk,

|>But they also define much more:
|>
|>+  the length of the time window of evaluation
|>+  whether the window is sliding or fixed
|
|Isn't this setting "good or bad"?

Yes, it says connectivity there/not there.

[snip]

|>+  how many packets must be sent in each window for valid decision
|
|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?

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. 

One solution may be to describe how it is done and leave details to 
those applying the connectivity metric.

[snip]

|>One of the reasons to define two-states like this is to distinguish
|>time intervals with failures from "normal" performance when preparing
|>long-term summaries.
|
|I agree with all of this, but I still don't see why availability
|has to be in this draft.  If we send X packets/unit of time and
|report loss, then the user can do the math for his version of
|availability himself using the algorithm he likes.

Please get more precise. If your statement covers the following 
example, I'm with you. My point would be that a report may cover 
a long interval and not every user may be interested in collecting 
raw data to do his own "connectivity" evaluation:

Reporting Intervall:     15 min (900 sec)
Measurement Intervall:   1 sec between probe packets
Availability definition: 10 consecutive packets lost make any such 
                         ten second interval unavailable
Other parameters reported: loss rate, delay etc.

As an example, 20 packets may have been lost during one reporting 
interval, out of these 20 some 18 packets were lost in sequence. 

Service available:     882 sec
Service not available:  18 sec

Packet loss rate:		2/882 

It is not possible to deduce this information from a 15 Minute 
report which only tells you:

Packet loss rate:	     20/900.

The draft should allow for a reporting of "connectivity".	   

Regards, 

Rudiger   

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

---

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 03 May 2006 15:37:02 +0200

Ruediger,

>of any availability definition.

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.  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.

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?   I remember doing
this problem with broken lightbulbs, I don't remember how.

>Service not available:  18 sec

I'd report loss% in a 10 second intervals, and define not-available as
loss% >= 90% in such an interval.  In this specific case, I'd report:

   2 intervals with loss >= 90%
   Loss rate in the remaining 880 seconds: 2/880.

And if you want to use your definition, that is still possible: set the
measurement interval to 1 second, count the number of intervals with
100% packet loss in a row.

The problem I see with your definition though is that a sequence like
9 packets lost, 1 arrives, 9 more lost, 1 arrives, 9 more lost, etc,
results in "service available 900 seconds".

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...