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

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 2 May 2006 14:39:24 +0200

Stas,

Real time and leased line services are characterised by an "availability". I think availability is a useful and common means to characterise these services. Today, there's only a meausurement principle for IP service availability. There's no commonly implemented IP service availability measurement (RFC2678 on connectivity proposes some metrics which may be useful).

The idea is that you define a service availability over time. If the service is available, the metrics you've listed below are applied to characterise the service. If the service is not available, then no further performance characterisation is required.

As more real time services start to be migrated to the Internet, measuring IP transport availability may be of interest. 

Regards, 

Rudiger

Carsten|> * additionally "availability" could be one metric
|>   (probably with param = (list of) server(s) or network)

Stas|Why aren't existing metrics enough?  When no packets 
|come through, you'll see
|
|delay = +infinity
|loss = 100%
|jitter = undefined
|duplication = 0%
|reordering = 0%
|
|Is that not enough?

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

---

From: Al Morton <[email-masked]>
Date: Tue, 02 May 2006 09:24:16 -0400

Thanks, Ruediger. Another way to look at this topic:

Users experience network performance in at least two states:
available or "broken" (unavailable) where typically some
sort of failure or misconfiguration cannot be restored automatically
and requires human intervention.

The tricky part is defining the performance levels that
constitute the transitions between the two states,
and keep them application-independent for simplicity.
Despite the difficulties, Availability is probably one of
the most important network metrics, as far as real users
are concerned.

Al

At 08:39 AM 5/2/2006, Geib, Ruediger wrote:
>Stas,
>
>Real time and leased line services are characterised by an "availability". 
>I think availability is a useful and common means to characterise these 
>services. Today, there's only a meausurement principle for IP service 
>availability. There's no commonly implemented IP service availability 
>measurement (RFC2678 on connectivity proposes some metrics which may be 
>useful).
>
>The idea is that you define a service availability over time. If the 
>service is available, the metrics you've listed below are applied to 
>characterise the service. If the service is not available, then no further 
>performance characterisation is required.
>
>As more real time services start to be migrated to the Internet, measuring 
>IP transport availability may be of interest.
>
>Regards,
>
>Rudiger
>
>

---

From: stanislav shalunov <[email-masked]>
Date: 02 May 2006 10:26:47 -0400

"Geib, Ruediger" <[email-masked]> writes:

> Real time and leased line services are characterised by an
> "availability". I think availability is a useful and common means to
> characterise these services. Today, there's only a meausurement
> principle for IP service availability. There's no commonly
> implemented IP service availability measurement (RFC2678 on
> connectivity proposes some metrics which may be useful).

I believe that, should we want to report availability, we could
replace the normal report with ``network unavailable'' or some such
phrase if no packets get through.  This is consistent with RFC2678
(the second metric, Type-P-Interval-Unidirectional-Connectivity and
Type-P-Interval-Bidirectional-Connectivity).

Would that work for you?  (I'm still not convinced we should put it
in, but if we do, that would probably be my preferred way of treating
it.  What does everyone else think?  Is a separate availability metric
needed when delay, loss, etc., are already there?)

Also, should we call it ``connectivity'' to be consistent with
RFC2678?  Or is there a reason to say ``availability''?

> the most important network metrics, as far as real users

I'd prefer to just report the numbers as much as possible.  I guess
it's a bit like any other kind of dashboard design.  Suppose you're
designing a dial that shows speed of a vehicle.  Should the
speedometer display (or point to) zero when the vehicle isn't moving?
Or should it change to something else entirely?  As a user, I actually
prefer the zero for consistency.  Popping up a sign ``stopped'' over
the speedometer isn't helpful to me.  Opinions can legitimately differ
on that one, though.  But if it popped up the sign at 5 MPH, I would
be very irritated: it precludes some usage scenarios just because the
designer thought them unlikely...

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

Just my 0.086g of Ag.