Subject: [MIB-DOCTORS] how not to build a performance monitoring agent

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 9 Sep 2007 16:36:10 +0200

Hi,

the April issue of the IEEE Communications Magazine contains an
article "How Not to Build a Performance Monitoring Agent) which gives
some advise about things to avoid in MIB designs. Its a short and
quick read and those who have access to IEEE explore or a paper copy
of the Communications Magazine might want to look it up. For the
others, I am quoting the main recommendations here:

  1) Where possible, agents should present data to the performance
     monitor as counters rather than gauges.
  
  2) Agents present raw data to performance monitors, and performance
     monitors gather, store, and process the data. Agent designers
     should respect this distinction. Put another way, the agent should
     let the performance monitor do its job, and avoid trying to
     anticipate it, offload it, or make its job "easier" by providing it
     with data that is already stored or partially processed
  
  3) Agents should avoid enumerated statuses in favor of cumulative
     status times or, at any rate, provide cumulative status times in
     addition to enumerated statuses.
  
  4) Agents should be so structured that they avoid the necessity of
     polling volatile entities (i.e., entities that are short-lived with
     respect to a reasonable poll perios).

While I think we usually pay attention to 1) and 4), we sometimes run
into issues with 2) and perhaps pretty frequently with 3).

The idea behind 3) is that reporting say the ifStatus is just
reporting a snapshot but in many cases, you are really interesting the
(percentage of) time an interface has spent in a certain state.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors

---

From: Andy Bierman <[email-masked]>
Date: Sun, 09 Sep 2007 08:31:30 -0700

> into issues with 2) and perhaps pretty frequently with 3).

I think (2) is correct, even though there is some variance
in what people considered cooked data.  For example, NETFLOW
export of flow records was preferred to RMON2-MIB collections
at my previous employer.  IMO, there were several factors,
including the cost of RMON probes vs. NETFLOW, in terms
of price and runtime resource hit.  Adding a new collection
type to the RMON probe is way harder and takes way longer
than adding a new collection type in the NETFLOW manager application.

Maybe there is some issues with MIB complexity related to (2),
and it is not just a raw vs. cooked data issue.

> (percentage of) time an interface has spent in a certain state.

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 9 Sep 2007 17:41:11 +0200

I believe that this article assumes a certain architecture and it would
be useful to see a diagram which the article may include, or hear a
definition of what they call an agent and what they call a performance
monitor. Otherwise it's hard to understand a statement like 'Agents
present raw data to performance monitors, and performance monitors
gather, store, and process the data'. 

I have encountered different architectures of such systems according to
the size of the networks and to what the performance monitoring is used
for. Is the MIB interface assumed to be the interface between the
'agent' and the 'performance monitor'? How are performance monitors
queried by a management application, or is the performance monitor
supposed to be the application? This does not always scale. 

Also, it counts what performance monitoring is used for. Does it need to
have some real time characteristics, like in adaptive routing or in QoS
monitoring for VoIP Quality management? There is a need for data
reduction in such cases, and I believe that implementing thresholds and
notifications rather than exposing raw data at the lower level of the
architecture (agents) works better. The strategy described in the
article enhanced with techniques like IPFIX seems to be targeting
applications that need long term statistics and status reporting. 

Dan

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Sunday, September 09, 2007 5:36 PM
> To: [email-masked]
> Subject: [MIB-DOCTORS] how not to build a performance monitoring agent
> 
> Hi,
> 
> the April issue of the IEEE Communications Magazine contains 
> an article "How Not to Build a Performance Monitoring Agent) 
> which gives some advise about things to avoid in MIB designs. 
> Its a short and quick read and those who have access to IEEE 
> explore or a paper copy of the Communications Magazine might 
> want to look it up. For the others, I am quoting the main 
> recommendations here:
> 
> While I think we usually pay attention to 1) and 4), we 
> sometimes run into issues with 2) and perhaps pretty 
> frequently with 3).
> 
> reporting a snapshot but in many cases, you are really 
> interesting the (percentage of) time an interface has spent 
> in a certain state.
> 
> /js
> 
> --