Subject: [Disman] Statistical Sampling of Data- Discussion on requirement and proposal on advanced features

From: "Shailaja Yadawad" <[email-masked]>
Date: Fri, 13 Feb 2004 09:07:24 -0700

Hi All
 
At the moment a group of us are working on a draft-00-.
The work is about object definition for configuring and controlling the
periodic statistical sampling of user specified Data (ASN.1 INTEGER). As
you might be aware that usr history group of RMON2 (RFC2021) does
address this kind of requirement. Our proposed framework apart from
containing the mechanisms seen in the alarm and usr history groups of
RMON2 contains also the additional features and functionality. In order
to get the ideas and inputs from congenial minds on the proposed
features (to be), a brief description of proposed features (to be) is
given below.
 
Discussion:
 
Suppose if the user needs to collect history for all the instances of a
columnar object say e.g., on the interface related statistics (ifTable
of MIB-II) like packets sent for all the interfaces by using the
usrHistory group object definition, the user is required to carry out
configuration for each instance separately. The usr History group does
not provide a single point of configuration for all the instances of the
columnar objects.
   
It has to be noted that there are some special requirements that arise
because of the above such condition. Following features address some
such special requirements.
 
Features:
 
(a) Goal: Simple configuration and Instance Management:
 
Objective: It must be possible to configure and control the history
collection for all the instances of the columnar object in a simple
way.
 
  The OID of a columnar object variable consists of two parts: a
columnar OID and an index.
 
Usually, the index part of the OID is defined by implementers of the
MIB or is dependent on the specific type of the parameter that is being
monitored. Hence it can have arbitrary values. Also, these indices can
vary from machine to machine. For example, the index of the ifTable is a
column called ifIndex. The value of this ifIndex is not pre-determined
and can be any arbitrary integer value. It is difficult for a user to
determine the complete OID for such parameter. 
 
There is another problem that arises vis-a-vis the history collection
of columnar variables. The numbers of instances for these parameters are
not fixed. This means that there could be new instances that are added
or existing ones removed, as per the dynamic behavior of the system
being monitored. For example, new interfaces added to the system could
result in new rows in the ifTable. Interfaces removed would result in
the deletion of existing rows. It becomes difficult if an user needs to
keep track of these additions and deletions and make sure that the
history collection configuration reflects these changes.
 
 A simple resolution to these kind of requirement being providing the
capability to the user to define only the columnar part of the OID and
allow the implementing application to find all the instances of the
table automatically. At the same time, this would also allow the agent
to keep track of additions and deletions that occur as stated above.
 
(b) Consistent reference to the resource: It must be possible to track
changing instances and automatically adjust the history collection.
 
Normally, the index part of columnar variables maps to an instance of
the system resource being monitored. However, if the resource being
monitored changes, it could result in a change to the index part of the
columnar variables also. As it is again left to implementation what the
index part is, there is no guarantee that an index is mapped to the same
instance of the system resource always. 
 
For example, consider the hrSWRunTable table in the Host resources
MIB. The index of this table is again an integer valued variable called
hrSWRunIndex. The HTTP server process might initially be associated with
index 7219. However, if it is restarted, it could get the index 9029.
Also, it is likely that a row with index 7219 might actually represent a
new process 
like notepad.exe. 
 
If some columnar variable related to the above table need statistical
sampling, it cannot rely just on the OID of that variable. It may result
in the data not being collected for the instance even if it is actually
available. Or worse, it may collect incorrect data assuming that the OID
still represents the same instance. It is also very difficult for an
user to keep these synchronized.
 
Strictly speaking, this problem should not arise if the indices of 
tables are defined and implemented in such a way that their mapping to
the underlying resource is ensured to be always unique. However, it is
observed in practice that indices of tables are usually just integer
valued numbers. It is also observed that there would be other columns in
the table which identify the resources in a more permanent manner. For
example, in the 
case of the hrSWRunTable, the name of the software could serve as a
good identifier.
 
This problem is addressed by introducing a concept of 
'Identifier Object'. The Identifier Objects are one or more Columnar
Objects that will serve to uniquely identify one instance among several
ones of selected columnar objects. The MIB definition allows the user to
associate Identifier Objects to the columnar Object being sampled. By
doing so, it is now left to the monitoring application to make sure that
data is being collected for the right resource even if it changes with
time.
 
(c) Instance Filtering: It must be possible to selectively collect
history on certain instances of a columnar object.
 
Sometimes, the user may not be interested in all the instances of a
given table. In such a case, usr can specify the OIDs of the specific
instances of interest. However, as described in the above points,
specifying the complete OID will again have a problem if there is a
change to the index part of such instances. 
 
For example, consider again the hrSWRunTable in the Host resources MIB.
This would include all processes running on the system. However the user
might be interested in monitoring only certain important processes like
a HTTP server or other major services. 
 
The current draft allows the user to define filter criteria specifying
the instances to be monitored. The monitoring application can now ensure
that instances satisfying these criteria can be monitored. Combined with
the other points mentioned above, this would handle cases where
instances satisfying the criteria get added, removed or modified.
 
(d) Threshold Monitoring: Combining the aspect of threshold monitoring
with history collection:
 
In addition to the above considerations, the current object definition
also tries to combine the functionality of threshold-based monitoring
with the history collection functionality. It allows the user to define
thresholds on the data being monitored. Any violation of the threshold
would result in a trap being generated.

---

From: "" <[email-masked]>
Date: 13 Feb 2004 09:26:39 PST

Before you go too far with this work you should find out the status of the patent that Hewlett-Packard had (it may now be held by Agilent) for statistical sampling of network data.  The RMON WG decided some years ago not to support a statistical sampling MIB because HP would not release their patent rights at that time.

Reva Bailey
[email-masked]

------- Original Message -------
On
Fri, 13 Feb 2004 09:07:24 -0700 Shailaja Yadawad?wrote:

Hi All

Discussion:

 
Features: