perfsonar development work

[Joe Metzger <>]

Jason,
Since we are branching out beyond just simple octet rates, we should  
make sure the protocol
clearly specifies if a given data set is giving counters or rates.

--Joe

On May 5, 2008, at 6:08 AM, Jason Zurawski wrote:

> Nicolas & Fausto;
>
> > > My suggestion for the eventTypes for perfSONAR would be:
> > >
> > > http://ggf.org/ns/nmwg/characteristic/packets/nonunicast/2.0/
> > > http://ggf.org/ns/nmwg/characteristic/packets/unicast/2.0/
> >
> > If nobody comments the eventTypes names (in particular the "To-ed"  
> > from this email), we'll go for them.
>
> I think we need to be careful with the name assignment.  Even  
> though we are proposing packet counters, we may wish to  record the  
> same behaviors that we currently do with octet counters (e.g.  
> utilization, errors discards).  Because these two data types are  
> similar, it would be desirable to mimic the same overall structure  
> of the octet counters.
>
> I would propose something that keeps the hierarchy intact:
>
> characteristic
>    /utilization
>        /octets
>        /packets
>            /unicast
>            /nonunicast
>    /errors
>        /octets
>        /packets
>            /unicast
>            /nonunicast
>    /discards
>        /octets
>        /packets
>            /unicast
>            /nonunicast
>
> It also makes sense (probably more so) from this point of view but  
> we will sacrifice backwards compatibility:
>
> characteristic
>    /octets
>       /utilization
>       /errors
>       /discards
>    /packets
>        /unicast
>            /utilization
>            /errors
>            /discards
>        /nonunicast
>            /utilization
>            /errors
>            /discards
>
> Either way should allow extension better than segregating packets  
> into a separate branch of the characteristics hierarchy.
>
> -jason