perfsonar development work

[David Schmitz <>]

Hi all,

the development of the snmp ifError/ifDiscards MA will start rather soon 
(next week) and there are still issues to discuss.
As probably not all people had time to follow the discussion in the
mailing list recently, I give a short summary about the schema being 
developed for this new type of MA:

In general, this type of MA will be similar to the utilization MA,
but it will support multiple metrics:
There are two new snmp metrics to support with this new type of MA
at the moment: ifErrors and ifDiscards (frame drops),
more metrics may be added later.

Jason has proposed 2 different possibilities for the new schema,
while I myself simultaneously proposed another one:

Jason's first solution is very similar to the existing schema for the 
utilization MA.
Here, in fact, for both new metrics (errors and discards) separate
schemas and namespaces (each similar to the utilization schema) are used.
The advantage of this possibility is that the adaptation from the existing
utilization MA to the new MA is very easy, and not much changes should
be required in the MA code.
As the developing of the new MA will start next week very soon, we should 
using
this solution in the beginning.

Jason's second solution is a unified solution covering any SNMP metric, 
i.e. utilization, errors, drops, and new ones to come in the future.
This single schema uses different event types for distinguishing
between the different metrics.
Above all, it supports a wildcard eventType covering all available metrics.
The advantage of this schema is that it allows to fetch the data for multiple 
metrics
of a single subject (e.g. an ip link) without specifying the subject twice in 
the request.
So it probably allows for a better performance.
Further, the integration of new SNMP metrics is possible.
This solution is of course more complex than the first one and MA Service 
developers 
will have to check the effort to adapt their services to this new schema.
The openness for the future of this unified approach should be
discussed, i.e. if it really is sufficient for all new metrics to come.
We should not have to change the existing schemas too often.
Specifically, we have to take care of the compability with the existing
utilization schema.

Additionally, I myself proposed a schema for error and drops which
lies more or less between Jason's proposals.
My idea was to have a single schema for the two new metrics.
As Jason already addressed this issue with his second approach 
(even integrating utilization) 
and he is more involved in NMWG schema development, it's probably better to
start with his proposal instead of my own.


Best Regards,
David

> Nicolas Simar wrote:
> > 
> > 
> > Jason Zurawski wrote:
> > > David;
> > >
> > > >
> > > > Jason, from your point of view, which of the schema proposals could be
> > > > easily made ready for immediate use next week?
> > > >
> > > >   
> > >
> > >
> > > In my opinion we should proceed with the method that best maps reality,
> > > not which is fastest to implement.  It would be great to hear comments 
> > > on
> > > both methods from various interested parties soon (and if its next week
> > > you are looking to implement, comments need to come *very* soon).
> > 
> > I guess that the interested parties are:
> > - the visualisation developers: Nina/Vedrin (psUI), David/Andreas (CNM),
> > Daniel(visualperfSONAR)
> > - the web-service developers: Roman (RRD), Jeff/Jason (SNMP MP)
> 
> I suspect it does not matter that much for the visualization developers. 
> They
> will need to start looking for additional schema/variables no matter what.
> And, I suspect something similar to the current structure should not be
> difficult for them. I believe Jason's proposal is much more similar to the
> current structure than David's. (I do understand the desire to retrieve
> multiple data types within a single data. Especially from a visualization
> point of view. However, I think this would be a complex thing to work into
> current services. The 'typed' datum is a completely new concept.)
> 
> For the service developers, I believe the main issue is how difficult it is 
> to
> extend the store to support multiple eventTypes. Multiples, no matter the
> namespace add some complexity.
> 
> However, I think we can postpone some of the complexity (at least from the
> perspective of the RRD MA) if we first support the errors/discards from the
> characteristic namespace. This will reduce the number of nmwg classes that
> Roman needs to create in support of this. (And, they end up being near
> duplicates to the existing 'utilization' class - so it should be trivial.)
> 
> The SNMP MP implementation does not have complexity in this space because it
> is using DOM for this - additional namespaces are just handled at the query
> level - there is no 'marshalling' to worry about. However, as I said - the
> multiple eventTypes are still an issue.
> 
> Perhaps we should start the discussion with evaluating this part (how do 
> deal
> with multiple eventTypes) of Jason's proposal. (I like it, but I was his
> sounding board for ideas...) It would be far better if others commented.
> 
> jeff
> 
> 
> > 
> > Nicolas
> > 
> > > > Do you foresee an easy way starting with only the basic
> > > > features necessary (for next week), while not much complicating the
> > > > later integration of more complex features (e.g. tool namespace snmp)?
> > > >   
> > >
> > >
> > > Any or all of the standard we choose can be implemented to start with, 
> > > as
> > > long as everything is fully implemented in the end.  in my opinion 
> > > keeping
> > > things 'similar' to the characteristic style (similar to utilization) is
> > > the fastest route to start with (both for getting comments on this list
> > > and for allowing service developers to get started).  No matter which
> > > method we choose it is imperative that extension be possible in the 
> > > future
> > > (i.e. to the SNMP namespace, etc.).
> > >
> > > -jason
> > >
> > 
> 

-- 

David Schmitz

Boltzmannstraße 1, 85748 Garching
Telefon:   +49 89 35831-8765
Fax:       +49 89 35831-9700
Leibniz-Rechenzentrum, Germany
Mail: