Re: [ippm] draft-shalunov-ippm-reporting-00.txt

"Schmoll, Carsten" <Carsten.Schmoll@fokus.fraunhofer.de> 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
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm

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