Subject: Re: <draft-ietf-disman-remops-mib-03.txt> comments

From: [email-masked]
Date: Thu, 4 Feb 1999 06:28:14 -0500

Bob,

First, sorry its taken so long to respond.

>>|This format for results sort of gives me heartburn.  I'd have a nice,
neat
>>|enumeration for the completion status and a separate object for the
>>|response time, and perhaps additional objects for more detail.  The
Cisco
>>|Ping MIB, which has been in use for some time, has messages sent,
messages
>>|received, and minimum, average, and maximum round trip time.
>>|
>>|As long as we're doing this we might as well do it up right.
>>
>>I agree that it is useful to know the min and max.

First:

In a note I sent a few weeks ago I said that I agreed with a suggestion
that Karl
Auerbach made to split the results status information apart from the
response
time value. You should see this in the next revision of the MIB(s).
Scanning
pingResultsTable entries allows a management application to figure out all
of what you mentioned. Aggregate information could be kept by adding some
pingEntry objects if that is the consensus. I think this would be a good
idea
if we expect that management appls would more likely never retrieve
pingResultsTable entries but would be satisfied with the aggregate
information
kept in an pingEntry.

>I initially wondered why have sent and received, but the difference is an
>indication of lost messages, or perhaps duplicates.  Those could cancel or
>be ambiguous unless the ping process is numbering messages and keeping
>track of no responses and duplicate responses.  There's something to be
>said for specifying operation to that level of detail.

In general I have a problem with keeping aggregate information that can be
replicated
by scanning subbordinate entries. The current MIB provides remote cmd
capabilities and
is not a general purpose availability tool. To do a true availability tools
requires
much more that a few aggregate counters.

>>We're using this technique despite not taking the time to understand it
and
>>write it down as a common reference.
>>
>>If someone's willing to take the time to write that framework document,
>>I won't stand in their way!

>I didn't figure you would.  If we only had time to find someone with
time...

>>So we'll need at least one more draft before we kick off a last call
>>on this.

>Seems to be a lot of that going around.  :-)}

I will be responding to the other comments in their respective notes.

Ken

---

From: Bob Stewart <[email-masked]>
Date: Mon, 08 Feb 1999 15:02:05 -0500

>pingResultsTable entries but would be satisfied with the aggregate

I'm confused.  I wasn't suggesting adding anything to pingEntry.  Are the
entries in pingResultsTable one per message exchange?  I thought they were
one per overall ping request.  The MIB definition isn't clear.

It didn't occur to me that they'd be one per message exchange.  That seems
to me it would create far, far too many entries.

>much more that a few aggregate counters.

I seem to be missing something.  This implies that the pingResultsTable is
indeed one entry per message.  If I set up a ping of 1000 messages that's
going to waste a lot of MIB space.

	Bob

---

From: Karl Auerbach <[email-masked]>
Date: Mon, 8 Feb 1999 13:44:05 -0800 (PST)

> going to waste a lot of MIB space.

Waste is the wrong word -- reveal more useful information is a better
notion.

I've played a lot with ping over the years.  One learns a whole lot from
the pattern of responses -- whether failures are randomly distributed or
grouped, whether the round trip times tend to be focused around one value
or have a wide deviation, and is that deviation somehow cyclic.  Are some
of the packets answered by ICMP TTL expirations or other indications from
the path, and if so are they coming from the same places (i.e. are there
indications of route flapping)? Etc.

Ping is a wonderful tool.  But using it simply to validate a path and life
at the other end or to measure a raw packet loss rate is using only the
part of the useful data that ping can generate.

The same holds true for traceroute (and pathchar) -- it is the details of
the responses in the whole that allow for more than the most basic of
troubleshooting.

Oh, I almost forgot -- it is not all that uncommon to get multiple
responses to pings (or from traceroute hops) when things are misconfigured
or one accidently stumbles onto an address which is a directed broadcast
or when there a multiple boxes on the target net with the same address, or
when routes flap and cause duplicate requests, or when switches go awry,
or, most recently, when VLANs get confused and have internal loops.

	--karl--

---

From: Bob Stewart <[email-masked]>
Date: Mon, 08 Feb 1999 17:01:42 -0500

>> going to waste a lot of MIB space.

It wasn't at all clear to me on my first reading of the object DESCRIPTIONs
that this is the way it worked.

I understand the argument for working this way, and I'm willing to agree it
has value, but that shouldn't be the only way it works.  On a more
resource-limited system, or if you're simply not interested in using the
memory and CPU to record, ignore, and delete the details, that should be an
option for how to run the ping.

	Bob

---

From: "Carl W. Kalbfleisch" <[email-masked]>
Date: Tue, 09 Feb 1999 10:15:03 -0600

> indications of route flapping)? Etc.

Perhaps the ping mib should provide attributes to summarize the data and
provide min, max, average ping results. Then the manager does not have
to pull back all the results to learn this in formation.

Carl

--
Carl W. Kalbfleisch
Manager NMS Development
Verio Inc., http://www.verio.net

---

From: Karl Auerbach <[email-masked]>
Date: Tue, 9 Feb 1999 20:39:40 +0000 ( )

> to pull back all the results to learn this in formation.

I think Bob Stewart also mentioned that yesterday.

In addition to simple average, a std deviation would be useful.

I'm not sure where the cutover line says "let a local agent compute this
from the full, raw data" as opposed to "put a summary variable in the
mib".

		--karl--

---

From: "Carl W. Kalbfleisch" <[email-masked]>
Date: Wed, 10 Feb 1999 05:59:11 -0600

> In addition to simple average, a std deviation would be useful.

agreed.

> from the full, raw data" as opposed to "put a summary variable in the

Since we are talking about "distributed management" I think it is
appropriate to talk about having the agent compute the values for us.
That is the whole idea...

Carl

---

From: Bob Stewart <[email-masked]>
Date: Wed, 10 Feb 1999 10:53:17 -0500

>from the full, raw data" as opposed to "put a summary variable in the

The cutover has to be where there's a reasonable balance of work.  You
might, for example, say the agent side shouldn't be doing fancy
computations when the application side can get the full data and do them,
but by removing the computational burden at the agent you're putting on it
a storage and Get* response burden.

There's a lot to be said for calculations the agent side can do in some
sort of reasonably inexpensive, incremental way when it's not keeping the
raw data.

And as is the case with more and more of what we're doing, especially in
the DisMan working group, we're not specifying sparse MIBs for
instrumenting protocols and transmission media.  We're designing management
applications that happen to offer a MIB as an interface and may want to be
run on a relatively limited machine or on a fairly capable one.  So we have
more to consider, and I believe we must have more flexibility in mind for a
range of application abilities, depending on available resources at the
managed system.

	Bob

---

From: Harmen van der Linde <[email-masked]>
Date: Wed, 10 Feb 1999 12:17:09 -0500

Bob, 

> sort of reasonably inexpensive, incremental way when it's not keeping the

It would be very nice if most of the calculations are performed on the agent
side. In addition to Karl Auerbach's suggested standard deviation parameter
in the REMOPS Ping MIB I really would like to see objects included that 
provide even more detailed summary statistics like min RTT and max RTT.

The problem with all these summary statistics, however, is how they are 
calculated. For example, if I instruct the agent to send 5 ping requests and 
one of these requests times out. Is the average ping response time calculated 
including or excluding the timed out request (the latter should be the case)?

Another problem with implementing objects providing summary statistics is 
that it increases complexity and processing load. My preference is to keep 
things simple and try to limit the number of objects providing any kind of 
summary statistics in the Ping MIB. This way, the MIB is easily implementable, 
even in small-sized network devices. Generating summary statistics should be 
the responsibility of a (mid-level) management application.

The Ping MIB can be a very useful tool to retrieve basic performance counts
from the network and a proprietary version is currently already supported
as part of 
the Cisco IOS. This MIB is used by the Concord Network Health management
application, for example, to generate aggregated performance statistics.
Aggregated 
performance statistics from different devices in the network make only
sense when 
there is a common set of MIBs supported by these devices. Unfortunately,
there's wealth
of proprietary MIBs out there which make complex object semantics mappings on 
the manager side necessary to be able to generate these aggregated statistics. 
Adding summary statistics on the agent side will probably only add to this
complexity.

Bottom line: keep things simple so we can finalize this spec and get it
implemented.

Harmen

------------------------------------------------------------------------
Harmen van der Linde
Advanced Internetworking Services  Voice: (732) 758-4129
Bellcore, NVC 2X-119                 Fax: (732) 758-2269
331 Newman Springs Road            Email: [email-masked]          
Red Bank, NJ 07710                        [email-masked]
------------------------------------------------------------------------