Re: [PSAMP] PSAMP-INFO IE realtiveError

["Zseby, Tanja" <[e-mail]>]

Hi Paul,

> -----Original Message-----
> From: Paul Aitken [mailto:[e-mail]]
> Sent: Friday, August 08, 2008 4:05 PM
> To: Zseby, Tanja
> Cc: Benoit Claise; psamp; Juergen Quittek
> Subject: Re: PSAMP-INFO IE realtiveError
> 
> Tanja,
> 
> >>> absoluteError
> >>>
> >>> This Information Element specifies the maximum possible
measurement
> >>> error of the reported value for a given Information Element. The
> >>
> >> We should indicate how to connect the *Error values to specific
> >> fields, eg by using an option with the specific field as scope.
> Else,
> >> someone may put the *Error elements adjacent to the relative fields
> >> in the data record - which could work, but is open to
> misinterpretation.
> >
> > Maybe I don't understand the comment correctly. Isnt the usage
> > explained in the example in PSAMP-PROTO? The error can also be
> applied
> > to relative values.
> 
> Either in the description for these fields, or at least in the title
> for the section, we should indicate that they should be used for the
> "Accuracy Report Interpretation" in PSAMP-PROTO.

o.k. maybe just put the sentence "The fields absoluteError, fixedError,
upperCILimit, lowerCILimit and confidenceLevel are used in the Accuracy
Report Interpretation as described in PSAMP-PROTO."

> 
> 
> >>> absoluteError has the same unit as the information element it is
> >>> associated to. The real value of the metric can differ by
> >>> absoluteError
> >> "with" ------^^
> >
> > ? Where to put the with?
> 
> Before the wrapping, the ^^ originally pointed to "to" - ie "to" ->
> "with".
>
Ah now I see :-) o.k.
 
> 
> >> We should specify that upperCILimit, lowerCILimit and
> confidenceLevel
> >> are all required, and what to do if too few of them are provided.
> >>
> >
> > Maybe just a sentence: "All three values (upperCILimit, lowerCILimit
> > and
> > confidenceLevel) are necessary to provide an complete accuracy
> > statement."
> >
> > I think the checking for the complete accuracy statement as out of
> > scope for IPFIX/PSAMP. I think this is something that the
> applications
> > that requires the statement should check. So I would consider no
> > mandatory action by collector.
> 
> If the *Error elements are provided in an option (eg, the Accuracy
> Report Interpretation) then the collector can obviously ignore them.
> 
> But that's not the only way to use them. What if they appeared right
in
> a data record - and there weren't enough of them? Should the collector
> ignore the entire data record?

No I think the collector does not need to take care of this since there
is nothing wrong with the reporting itself just that the reported values
may be useless due to an incomplete accuracy statement. But I think this
is something the application should check.

> >>> NEW:
> >>>
> >>> ... The accuracy for a measured information elelment SHOULD be
> >>> reported either with the fixedError Information Element
[PSAMP-INFO
> >>>
<http://tools.ietf.org/html/draft-ietf-psamp-protocol-09#ref-PSAMP-
> I
> >>> NFO>], or with the relativeError Information Element [PSAMP-INFO
> >>>
<http://tools.ietf.org/html/draft-ietf-psamp-protocol-09#ref-PSAMP-
> INFO>].
> >>> The accuracy for an estimated information element (from sampling)
> >>> SHOULD be reported with confidence limits and confidence
> >>> level.[PSAMP-INFO]
> >>
> > > Agreed. I'd also like to add something indicating how this can be
> > > done,
> >> eg by using an option with the correct scope.
> >
> > o.k. Maybe you can add a sentence for this?
> 
> It should be per the "Accuracy Report Interpretation" in PSAMP-PROTO -
> which should be updated to include these new IEs.
> 
> 
> >> The intention was to say that the clock is 5 minutes slow, +/- 10
> >> seconds - so there's both an absolute error and a relative error.
> >>
> >
> > NOW I finally understand what you meant by fixedError initially !!
> > This I would not consider as error. Any fixed deviation I would
> rather
> > name "offset"...
> > If it is known couldn't you add it to the value and report the
> correct
> > time?
> 
> In that case there would be no need to ever report "absoluteError" -
> because all the original measurements can be corrected before being
> exported.

Maybe for clarification:
The absoluteError that I propose is different from what you intended by
fixedError. absoluteError is a maximum error that you would expect due
to the inaccurate measurement (e.g. the timestamp may vary by +/- 5 ms).
The real error that you make during measurements is unknown and can
vary. Your fixedError is different. It is a fixed and known offset for
the measured values, correct?

Kind regards
Tanja

> 
> However, it may be we want to export the actual observed value, rather
> than a corrected value.
> 
> 
> > Or maybe check whether the NTP and TICTOC have a term for this...
> 
> We need a generic solution that works for all different kinds of IEs,
> not just for time.
> 
> 
> Thanks.
> --
> Paul Aitken
> Cisco Systems Ltd, Edinburgh, Scotland.
_______________________________________________
PSAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/psamp