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

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 4 May 2006 10:25:50 +0200

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

As I mentioned earlier, agreeing these thresholds is the hard part of
an availability measurement. I agree that IPPM better doesn't get 
involved. This may be done once operational experience allows for 
a consent within the WG. 

What I'd propose is to enable reports of the following kind:

During a report Interval of X

Service was Unavailable: U    (U <= X)

Service was available:   X-U
During X-U the following metrics were determined:
Packet loss rate, delay metric.....

The mechanism how to determine connectivity/availability should 
be specified in principle, but not in detail:  service is 
unavailable if n out of m consecutive probing packets are 
lost (n <= m). The total number of probing packets p sent 
during X should meet p >= m.

Hope that makes sense. Regards,

Rudiger

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

---

From: stanislav shalunov <[email-masked]>
Date: 04 May 2006 11:29:59 -0400

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

> be specified in principle, but not in detail:

Ruediger,

The rest of the draft can be implemented, with defaults.  It has
defaults for everything.  Defaults are rather the point.  Unless
defaults are overridden, the results can be compared directly.  I do
believe that everything should have defaults, in this draft.

> service is unavailable if n out of m consecutive probing packets are
> lost (n <= m). The total number of probing packets p sent during X
> should meet p >= m.

...but I don't believe that we could come up with values of n, m, and
p that would be acceptable to everyone.  (There are also statistical
arguments against doing such ad hoc selection, but even default
parameter choice, I think, is enough to make it a no-go.)

If there's interest in long-term aggregation and reporting (presumably
with SLAs in mind first), I think it should be a separate document,
perhaps building on this draft: it might subdivide the long-term
interval into 10-second chunks, do stats of this draft on the chunks,
and then do something to be discussed with these stats.

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

Sex is the mathematics urge sublimated.                 -- M. C. Reed.

---

From: Al Morton <[email-masked]>
Date: Thu, 04 May 2006 15:10:44 -0400

Stas,

I think the most important clarification you can make at this point
is to add a Scope section to the draft.  The only clues I
can find that these metrics are intended for real-time display
to a single user are the "now-corrected-in-03" measurement interval
of 10 seconds, and this:

At 12:17 PM 5/3/2006, stanislav shalunov wrote:
>The set can be derived from a run of a ping-like tool.  In that case,
>it's just one set.  If an application such as a game or a VoIP phone
>produces it, it just shows the statistics for the last 10 seconds (as
>numbers, dial positions, whatever), continually updating them.

If this scope had been clear, I'm sure I would have spent less time
discussing availability.  If I see packet loss = 100% every 10 seconds,
I don't need anymore convincing than that.  There's a point-point
aspect to the scope here. Also, there seems to be no storage
of the singletons. The tighter the scope in this case,
the better.

>and then do something to be discussed with these stats.

To simplify achieving agreement in this real-time performance
display context, I'd like to argue that this set of metrics should have
no explicit or implied status when it comes to reporting
performance in longer time frames. That's partly because IPPM already
took-up that work item under the Composition and Aggregation
Framework (Steven's draft will address Temporal Aggregation).

Al

---

From: stanislav shalunov <[email-masked]>
Date: 04 May 2006 16:18:09 -0400

Al Morton <[email-masked]> writes:

> is to add a Scope section to the draft.

You're quite right: the scope of the current document is not clear.  I
see the source of confusion now.  I'll work something out and include
it in the next version.

.signature: I/O Error