Re: [PSAMP] PSAMP-INFO IE realtiveError

"Zseby, Tanja" <Tanja.Zseby@fokus.fraunhofer.de> Fri, 08 August 2008 23:20 UTC

Return-Path: <psamp-bounces@ietf.org>
X-Original-To: psamp-archive@lists.ietf.org
Delivered-To: ietfarch-psamp-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B457A3A6C59; Fri, 8 Aug 2008 16:20:02 -0700 (PDT)
X-Original-To: psamp@core3.amsl.com
Delivered-To: psamp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4DE13A6C59 for <psamp@core3.amsl.com>; Fri, 8 Aug 2008 16:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.939
X-Spam-Level:
X-Spam-Status: No, score=-5.939 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmPWwGW8T76l for <psamp@core3.amsl.com>; Fri, 8 Aug 2008 16:19:59 -0700 (PDT)
Received: from mailgw1.fraunhofer.de (mailgw1.fraunhofer.de [153.96.1.17]) by core3.amsl.com (Postfix) with ESMTP id 853103A6930 for <psamp@ietf.org>; Fri, 8 Aug 2008 16:19:58 -0700 (PDT)
Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de[host mailgw13] (8.14.2+/8.14.2) with ESMTP id m78NJAP3018274; Sat, 9 Aug 2008 01:19:10 +0200 (CEST)
Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m78NJ9nc018269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Aug 2008 01:19:10 +0200 (CEST)
Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m78NJ7Wq004572; Sat, 9 Aug 2008 01:19:08 +0200 (MEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sat, 09 Aug 2008 01:19:05 +0200
Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A821@EXCHSRV.fokus.fraunhofer.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PSAMP] PSAMP-INFO IE realtiveError
Thread-Index: Acj5h1lwe4lW3iMJRLyYIJWdRAJX/QAJG5nQ
References: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A5F9@EXCHSRV.fokus.fraunhofer.de><489AB8F2.2050800@cisco.com><804B13F8F3D94A4AB18B9B01ACB68FA101F5A810@EXCHSRV.fokus.fraunhofer.de><489C52A7.6050907@cisco.com><804B13F8F3D94A4AB18B9B01ACB68FA101F5A819@EXCHSRV.fokus.fraunhofer.de><1218208442.9068.45.camel@localhost><804B13F8F3D94A4AB18B9B01ACB68FA101F5A81C@EXCHSRV.fokus.fraunhofer.de> <1218221293.9068.61.camel@localhost>
From: "Zseby, Tanja" <Tanja.Zseby@fokus.fraunhofer.de>
To: Andrew Johnson <andrjohn@cisco.com>
X-Fraunhofer-Email-Policy: accepted
Cc: psamp <psamp@ietf.org>, Juergen Quittek <Quittek@nw.neclab.eu>
Subject: Re: [PSAMP] PSAMP-INFO IE realtiveError
X-BeenThere: psamp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" <psamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/psamp>, <mailto:psamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/psamp>
List-Post: <mailto:psamp@ietf.org>
List-Help: <mailto:psamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/psamp>, <mailto:psamp-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: psamp-bounces@ietf.org
Errors-To: psamp-bounces@ietf.org

Hi Andrew,

> -----Original Message-----
> From: psamp-bounces@ietf.org [mailto:psamp-bounces@ietf.org] On Behalf
> Of Andrew Johnson
> Sent: Friday, August 08, 2008 8:48 PM
> To: Zseby, Tanja
> Cc: psamp; Juergen Quittek
> Subject: Re: [PSAMP] PSAMP-INFO IE realtiveError
> 
> 
> On Fri, 2008-08-08 at 18:07 +0200, Zseby, Tanja wrote:
> > Hi Andrew,
> >
> > lets first forget about the fixed error and say we agree that we
need
> > something like an absolute error that defines the maximum error that
> > can happen at each measurement (given the real error is unknown).
> > Then it was unclear for me why you report this together with a
> > relative error which provides exactly the same information but only
> as
> > percentage of the measured value. It is only for convenience that we
> > can report either format.
> >
> > relError=abserror/measured value
> >
> >
> > e.g. you can e.g. say: The absolute error is +/- 0.2 kg:
> > Person:   80.50kg +/- 0.2kg
> > Mouse:     0.50 kg +/- 0.2kg
> >
> > That corresponds to the relative errors:
> > Person:   0.249 %
> > Mouse:   40%
> 
> In the Accuracy Report Interpretation you only provide one accuracy
for
> the field, you don't report the accuracy per measurement.  The idea is
> to provide the margin of error for all measurements of a certain type.
> 
> The only use of the error field types that was originally intended was
> in the Accuracy Report Interpretation, where the error is scoped to
the
> field (and optionally template).  Unless you use a new template per
> record I'm not sure how you would scope the error value to an
> individual measurement.

But this is absolutely in-line with the above. You can provide one
absolute error for all timestamps or all byte measurements (or all
weight measurements). With this you say what is the maximum error when
measuring the timestamp or bytes. This maximum error usually depends on
the measurement method and therefore the absolute error (= the maximum
possible error) is usually the same for all of the values measured with
this method. I think this is exactly the same that you want to express,
correct? 

> 
> 
> > Or you could say: The relative error is +/- 10 %. Then you get the
> > corresponding absolute errors:
> > Person:   80.50kg +/- 8.05 kg
> > Mouse:     0.50 kg +/ 0.05 kg
> >
> > If this is o.k., the second question would be:  do we need something
> > like an offset/fixed error ?
> > e.g. Offset: 0.25
> > Person (real value):   80.50kg
> > Person (measured):     80.75kg
> >
> > Mouse (real value):   0.50 kg
> > Mouse (measured):     0.75 kg
> >
> > The only thing that might be confusing is if you have an offset and
> > report it together with a relative error, since the  relative error
> > should still refer to the real value (without offset). But we
> probably
> > do not need the offset value.
> 
> I don't think we have any need for an offset.

o.k. I agree.

> 
> > Hope this was not even more confusing...
> 
> I think I understand how you may have misunderstood how the error IEs
> were intended to be used.  I hope I'm making things clearer... perhaps
> the draft needs some clarification.

I think we have the same understanding (see above). The absoluteError
gives the maximum value from which a measured value can differ from the
real value. The error is usually bound to the measurement method or
system (i.e. the same for subsequent values).

Kind regards,
Tanja

> 
> Cheers
> 
> Andrew
> 
> 
> > Kind regards
> > Tanja (starting to see white mice)
> >
> >
> > > -----Original Message-----
> > > From: Andrew Johnson [mailto:andrjohn@cisco.com]
> > > Sent: Friday, August 08, 2008 5:14 PM
> > > To: Zseby, Tanja
> > > Cc: Paul Aitken; psamp; Juergen Quittek
> > > Subject: Re: [PSAMP] PSAMP-INFO IE realtiveError
> > >
> > > [SNIP]
> > > > > >> 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?
> > >
> > > I think the absoluteError is the same as the originally
fixedError.
> > In
> > > Paul's example above the fixedError was +/- 10 seconds.  I'm not
> > > sure how you would communicate the "5 minutes slow" part...
> > >
> > > The original idea was fixedError would say this is accurate to
> > > within
> > X
> > > units.  Both the fixed and the absolute error can be used
together,
> > but
> > > you just have to go with the least accurate one.  For example, if
> my
> > > bathroom scales have a fixed error of 0.25kg and a relative error
> of
> > > 0.5%, then they can weigh a person very accurate, but are rubbish
> > > for weighing mice:
> > >   Person1:   81.50kg +/- 0.4kg
> > >   Mouse1:     0.25kg +/ 0.25kg
> > >
> > > Cheers
> > >
> > > Andrew
> >
_______________________________________________
PSAMP mailing list
PSAMP@ietf.org
https://www.ietf.org/mailman/listinfo/psamp