Re: [PSAMP] PSAMP-INFO IE realtiveError

Juergen Quittek <quittek@nw.neclab.eu> Sat, 02 August 2008 08:58 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 7463F3A67F4; Sat, 2 Aug 2008 01:58:06 -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 51B003A67F4 for <psamp@core3.amsl.com>; Sat, 2 Aug 2008 01:58:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992]
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 H9rJic1mDlXn for <psamp@core3.amsl.com>; Sat, 2 Aug 2008 01:58:02 -0700 (PDT)
Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 76A803A6405 for <psamp@ietf.org>; Sat, 2 Aug 2008 01:58:01 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 3AF672C009E93; Sat, 2 Aug 2008 10:58:23 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office)
Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D66bPYzadXNt; Sat, 2 Aug 2008 10:58:23 +0200 (CEST)
Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 073962C0008C1; Sat, 2 Aug 2008 10:58:08 +0200 (CEST)
Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Sat, 2 Aug 2008 08:58:07 +0000
User-Agent: Microsoft-Entourage/12.10.0.080409
Date: Fri, 01 Aug 2008 16:53:05 +0200
From: Juergen Quittek <quittek@nw.neclab.eu>
To: Tanja Zseby <Tanja.Zseby@fokus.fraunhofer.de>, Benoit Claise <bclaise@cisco.com>
Message-ID: <C4B8EFF1.C389%quittek@nw.neclab.eu>
Thread-Topic: [PSAMP] PSAMP-INFO IE realtiveError
Thread-Index: AcjzX1+jbdnY7+Z8QSCcn2o21oD8ygAUIUTQAA2aOTM=
In-Reply-To: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A607@EXCHSRV.fokus.fraunhofer.de>
Mime-version: 1.0
Cc: IETF PSAMP Working Group <psamp@ietf.org>
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

Tanja,

If you can suggest a new paragraph for PSAMP-PROTO and if the
authors support it, I can ask Dan for his support and to forward
it as an RFC Editor comment. This would be a much cleaner procedure
than applying changes at AUTH48.  And if it got rejected, we
would just follow Benoit's proposal.

Thanks,

    Juergen


Am 01.08.08 10:28 schrieb "Tanja Zseby" unter
<Tanja.Zseby@fokus.fraunhofer.de>:

> Hi Benoit,
> 
> I think we need no new section in PSAMP-PROTO and can only introduce the
> CI limits in PSAMP-INFO. We can stick with the example in PSAMP-PROTO
> but need to clarify that the example is only for the accuracy of
> measured values. That means mainly to remove the 2 sentences that refer
> to estimation error. It depends how much we can still change in
> PSAMP-PROTO. Is removing 2 sentences o.k.?
> 
> Kind regards
> Tanja
> 
>> -----Original Message-----
>> From: psamp-bounces@ietf.org [mailto:psamp-bounces@ietf.org] On Behalf
>> Of Benoit Claise
>> Sent: Friday, August 01, 2008 12:46 AM
>> To: Zseby, Tanja
>> Cc: psamp; Juergen Quittek
>> Subject: Re: [PSAMP] PSAMP-INFO IE realtiveError
>> 
>> Hi Tanja,
>> 
>> 
>> Hi Benoit and Paul,
>> 
>> 
>> 
>> here my suggestions for clarification of the error IEs in PSAMP-
>> INFO.
>> 
>> -    I suggest to rename the fixedError to absoluteError
>> 
>> No problem with that, but [PSAMP-PROTO] must follow otherwise we have
> a
>> problem Can we still change that in AUTH48 maybe?
>> 
>> 
>> 
>> 
>> -    I suggest to introduce CI limits and level to also report
>> estimation errors
>> 
>> I'm wondering whether this is a good idea to add upperCILimit,
>> lowerCILimit, and confidenceLevel at this stage.
>> Because it implies that we need a complete new section in
> [PSAMP-PROTO]
>> (as opposed to just editorial change) similar to "Accuracy Report
>> Interpretation" but for the accuracy statement for estimated value.
>> Now, the simple solution is to add the information elements in PSAMP-
>> INFO and don't discuss the accuracy statement for estimated value in
>> [PSAMP-PROTO].
>> 
>> 
>> 
>> 
>> -    If it is still possible I would suggest to make a few small
>> changes in PSAMP-PROTO for consistency.
>> 
>> -    Upper and lower CI limits can be also specified as provided
>> absolute or relative limits. So we could also add 2 more IEs (for the
>> relative CI limits)
>> 
>> 
>> 
>> New description of IEs:
>> 
>> 
>> 
>> absoluteError
>> 
>> This Information Element specifies the maximum possible
>> measurement error of the reported value for a given Information
>> Element. The absoluteError has the same unit as the information
> element
>> it is associated to. The real value of the metric can differ by
>> absoluteError (positive or negative) from the measured value. This
>> information element provides only the error for measured values. If an
>> information element contains an estimated values (from sampling) the
>> confidence boundaries and confidence level have to be provided
> instead.
>> 
>> 
>> 
>> relativeError
>> 
>> This Information Element specifies the maximum possible
>> measurement error of the reported value for a given Information
> Element
>> as percentage of the measured value. The real value of the metric can
>> differ by relativeError percent (positive or negative) from the
>> measured value. This information element provides only the error for
>> measured values. If an information element contains an estimated
> values
>> (from sampling) the confidence boundaries and confidence level have to
>> be provided instead.
>> 
>> I like your suggestions for absoluteError and relativeError because
>> something that was not clear (neither from PSAMP-PROTO or PSAMP-INFO)
>> is that we wanted to quantify the accuracy of the measurement
>> estimation, as opposed to the accuracy of the estimated value
>> 
>> 
>> 
>> 
>> 
>> 
>> upperCILimit
>> 
>> This Information Element specifies the upper limit of a
>> confidence interval. It is used to provide an accuracy statement for
> an
>> estimated value. The confidence limits define the range in which the
>> real value is assumed to be with a certain probability p. Confidence
>> limits always need to be associated with a confidence level that
>> defines this probability p. Please note that a confidence interval
> only
>> provides a probability that the real values lies within the limits.
>> That means the real value can lie outside the confidence limits.
>> 
>> 
>> 
>> lowerCILimit
>> 
>> This Information Element specifies the lower limit of a
>> confidence interval. For further information see the description of
>> upperCILimit.
>> 
>> 
>> 
>> confidenceLevel
>> 
>> This Information Element specifies the confidence level. It is
>> used to provide an accuracy statement for estimated values. The
>> confidence level provides the probability p with which the real value
>> lies within a given range. A confidence level always needs to be
>> associated with confidence limits that define the range in which the
>> real value is assumed to be.
>> 
>> 
>> 
>> 
>> 
>> Changes to PSAMP-PROTO if still possible:
>> 
>> 
>> 
>> -    Rename fixedError to absoluteError
>> 
>> -    Slightly modify paragraph 2
>> 
>> OLD:
>> 
>> ...  The accuracy SHOULD be reported either with the fixedError
>> Information Element [PSAMP-INFO
> <http://tools.ietf.org/html/draft-ietf-
>> psamp-protocol-09#ref-PSAMP-INFO> ], or with the relativeError
>> Information Element [PSAMP-INFO
> <http://tools.ietf.org/html/draft-ietf-
>> psamp-protocol-09#ref-PSAMP-INFO> ].
>> 
>> 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-
>> INFO> ], or with the relativeError Information Element [PSAMP-INFO
>> <http://tools.ietf.org/html/draft-ietf-psamp-protocol-09#ref-PSAMP-
>> INFO> ]. T
>> 
>> To be consistent with my statement above, I would not add the
> following
>> sentence.
>> 
>> 
>> he accuracy for an estimated information element (from sampling)
>> SHOULD be reported with confidence limits and confidence level.[PSAMP-
>> INFO]
>> 
>> 
>> 
>> -    Remove the following paragraph (very important! Otherwise
> it
>> would lead to confusion):
>> 
>> For example, the accuracy of an Information Element to estimate
>> the accuracy of a sampled flow, for which the unit would be specified
>> in octets, can be specified with the relativeError Information Element
>> with the octet units.  In this case, the error interval is the
>> Information Element value +/- the value reported in the relativeError
>> times the reported Information Element value.
>> 
>> 
>> 
>> -    Avoid the term error interval
>> 
>> OLD:
>> 
>> In this case, the error interval is the Information Element
> value
>> +/- the value reported in the fixedError.
>> 
>> NEW:
>> 
>> In this case, the real values lies within the range of the
>> Information Element value +/- the value reported in the absoluteError.
>> 
>> 
>> 
>> 
>> 
>> -    Remove the following paragraph (since absolute or relative
>> error are just different representations I would not gain something if
>> I report both)
>> 
>> Alternatively to reporting either the fixedError Information
>> Element or the relativeError Information Element in the Accuracy
> Report
>> Interpretation, both Information Elements MAY be present.  This
>> scenario could help in more complex situations where the system clock
>> drifts, on the top of having its own accuracy, during the duration of
> a
>> measurement.
>> 
>> I would also change "Accuracy Report Interpretation" into "Measurement
>> Accuracy Report Interpretation" in  [PSAMP-PROTO]
>> 
>> Regards, Benoit.
>> 
>> 
>> 
>> 
>> 
>> 
>> Sorry for the late comments, I was quite busy with PSAMP-TECH
>> before...
>> 
>> 
>> 
>> Kind regards,
>> 
>> Tanja
>> 
>> 
>> 
>> 
>> 
> 

_______________________________________________
PSAMP mailing list
PSAMP@ietf.org
https://www.ietf.org/mailman/listinfo/psamp