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

From: "Fardid, Reza" <[email-masked]>
Date: Tue, 2 May 2006 12:28:00 -0700

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:[email-masked]] 
Sent: Tuesday, May 02, 2006 9:17 AM
To: Schmoll, Carsten
Cc: [email-masked]
Subject: Re: [ippm] draft-shalunov-ippm-reporting-00.txt - availability

"Schmoll, Carsten" <[email-masked]> 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
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm

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

---

From: stanislav shalunov <[email-masked]>
Date: 02 May 2006 16:00:01 -0400

> availability metric, with X being service-specific, per Y.1541.

That's good to know, but we probably shouldn't replicate it as
suitability of networks with given measurements for given purposes is
outside of scope of IPPM (in my understanding, anyway).

The existing IPPM connectivity metric has no specific percentages
(well, other than 0 or 100%).

This message is designed to be viewed with 0.06479891g of NaCl.