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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 13 Feb 2004 18:16:02 +0200

Shailadja,
 
I did not see yet your draft-00, so it is difficult for me to make too intelligent comments in the absence of the details. However, here are a few preliminary thoughts, triggered by your mail.
 
1. There may be some prior work - for example, in the RMON WG, during the work for the INTERFACETOPN-MIB (RFC 3144) we played with the idea of a userTopN function, that looks quite close to the idea of sorting instances of the columnar objects. The archives of the WG list may give you some ideas of what was discussed then, and old I-Ds may contain some MIB work discarded later - as we decided to focus the work on interface counters specific parameters
2. psamp does a lot of work in defining packet filtering for monitoring purposes
3. It is not clear what is the combination of threshold monitoring with history collection. How would this be different from the Alarms and Events mechanism in RFC 2819?
4. Why do you think this work would belong in disman? 

Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Shailaja Yadawad
Sent: 13 February, 2004 5:51 PM
To: [email-masked]
Cc: Hemanth Kumar; Raja Shekar; Hemanth Yamijala
Subject: [Disman] Statistical Sampling of Data- Discussion onrequirement and proposal on advanced features

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 features that we are working, a brief description of features is being posted in this WG.

Please do share your comments, inputs, additional features etc.

Thanks,

Shailaja.

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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 13 Feb 2004 18:16:02 +0200

Shailadja,

Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Shailaja Yadawad
Sent: 13 February, 2004 5:51 PM
To: [email-masked]
Cc: Hemanth Kumar; Raja Shekar; Hemanth Yamijala
Subject: [Disman] Statistical Sampling of Data- Discussion onrequirement and proposal on advanced features

Hi All,

Thanks,

Shailaja.

Discussion:

Features:

like notepad.exe.