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

["Fardid, Reza" <[e-mail]>]

Carsten, Stanislav,

ITU-T Y.1540 has defined "loss ratio > X%" as its IP service
availability metric, with X being service-specific, per Y.1541.

I think deriving connecitivity from one or more IPPM metrics will leave
gaps that you identified.  However, service availability lends itself to
a less ambiguous defintion based on one metric, if we cross-reference
the above.

Regards,
Reza 

-----Original Message-----
From: stanislav shalunov [mailto:[e-mail]] 
Sent: Tuesday, May 02, 2006 9:17 AM
To: Schmoll, Carsten
Cc: [e-mail]
Subject: Re: [ippm] draft-shalunov-ippm-reporting-00.txt - availability

"Schmoll, Carsten" <[e-mail]> writes:

> Technically there is not much of a difference between
> "delay to X < inf"  and  "connectivity with X exists"

With current definitions,

delay < +infinity is equivalent to loss < 50%

The only connectivity metric I see as compatible with the connectivity
RFC is loss < 100%.  How could we square loss < 50% with RFC2678?

> I would suggest to talk about *connectivity*, since *availability*
> to my ears sounds much like 'service availability' which is an
> application-level metric, and on this level there is no clear
> relation like the above.

``Connectivity'' is consistent with RFC2678, so, if there are no
arguments against it, it should probably be the default.

> Still I think connectivity deserves an extra report entry,
> since it might be "FALSE" for different reasons which cannot
> be derived from delay etc. For a user the reasons are of interest.

I don't understand.  If, as you seem to be proposing, we make ``no
connectivity'' == ``delay < +infinity'', it's derived from delay.  If
we make it ``loss < 100%'', it's derived from loss.  When would
connectivity *not* be derived from the five metrics already in there?

> Think about connectivity *to the Internet* as a desired metric;

Any measurement is tied to specific endpoints.  I don't expect
connectivity to the Internet can be meaningfully defined in a way that
will endure.

> this can be FALSE due to a lot of things, e.g.
> the 1st L2 link being down, DHCP, DNS, routing, firewall, or
> gateway failure.
> 
> Could the metric "connectivity to the Internet" be something more
> than binary and could it give a user a value stating either
> "OK", or some value indicating ''how far'' connectivity is from being
> OK?

Such a metric would essentially require an entire troubleshooting
algorithm.  This is way beyond the very limited summarization of
measurement results I'm trying to do with this draft...

> If connectivity is just a binary metric then I think it could be
> derived from the other reported metrics (if we just talk about
> Layer3 connectivity) as long as the destination parameter is the
> same.

Is there any need to report it separately, then?  The argument against
doing so is: Presence of derivative metrics enlarges the set of
metrics needlessly and violates metric orthogonality.

> What do you think about a finer granularity for connectivity?

I think if it's defined, it should be a separate effort.  (It would
probably also be a larger effort than anything IPPM has done so
far...)

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

Al your Qaeda are belong to US.

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

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