From psamp-bounces@ietf.org Sat Aug 2 01:58:06 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-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 ; 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 ; 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 ; 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 To: Tanja Zseby , Benoit Claise Message-ID: 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 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 : > 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 > > psamp-protocol-09#ref-PSAMP-INFO> ], or with the relativeError >> Information Element [PSAMP-INFO > > 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 >> > INFO> ], or with the relativeError Information Element [PSAMP-INFO >> > 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 From psamp-bounces@ietf.org Sat Aug 2 08:32:50 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18AE3A687A; Sat, 2 Aug 2008 08:32:49 -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 DFE0A3A687A for ; Sat, 2 Aug 2008 08:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.757 X-Spam-Level: X-Spam-Status: No, score=-5.757 tagged_above=-999 required=5 tests=[AWL=0.492, 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 2mhpiPeJv96g for ; Sat, 2 Aug 2008 08:32:47 -0700 (PDT) Received: from mailgwb1.fraunhofer.de (mailgwb1.fraunhofer.de [153.96.87.18]) by core3.amsl.com (Postfix) with ESMTP id 1F6DC3A6830 for ; Sat, 2 Aug 2008 08:32:45 -0700 (PDT) Received: from mailgwb1.fraunhofer.de (localhost [127.0.0.1]) by mailgwb1.fraunhofer.de[host mailgwb1] (8.14.2+/8.14.2) with ESMTP id m72FR0sL004850; Sat, 2 Aug 2008 17:27:01 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgwb1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m72FQs7p004680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 2 Aug 2008 17:27:00 +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 m72FQrpq015907; Sat, 2 Aug 2008 17:26:53 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 2 Aug 2008 17:26:45 +0200 Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A651@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PSAMP] PSAMP-INFO IE realtiveError Thread-Index: AcjzX1+jbdnY7+Z8QSCcn2o21oD8ygAUIUTQAA2aOTMAMzENUA== References: From: "Zseby, Tanja" To: "Juergen Quittek" , "Benoit Claise" X-Fraunhofer-Email-Policy: accepted Cc: IETF PSAMP Working Group 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Hi J=FCrgen, here my suggested changes to PSAMP-PROTO section 6.5.4 (see my initial emai= l): - Rename fixedError to absoluteError - slightly modify paragraph 2 OLD: ... The accuracy SHOULD be reported either with the fixedError Information= Element [PSAMP-INFO ], or with the relativeError Information Element [PSAMP-= INFO ]. NEW: ... The accuracy for a measured information elelment SHOULD be reported eit= her with the fixedError Information Element [PSAMP-INFO ], or with the relati= veError Information Element [PSAMP-INFO ]. The accuracy for an estimated info= rmation element (from sampling) SHOULD be reported with confidence limits a= nd confidence level.[PSAMP-INFO] - Remove the following paragraph (this I consider as most important!) For example, the accuracy of an Information Element to estimate the accurac= y of a sampled flow, for which the unit would be specified in octets, can b= e specified with the relativeError Information Element with the octet units= . In this case, the error interval is the Information Element value +/- th= e value reported in the relativeError times the reported Information Elemen= t value. - Avoid the term error interval OLD: = In this case, the error interval is the Information Element value +/- the v= alue reported in the fixedError. NEW: = In this case, the real values lies within the range of the Information Elem= ent 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, b= oth 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. Kind regards, Tanja > -----Original Message----- > From: Juergen Quittek [mailto:quittek@nw.neclab.eu] > Sent: Friday, August 01, 2008 4:53 PM > To: Zseby, Tanja; Benoit Claise > Cc: IETF PSAMP Working Group > Subject: Re: [PSAMP] PSAMP-INFO IE realtiveError > = > 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 > : > = > > 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 > > >> psamp-protocol-09#ref-PSAMP-INFO> ], or with the relativeError > >> Information Element [PSAMP-INFO > > >> 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 > >> >> INFO> ], or with the relativeError Information Element [PSAMP-INFO > >> >> 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 From psamp-bounces@ietf.org Thu Aug 7 01:57:41 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C0B3A6B06; Thu, 7 Aug 2008 01:57:41 -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 250F13A6B06 for ; Thu, 7 Aug 2008 01:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.345 X-Spam-Level: X-Spam-Status: No, score=-6.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, 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 c4jOsmW7NSFQ for ; Thu, 7 Aug 2008 01:57:38 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3FAB93A6B00 for ; Thu, 7 Aug 2008 01:57:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,319,1215388800"; d="scan'208";a="16465926" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 07 Aug 2008 08:57:27 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m778vLju022653; Thu, 7 Aug 2008 10:57:21 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m778vLu7008314; Thu, 7 Aug 2008 08:57:21 GMT Received: from [10.61.80.226] (ams3-vpn-dhcp4323.cisco.com [10.61.80.226]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m778vJe03391; Thu, 7 Aug 2008 09:57:20 +0100 (BST) Message-ID: <489AB8F2.2050800@cisco.com> Date: Thu, 07 Aug 2008 09:57:22 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 MIME-Version: 1.0 To: "Zseby, Tanja" References: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A5F9@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A5F9@EXCHSRV.fokus.fraunhofer.de> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6477; t=1218099441; x=1218963441; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20PSAMP-INFO=20IE=20realtiveError |Sender:=20; bh=AubtHcO5uqtL/ezs+TJnzCIzoV6tvEa5LgaQbZFwDDI=; b=k4w7C2+wCpdkKk681oMItJ1M42EwlOUs8nIJ+ANlJI9fHN1mtip1etGktO jK+93JL+KgwLKjdQD7nCZFhz1oyzIvZZYBrHXmv5uqpoAKjJsbEpGRRg717x wCUeO0PiJh; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: psamp , Juergen Quittek 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org 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 Agreed. > - I suggest to introduce CI limits and level to also report > estimation errors > > - 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 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. > absoluteError has the same unit as the information element it is > associated to. The real value of the metric can differ by absoluteError "with" ------^^ > (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 would name the IEs: "the confidence boundaries and confidence level have to be provided instead (with the upperCILimit, lowerCILimit and confidenceLevel). > 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. Again, as above, I would specifically name the IEs for this. > 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. We should specify that upperCILimit, lowerCILimit and confidenceLevel are all required, and what to do if too few of them are provided. > 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 > ], > or with the relativeError Information Element [PSAMP-INFO > ]. > > NEW: > > ... The accuracy for a measured information elelment SHOULD be reported > either with the fixedError Information Element [PSAMP-INFO > ], > or with the relativeError Information Element [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. > > > > - 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. 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. > Sorry for the late comments, I was quite busy with PSAMP-TECH before... Thanks for your input! -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Fri Aug 8 06:39:30 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A5BA3A6ACC; Fri, 8 Aug 2008 06:39:30 -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 DA6C53A6ACC for ; Fri, 8 Aug 2008 06:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.39 X-Spam-Level: X-Spam-Status: No, score=-4.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 bBC2INdzxs5f for ; Fri, 8 Aug 2008 06:39:28 -0700 (PDT) Received: from mailgw1.fraunhofer.de (mailgw1.fraunhofer.de [153.96.1.17]) by core3.amsl.com (Postfix) with ESMTP id 5B4953A67F8 for ; Fri, 8 Aug 2008 06:39:27 -0700 (PDT) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de[host mailgw27] (8.14.2+/8.14.2) with ESMTP id m78DVphb007977; Fri, 8 Aug 2008 15:31:51 +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 m78DVolY007963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Aug 2008 15:31:51 +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 m78DVntP014204; Fri, 8 Aug 2008 15:31:49 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Aug 2008 15:31:48 +0200 Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A810@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PSAMP-INFO IE realtiveError Thread-Index: Acj4a6dzqFKTmP1sTMussACAxkYKXAA60QWA References: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A5F9@EXCHSRV.fokus.fraunhofer.de> <489AB8F2.2050800@cisco.com> From: "Zseby, Tanja" To: "Paul Aitken" X-Fraunhofer-Email-Policy: accepted Cc: psamp , Juergen Quittek 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Hi Paul, see comments below. > -----Original Message----- > From: Paul Aitken [mailto:paitken@cisco.com] > Sent: Thursday, August 07, 2008 10:57 AM > To: Zseby, Tanja > Cc: Benoit Claise; psamp; Juergen Quittek > Subject: Re: PSAMP-INFO IE realtiveError > > 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 > > Agreed. > > > > - I suggest to introduce CI limits and level to also report > > estimation errors > > > > - 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 > > 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. > > > > 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? > > > (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 would name the IEs: "the confidence boundaries and confidence level > have to be provided instead (with the upperCILimit, lowerCILimit and > confidenceLevel). o.k. > > > > 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. > > Again, as above, I would specifically name the IEs for this. again o.k. > > > > 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. > > 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. > > > 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 > > INFO>], > > or with the relativeError Information Element [PSAMP-INFO > > INFO>]. > > > > NEW: > > > > ... The accuracy for a measured information elelment SHOULD be > reported > > either with the fixedError Information Element [PSAMP-INFO > > INFO>], > > or with the relativeError Information Element [PSAMP-INFO > > 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? > > > > > > > > > > - 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. > > 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? Or maybe check whether the NTP and TICTOC have a term for this... Kind regards Tanja > > Sorry for the late comments, I was quite busy with PSAMP-TECH > before... > > Thanks for your input! > > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Fri Aug 8 07:05:31 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EB223A6D75; Fri, 8 Aug 2008 07:05:31 -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 702CC3A6D73 for ; Fri, 8 Aug 2008 07:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 KoigRipMoaVy for ; Fri, 8 Aug 2008 07:05:29 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id EC2B73A6D59 for ; Fri, 8 Aug 2008 07:05:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,327,1215388800"; d="scan'208";a="16619193" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Aug 2008 14:05:27 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m78E5R2k001657; Fri, 8 Aug 2008 16:05:27 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m78E5RDK000634; Fri, 8 Aug 2008 14:05:27 GMT Received: from [10.61.97.83] (dhcp-10-61-97-83.cisco.com [10.61.97.83]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m78E5Qf20975; Fri, 8 Aug 2008 15:05:26 +0100 (BST) Message-ID: <489C52A7.6050907@cisco.com> Date: Fri, 08 Aug 2008 15:05:27 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 MIME-Version: 1.0 To: "Zseby, Tanja" References: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A5F9@EXCHSRV.fokus.fraunhofer.de> <489AB8F2.2050800@cisco.com> <804B13F8F3D94A4AB18B9B01ACB68FA101F5A810@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A810@EXCHSRV.fokus.fraunhofer.de> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3740; t=1218204327; x=1219068327; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20PSAMP-INFO=20IE=20realtiveError |Sender:=20; bh=2Ay7NnaxNaynj0WakNePePVjibkl+DsMHaS5MNIHa6k=; b=pZVF00Q3wveMnfHNrTesfzfxOBn9qRNZHZDJCStukxnMU+1O7Tbyi51ZaQ P0D7KdUkK0m21f4G2YrK4owsz+lSEsGT27gueI5JOg+7/x7fKpFhcfG9ucK7 9QCeZeYyVe; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: psamp , Juergen Quittek 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org 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. >>> 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". >> 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? >>> NEW: >>> >>> ... The accuracy for a measured information elelment SHOULD be reported >>> either with the fixedError Information Element [PSAMP-INFO >>> ], >>> or with the relativeError Information Element [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. 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 PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Fri Aug 8 07:29:18 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EE353A6AD9; Fri, 8 Aug 2008 07:29:18 -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 5318A3A6AD9 for ; Fri, 8 Aug 2008 07:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.32 X-Spam-Level: X-Spam-Status: No, score=-5.32 tagged_above=-999 required=5 tests=[AWL=0.929, 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 a6RqFHmTjIbe for ; Fri, 8 Aug 2008 07:29:16 -0700 (PDT) Received: from mailgwb1.fraunhofer.de (mailgwb1.fraunhofer.de [153.96.87.18]) by core3.amsl.com (Postfix) with ESMTP id 0764E3A681D for ; Fri, 8 Aug 2008 07:29:15 -0700 (PDT) Received: from mailgwb1.fraunhofer.de (localhost [127.0.0.1]) by mailgwb1.fraunhofer.de[host mailgwb1] (8.14.2+/8.14.2) with ESMTP id m78ESbtZ028046; Fri, 8 Aug 2008 16:28:37 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgwb1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m78ESbFr028033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Aug 2008 16:28:37 +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 m78ESZH8016969; Fri, 8 Aug 2008 16:28:35 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Aug 2008 16:28:31 +0200 Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A819@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PSAMP-INFO IE realtiveError Thread-Index: Acj5X9Q5Cve0zcmCRDCALd/YjrPF1wAAL+/w References: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A5F9@EXCHSRV.fokus.fraunhofer.de> <489AB8F2.2050800@cisco.com> <804B13F8F3D94A4AB18B9B01ACB68FA101F5A810@EXCHSRV.fokus.fraunhofer.de> <489C52A7.6050907@cisco.com> From: "Zseby, Tanja" To: "Paul Aitken" X-Fraunhofer-Email-Policy: accepted Cc: psamp , Juergen Quittek 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Hi Paul, > -----Original Message----- > From: Paul Aitken [mailto:paitken@cisco.com] > 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 > >>> I > >>> NFO>], or with the relativeError Information Element [PSAMP-INFO > >>> 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 PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Fri Aug 8 08:14:08 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 617423A6971; Fri, 8 Aug 2008 08:14:08 -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 4FDE53A6914 for ; Fri, 8 Aug 2008 08:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 h0ZhJdFEMHMI for ; Fri, 8 Aug 2008 08:14:06 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 209753A6923 for ; Fri, 8 Aug 2008 08:14:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,327,1215388800"; d="asc'?scan'208";a="16627092" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Aug 2008 15:14:05 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m78FE5Ic022457; Fri, 8 Aug 2008 17:14:05 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m78FE4fr021673; Fri, 8 Aug 2008 15:14:04 GMT Received: from [10.55.163.35] (ams-andrjohn-8712.cisco.com [10.55.163.35]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m78FE3f28019; Fri, 8 Aug 2008 16:14:03 +0100 (BST) From: Andrew Johnson To: "Zseby, Tanja" In-Reply-To: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A819@EXCHSRV.fokus.fraunhofer.de> References: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A5F9@EXCHSRV.fokus.fraunhofer.de> <489AB8F2.2050800@cisco.com> <804B13F8F3D94A4AB18B9B01ACB68FA101F5A810@EXCHSRV.fokus.fraunhofer.de> <489C52A7.6050907@cisco.com> <804B13F8F3D94A4AB18B9B01ACB68FA101F5A819@EXCHSRV.fokus.fraunhofer.de> Date: Fri, 08 Aug 2008 16:14:02 +0100 Message-Id: <1218208442.9068.45.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3-1.2mdv2008.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2166; t=1218208445; x=1219072445; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[PSAMP]=20PSAMP-INFO=20IE=20realtiveErr or |Sender:=20; bh=ecXdUunZzkQVxWLrJ049I7s+cBh+D98aHTTWZcCntv0=; b=idLekblWjIZzQfrP2VIpPV9qCZgG+3xToDgIFCzbux8chb6LyGft05d6lU ZBmIDky+ZuQtaDAFoz5x8+YGOcO+JUIPO3pdmFZdsYleEskRIDDuk25zTg71 PeVk4tFli1; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: psamp , Juergen Quittek 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1655131485==" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org --===============1655131485== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-cMosT4Zm8y/KuCXv5OnW" --=-cMosT4Zm8y/KuCXv5OnW Content-Type: text/plain Content-Transfer-Encoding: quoted-printable [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? > >=20 > > In that case there would be no need to ever report "absoluteError" - > > because all the original measurements can be corrected before being > > exported. >=20 > 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 --=-cMosT4Zm8y/KuCXv5OnW Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBInGK3xaGr6Yt1y6ARAvsNAKDCyiJuqcQyoU5DAa5ZXWsGVZrt+gCffiUw EU+9mAn1+sc68TRb0NNg9sA= =D0dL -----END PGP SIGNATURE----- --=-cMosT4Zm8y/KuCXv5OnW-- --===============1655131485== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --===============1655131485==-- From psamp-bounces@ietf.org Fri Aug 8 09:08:23 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D5D03A6B45; Fri, 8 Aug 2008 09:08:23 -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 7F04E3A6B4D for ; Fri, 8 Aug 2008 09:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.784 X-Spam-Level: X-Spam-Status: No, score=-5.784 tagged_above=-999 required=5 tests=[AWL=0.465, 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 PuY1Mik1+kVp for ; Fri, 8 Aug 2008 09:08:21 -0700 (PDT) Received: from mailgwb1.fraunhofer.de (mailgwb1.fraunhofer.de [153.96.87.18]) by core3.amsl.com (Postfix) with ESMTP id 50AF83A6A9C for ; Fri, 8 Aug 2008 09:08:20 -0700 (PDT) Received: from mailgwb1.fraunhofer.de (localhost [127.0.0.1]) by mailgwb1.fraunhofer.de[host mailgwb1] (8.14.2+/8.14.2) with ESMTP id m78G82bo015431; Fri, 8 Aug 2008 18:08:03 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgwb1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m78G7qci015145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Aug 2008 18:08:02 +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 m78G7pFR021265; Fri, 8 Aug 2008 18:07:51 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Aug 2008 18:07:49 +0200 Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A81C@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PSAMP] PSAMP-INFO IE realtiveError Thread-Index: Acj5aWtc41Jz//l+S8W0/5IKLE1cDQABxDNw 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> From: "Zseby, Tanja" To: "Andrew Johnson" X-Fraunhofer-Email-Policy: accepted Cc: psamp , Juergen Quittek 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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, 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% 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. Hope this was not even more confusing... 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 From psamp-bounces@ietf.org Fri Aug 8 11:48:19 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61F173A68E7; Fri, 8 Aug 2008 11:48:19 -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 30F263A68BD for ; Fri, 8 Aug 2008 11:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 fYAyiIhLHaRO for ; Fri, 8 Aug 2008 11:48:17 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9947A3A676A for ; Fri, 8 Aug 2008 11:48:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,329,1215388800"; d="asc'?scan'208";a="16641458" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Aug 2008 18:48:15 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m78ImFGe001659; Fri, 8 Aug 2008 20:48:15 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m78ImFGl004658; Fri, 8 Aug 2008 18:48:15 GMT Received: from [10.55.163.35] (ams-andrjohn-8712.cisco.com [10.55.163.35]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m78ImEf12290; Fri, 8 Aug 2008 19:48:14 +0100 (BST) From: Andrew Johnson To: "Zseby, Tanja" In-Reply-To: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A81C@EXCHSRV.fokus.fraunhofer.de> 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> Date: Fri, 08 Aug 2008 19:48:13 +0100 Message-Id: <1218221293.9068.61.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3-1.2mdv2008.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5052; t=1218221295; x=1219085295; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20RE=3A=20[PSAMP]=20PSAMP-INFO=20IE=20realtiveErr or |Sender:=20; bh=U4RB5Iq1zC6R2gsXKaMe8gs3HV7jobXMRmRonlPxIy0=; b=BGrBxzMmDyjUwXODVi4JUZRn1Ug4XnjvS1JCEOwocDtYZ/QwCnO2SjUcmt 1HviNyxfCsKmhdbb0HTQCmI6W2znGPuPKD7fN/TPxCIWaJThYVHxJOGaVhMy 7bBwHjY75l; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: psamp , Juergen Quittek 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1837657598==" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org --===============1837657598== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hAW29DKGjtj8RVPwq7Vg" --=-hAW29DKGjtj8RVPwq7Vg Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2008-08-08 at 18:07 +0200, Zseby, Tanja wrote: > Hi Andrew, >=20 > 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).=20 > 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. >=20 > relError=3Dabserror/measured value >=20 >=20 > 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 >=20 > 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. > 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 >=20 > 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=20 > Person (measured): 80.75kg=20 >=20 > Mouse (real value): 0.50 kg=20 > Mouse (measured): 0.75 kg=20 >=20 > 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.=20 I don't think we have any need for an offset. > 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. Cheers Andrew > Kind regards > Tanja (starting to see white mice) >=20 >=20 > > -----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 > >=20 > > [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? > >=20 > > 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... > >=20 > > 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 > >=20 > > Cheers > >=20 > > Andrew >=20 --=-hAW29DKGjtj8RVPwq7Vg Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBInJTqxaGr6Yt1y6ARAltfAKDj/woBoTn9Sh1hIg9qXsJ4ESUnXwCdHpHA fPXcSTAis+aKkf0emBZREIs= =4GHA -----END PGP SIGNATURE----- --=-hAW29DKGjtj8RVPwq7Vg-- --===============1837657598== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --===============1837657598==-- From psamp-bounces@ietf.org Fri Aug 8 16:20:02 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-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 ; 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 ; 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 ; 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, 9 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" To: "Andrew Johnson" X-Fraunhofer-Email-Policy: accepted Cc: psamp , Juergen Quittek 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From psamp-bounces@ietf.org Wed Aug 13 15:13:06 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FF6D3A6B05; Wed, 13 Aug 2008 15:13: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 EC3543A6AFC for ; Wed, 13 Aug 2008 15:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Q1-5s-K65Slz for ; Wed, 13 Aug 2008 15:13:03 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2505B3A6AEF for ; Wed, 13 Aug 2008 15:13:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,203,1217808000"; d="asc'?scan'208";a="17090050" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Aug 2008 22:13:05 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7DMD6Bt004248; Thu, 14 Aug 2008 00:13:06 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7DMD571016604; Wed, 13 Aug 2008 22:13:05 GMT Received: from [10.55.163.35] (ams-andrjohn-8712.cisco.com [10.55.163.35]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m7DMCwY29501; Wed, 13 Aug 2008 23:13:04 +0100 (BST) From: Andrew Johnson To: "Zseby, Tanja" In-Reply-To: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A821@EXCHSRV.fokus.fraunhofer.de> 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> <804B13F8F3D94A4AB18B9B01ACB68FA101F5A821@EXCHSRV.fokus.fraunhofer.de> Date: Wed, 13 Aug 2008 23:12:58 +0100 Message-Id: <1218665578.9426.10.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3-1.2mdv2008.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7359; t=1218665586; x=1219529586; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20RE=3A=20[PSAMP]=20PSAMP-INFO=20IE=20realtiveErr or |Sender:=20; bh=DpABeNqui9OWDB7v5Rq7TH/e+EYLYvU6qoVj/nCXBFo=; b=XnChdvtp9kPpNs2lDaTqZ27V5JzruqO3IL0AK2CHMMrU2T2eFTLSUomTlm luWTsvrlO++AFRNHg/qW1Z6xiMnmflB5iUbuRt6hQdNb0SO9RHgtdKyYjWjV hb2PWXHsY4; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: psamp , Juergen Quittek 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0178750903==" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org --===============0178750903== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-dK0A8oD+qQsJtuKVobnX" --=-dK0A8oD+qQsJtuKVobnX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Tanja On Sat, 2008-08-09 at 01:19 +0200, Zseby, Tanja wrote: > Hi Andrew, >=20 > > -----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 > >=20 > >=20 > > 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=3Dabserror/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% > >=20 > > 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. > >=20 > > 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. >=20 > 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 (=3D 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?=20 Ah I see what you mean now. In general I think that only one type of error will be reported at once and that most of the time that will be an absolute error. I think there is still value in providing a way to express a relative error though. For example, clocks tend to drift over time so the larger the time measurement the larger the error, i.e. accurate to within 1 second per day is 0.0011574%. Cheers Andrew > >=20 > >=20 > > > 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. > >=20 > > I don't think we have any need for an offset. >=20 > o.k. I agree. >=20 > >=20 > > > Hope this was not even more confusing... > >=20 > > 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. >=20 > 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). >=20 > Kind regards, > Tanja >=20 > >=20 > > Cheers > >=20 > > Andrew > >=20 > >=20 > > > 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 > > > >=20 --=-dK0A8oD+qQsJtuKVobnX Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBIo1xmxaGr6Yt1y6ARAgYcAKCXu3+4pT5kym+HdFNHnN00R4FjXgCgjlS1 9KBP+jsMtsMIc3lEJ14+tFc= =4h6z -----END PGP SIGNATURE----- --=-dK0A8oD+qQsJtuKVobnX-- --===============0178750903== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --===============0178750903==-- From psamp-bounces@ietf.org Thu Aug 14 06:12:28 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 432C03A6BBB; Thu, 14 Aug 2008 06:12:28 -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 03DD63A6DAD for ; Thu, 14 Aug 2008 06:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.017 X-Spam-Level: X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.232, 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 FZMuq3n8OEaj for ; Thu, 14 Aug 2008 06:12:22 -0700 (PDT) Received: from mailgw1.fraunhofer.de (mailgw1.fraunhofer.de [153.96.1.17]) by core3.amsl.com (Postfix) with ESMTP id 8D7023A6922 for ; Thu, 14 Aug 2008 06:12:21 -0700 (PDT) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de[host mailgw21] (8.14.2+/8.14.2) with ESMTP id m7ED3Fdq016574; Thu, 14 Aug 2008 15:03:15 +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 m7ED3E5j016568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Aug 2008 15:03:14 +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 m7ED3CJQ027298; Thu, 14 Aug 2008 15:03:12 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Aug 2008 15:03:10 +0200 Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA101F5AA39@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PSAMP] PSAMP-INFO IE realtiveError Thread-Index: Acj9keK0MKRZiW7ATeeooY4YEPkAFwAe2bLg 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><804B13F8F3D94A4AB18B9B01ACB68FA101F5A821@EXCHSRV.fokus.fraunhofer.de> <1218665578.9426.10.camel@localhost> From: "Zseby, Tanja" To: "Andrew Johnson" X-Fraunhofer-Email-Policy: accepted Cc: psamp , Juergen Quittek 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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, great. So it seems that after a lot of mice stepping on and off the scale we have a common understanding of the terms :-) So to summarize: - we don't need an offset IE - we definitely include the absoluteError IE - we can also include the relativeError IE (maybe you as authors decide?) Kind regards Tanja > -----Original Message----- > From: psamp-bounces@ietf.org [mailto:psamp-bounces@ietf.org] On Behalf > Of Andrew Johnson > Sent: Thursday, August 14, 2008 12:13 AM > To: Zseby, Tanja > Cc: psamp; Juergen Quittek > Subject: Re: [PSAMP] PSAMP-INFO IE realtiveError > > Hi Tanja > > > On Sat, 2008-08-09 at 01:19 +0200, Zseby, Tanja wrote: > > 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? > > Ah I see what you mean now. In general I think that only one type of > error will be reported at once and that most of the time that will be > an absolute error. > > I think there is still value in providing a way to express a relative > error though. For example, clocks tend to drift over time so the > larger the time measurement the larger the error, i.e. accurate to > within 1 second per day is 0.0011574%. > > Cheers > > Andrew > > > > > > > > > > > > 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 From psamp-bounces@ietf.org Thu Aug 14 06:26:20 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C25F73A6DC9; Thu, 14 Aug 2008 06:26:20 -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 12EC83A6DC6 for ; Thu, 14 Aug 2008 06:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 XCgBKqH+xDol for ; Thu, 14 Aug 2008 06:26:18 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 07B283A67EC for ; Thu, 14 Aug 2008 06:26:18 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 2F2352C000303; Thu, 14 Aug 2008 15:25:57 +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 M2GZj8l2p0xO; Thu, 14 Aug 2008 15:25:57 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id EE26D2C000304; Thu, 14 Aug 2008 15:25:36 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 14 Aug 2008 15:25:35 +0200 Message-ID: <547F018265F92642B577B986577D671C2A5471@VENUS.office> In-Reply-To: <804B13F8F3D94A4AB18B9B01ACB68FA101F5AA39@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [PSAMP] PSAMP-INFO IE realtiveError Thread-Index: Acj9keK0MKRZiW7ATeeooY4YEPkAFwAe2bLgAADlEXA= References: DEFANGED[22027]:<804B13F8F3D94A4AB18B9B01ACB68FA101F5A5F9@EXCHSRV.fokus.fraunhofer.de><489AB8F2.2050800@cisco.com><804B13F8F3D94A4AB18B9B01ACB68FA101F5A810@EXCHSRV.fokus.fraunhofer.de><489C52A7.6050907@cisco.com><804B13F8F3D94A4AB18B9B01ACB68FA101F5A819@EXCHSRV.fokus.frau " " nhofer.de><1218208442.9068.45.camel@localhost><804B13F8F3D94A4AB18B9B01ACB68FA101F5A81C@EXCHSRV.fokus.fraunhofer.de><1218221293.9068.61.camel@localhost><804B13F8F3D94A4AB18B9B01ACB68FA101F5A821@EXCHSRV.fokus.fraunhofer.de><1218665578.9426.10.camel@localhost> <804B13F8F3D94A4AB18B9B01ACB68FA101F5AA39@EXCHSRV.fokus.fraunhofer.de> From: "Thomas Dietz" To: "Zseby, Tanja" , "Andrew Johnson" , "Paul Aitken" Cc: psamp , Juergen Quittek 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1202107733==" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org This is a multipart message in MIME format. --===============1202107733== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_003B_01C8FE21.FF5C15E0" This is a multipart message in MIME format. ------=_NextPart_000_003B_01C8FE21.FF5C15E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tanja, Andrew, Paul, since the topic seems to be settled now can you please summarize your discussion in this thread? I would like to know what to put into an updated version of the draft so that it can get published asap. Best Regards, Thomas -- Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu NEC Europe Ltd. Phone: +49 6221 4342-128 NEC Laboratories Europe Fax: +49 6221 4342-155 Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.nw.neclab.eu NEC Europe Limited Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: psamp-bounces@ietf.org [mailto:psamp-bounces@ietf.org] On Behalf > Of Zseby, Tanja > Sent: Donnerstag, 14. August 2008 15:03 > To: Andrew Johnson > Cc: psamp; Juergen Quittek > Subject: Re: [PSAMP] PSAMP-INFO IE realtiveError > > Hi Andrew, > > great. So it seems that after a lot of mice stepping on and off the > scale we have a common understanding of the terms :-) > So to summarize: > - we don't need an offset IE > - we definitely include the absoluteError IE > - we can also include the relativeError IE (maybe you as authors > decide?) > > Kind regards > Tanja > > > -----Original Message----- > > From: psamp-bounces@ietf.org [mailto:psamp-bounces@ietf.org] On > Behalf > > Of Andrew Johnson > > Sent: Thursday, August 14, 2008 12:13 AM > > To: Zseby, Tanja > > Cc: psamp; Juergen Quittek > > Subject: Re: [PSAMP] PSAMP-INFO IE realtiveError > > > > Hi Tanja > > > > > > On Sat, 2008-08-09 at 01:19 +0200, Zseby, Tanja wrote: > > > 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? > > > > Ah I see what you mean now. In general I think that only one type of > > error will be reported at once and that most of the time that will be > > an absolute error. > > > > I think there is still value in providing a way to express a relative > > error though. For example, clocks tend to drift over time so the > > larger the time measurement the larger the error, i.e. accurate to > > within 1 second per day is 0.0011574%. > > > > Cheers > > > > Andrew > > > > > > > > > > > > > > > > > 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 ------=_NextPart_000_003B_01C8FE21.FF5C15E0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggM5MIICoqADAgECAhBD3kUGfpHtO7Zw5BdS Zkm1MA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTkwMDAw MDBaFw0wOTEwMTIyMzU5NTlaMEMxETAPBgNVBAoTCFZlcmlTaWduMS4wLAYDVQQLEyVWZXJpU2ln biBDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIENBMIGdMA0GCSqGSIb3DQEBAQUAA4GLADCBhwKB gQDcKpmdbjP8u0F2xDkejfd255APdFVhYXI8+DdLGx8I6TAdcMUWiWAzRkh/xtCaPXaYw6HBrFLR F7kUBGmGXGFPs2Vli2Oi7iF8Qa+tckDDTZGzSb6Y+1fHWi6wS6fvCSTzgZ04xZLaSqeYUanYMHYt atavL37bESqF+2VgWkXoGwIBA6OBsDCBrTAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYL YIZIAYb4RQEHFwIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0 BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcyLmNybDALBgNV HQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4GBAImQvq5zldxCHk2g j+8C+6loWwvtLEWziOuOTs80iqY1DoOM0LQTL+uqlfw2fmiFnPw3WVPKuQwGhOE7ZAcLITREdYg3 NsW1WA2oODuvoGG4fGwXn+H/4dpDqEKGAl1K7ZyQjRKqTMJuA5gfQ69+m0m1tHSjbq1qW+svscua HqaaMIIDZjCCAs+gAwIBAgIQRuECOhCAVuaaKKVALy7ycDANBgkqhkiG9w0BAQQFADBDMREwDwYD VQQKEwhWZXJpU2lnbjEuMCwGA1UECxMlVmVyaVNpZ24gQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVh bCBDQTAeFw0wNzEwMjQwMDAwMDBaFw0wODEwMjMyMzU5NTlaMIHdMRswGQYDVQQKDBJORUMgRXVy b3BlIExpbWl0ZWQxRjBEBgNVBAsMPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9DUFMgSW5j b3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTkxNTAzBgNVBAsMLENvbXBhbnkgLSBORUMgTGFib3Jh dG9yaWVzIEV1cm9wZSBIZWlkZWxiZXJnMRUwEwYDVQQDDAxUaG9tYXMgRGlldHoxKDAmBgkqhkiG 9w0BCQEWGXRob21hcy5kaWV0ekBudy5uZWNsYWIuZXUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALC4yWRsqDAwBYKjb3zoUfE18Tj5pOb+b2u/jmoeW6I3KKtzQxSIcW6qGrkrks0px63VYr72 6VF72Qhv4K31ntSOOLVOgz/yUXu2TBqsGxzcpjHD9LIJPK2LbEoo8m4t5mcVQReNhvrsCFukpYZn tb6xoCmmFfxcXeZh48Rhn4wVAgMBAAGjgb8wgbwwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBxcCMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYD VR0PBAQDAgWgMBEGCWCGSAGG+EIBAQQEAwIHgDBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vb25z aXRlY3JsLnZlcmlzaWduLmNvbS9PblNpdGVQdWJsaWMvTGF0ZXN0Q1JMLmNybDANBgkqhkiG9w0B AQQFAAOBgQAeld8hZLp3F1TtzJkmSe1io5guKbUqux6y0l//Ya5ESWBOpApe3vweWAsZYbn3dw0U F73oKpjuW6qdSNJizqtngj9is0DLLqH3u2PG3zksB7oy4hYPKejEuq4HXz3/bIxZSwvl7S9XL0Ce tSXJji+Rh4wFkL3GLZkWrlXPO+Y5tTGCAuowggLmAgEBMFcwQzERMA8GA1UEChMIVmVyaVNpZ24x LjAsBgNVBAsTJVZlcmlTaWduIENsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgQ0ECEEbhAjoQgFbm miilQC8u8nAwCQYFKw4DAhoFAKCCAekwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDgwODE0MTMyNTM1WjAjBgkqhkiG9w0BCQQxFgQUYZPw7Kvk+7ODURi3wFwTt5X+ 6kAwZgYJKwYBBAGCNxAEMVkwVzBDMREwDwYDVQQKEwhWZXJpU2lnbjEuMCwGA1UECxMlVmVyaVNp Z24gQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBDQQIQRuECOhCAVuaaKKVALy7ycDBoBgsqhkiG 9w0BCRACCzFZoFcwQzERMA8GA1UEChMIVmVyaVNpZ24xLjAsBgNVBAsTJVZlcmlTaWduIENsYXNz IDIgT25TaXRlIEluZGl2aWR1YWwgQ0ECEEbhAjoQgFbmmiilQC8u8nAwgbcGCSqGSIb3DQEJDzGB qTCBpjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF Kw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwCgYIKoZIhvcNAgUw DQYJKoZIhvcNAQEBBQAEgYCXDBM/JtqY+rzdvmYb92MbNA0xqvbJV1W5ptjxFoyVnzEcoZY/aAc7 7ZMWi1fscJHHZZTgHX3Hq+CMbOM0Iu1Leq2oADv5w2Np56ifw0j+t1YjTpiAeRkQwv74DsCc7TdC wHQYNZNCtnm5nt4tj+IapC8cF+4oOlhXksD2PCgKDwAAAAAAAA== ------=_NextPart_000_003B_01C8FE21.FF5C15E0-- --===============1202107733== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --===============1202107733==-- From psamp-bounces@ietf.org Thu Aug 14 06:37:54 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26D7F3A6DC6; Thu, 14 Aug 2008 06:37:54 -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 656A43A6DB8 for ; Thu, 14 Aug 2008 06:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 LQevRD92YvIE for ; Thu, 14 Aug 2008 06:37:46 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 80D233A6DC6 for ; Thu, 14 Aug 2008 06:37:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,210,1217808000"; d="asc'?scan'208";a="17165279" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Aug 2008 13:37:09 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7EDb9DG027965; Thu, 14 Aug 2008 15:37:09 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7EDb9gi025050; Thu, 14 Aug 2008 13:37:09 GMT Received: from [10.55.163.35] (ams-andrjohn-8712.cisco.com [10.55.163.35]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m7EDb2p13711; Thu, 14 Aug 2008 14:37:02 +0100 (BST) From: Andrew Johnson To: Thomas Dietz In-Reply-To: <547F018265F92642B577B986577D671C2A5471@VENUS.office> References: DEFANGED[22027]:<804B13F8F3D94A4AB18B9B01ACB68FA101F5A5F9@EXCHSRV.fokus.fraunhofer.de> <489AB8F2.2050800@cisco.com> <804B13F8F3D94A4AB18B9B01ACB68FA101F5A810@EXCHSRV.fokus.fraunhofer.de> <489C52A7.6050907@cisco.com> <804B13F8F3D94A4AB18B9B01ACB68FA101F5A819@EXCHSRV.fokus.frau " " nhofer.de> <1218208442.9068.45.camel@localhost> <804B13F8F3D94A4AB18B9B01ACB68FA101F5A81C@EXCHSRV.fokus.fraunhofer.de> <1218221293.9068.61.camel@localhost> <804B13F8F3D94A4AB18B9B01ACB68FA101F5A821@EXCHSRV.fokus.fraunhofer.de> <1218665578.9426.10.camel@localhost> <804B13F8F3D94A4AB18B9B01ACB68FA101F5AA39@EXCHSRV.fokus.fraunhofer.de> <547F018265F92642B577B986577D671C2A5471@VENUS.office> Date: Thu, 14 Aug 2008 14:37:01 +0100 Message-Id: <1218721021.9426.57.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3-1.2mdv2008.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11420; t=1218721029; x=1219585029; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20RE=3A=20[PSAMP]=20PSAMP-INFO=20IE=20realtiveErr or |Sender:=20; bh=ZvvL2ayRM/1o8AbRND92n3VvbQ0tDS64A53fneweDQ8=; b=Pos4B+QNpqf/TSNLO5MdRgtE0Hjdl0i+PaM58rUkxwxQU7lhJazlAByofh He/GdccsUoSe360qvyPwtAwXQeZncvSud5rACJuhaCBSBnHfFXECSuw1KMXg hJyeGzYxmE; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: psamp , "Zseby, Tanja" , Juergen Quittek 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0828277547==" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org --===============0828277547== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-sbxpFLGMHj3R0a1rdSY7" --=-sbxpFLGMHj3R0a1rdSY7 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Thomas I don't think much has changed. If I filter out the misunderstandings I think you get something like this: Tanja: What's this fixedError thing for? Paul: It's the uncertainty of the measurement expressed as a fixed amount of the measured units. Tanja: That's a confusing name, let's call it absoluteError. Everyone: OK. Tanja: Why do we even need relativeError then? Andrew: I think it might be useful for certain measurement devices. Tanja: OK, well keep it if you want. In conclusion, fixedError is now called absoluteError and we'll keep relativeError in case it's needed. For those who followed the thread, does that sound fair? Cheers Andrew On Thu, 2008-08-14 at 15:25 +0200, Thomas Dietz wrote: > Hi Tanja, Andrew, Paul, >=20 > since the topic seems to be settled now can you please summarize your > discussion in this thread? I would like to know what to put into an updat= ed > version of the draft so that it can get published asap. >=20 > Best Regards, >=20 > Thomas >=20 > --=20 > Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu > NEC Europe Ltd. Phone: +49 6221 4342-128 > NEC Laboratories Europe Fax: +49 6221 4342-155 > Network Research Division > Kurfuersten-Anlage 36 > 69115 Heidelberg, Germany http://www.nw.neclab.eu >=20 > NEC Europe Limited Registered in England 2832014 > Registered Office: NEC House, 1 Victoria Road, London W3 6BL >=20 > > -----Original Message----- > > From: psamp-bounces@ietf.org [mailto:psamp-bounces@ietf.org] On Behalf > > Of Zseby, Tanja > > Sent: Donnerstag, 14. August 2008 15:03 > > To: Andrew Johnson > > Cc: psamp; Juergen Quittek > > Subject: Re: [PSAMP] PSAMP-INFO IE realtiveError > >=20 > > Hi Andrew, > >=20 > > great. So it seems that after a lot of mice stepping on and off the > > scale we have a common understanding of the terms :-) > > So to summarize: > > - we don't need an offset IE > > - we definitely include the absoluteError IE > > - we can also include the relativeError IE (maybe you as authors > > decide?) > >=20 > > Kind regards > > Tanja > >=20 > > > -----Original Message----- > > > From: psamp-bounces@ietf.org [mailto:psamp-bounces@ietf.org] On > > Behalf > > > Of Andrew Johnson > > > Sent: Thursday, August 14, 2008 12:13 AM > > > To: Zseby, Tanja > > > Cc: psamp; Juergen Quittek > > > Subject: Re: [PSAMP] PSAMP-INFO IE realtiveError > > > > > > Hi Tanja > > > > > > > > > On Sat, 2008-08-09 at 01:19 +0200, Zseby, Tanja wrote: > > > > 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=3Dabserror/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 (=3D 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? > > > > > > Ah I see what you mean now. In general I think that only one type of > > > error will be reported at once and that most of the time that will be > > > an absolute error. > > > > > > I think there is still value in providing a way to express a relative > > > error though. For example, clocks tend to drift over time so the > > > larger the time measurement the larger the error, i.e. accurate to > > > within 1 second per day is 0.0011574%. > > > > > > Cheers > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > 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 --=-sbxpFLGMHj3R0a1rdSY7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBIpDT5xaGr6Yt1y6ARAohDAKDuPHMLcFZtuOs4J6v/i5ixCRIPnwCfTblI zsuBaUC6To41kS8PDNkfJZo= =JEhO -----END PGP SIGNATURE----- --=-sbxpFLGMHj3R0a1rdSY7-- --===============0828277547== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --===============0828277547==-- From psamp-bounces@ietf.org Thu Aug 14 06:45:28 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E62DB3A6C17; Thu, 14 Aug 2008 06:45:28 -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 5261A3A6DE2 for ; Thu, 14 Aug 2008 06:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.063 X-Spam-Level: X-Spam-Status: No, score=-6.063 tagged_above=-999 required=5 tests=[AWL=0.186, 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 IG3j8Dt0gnI2 for ; Thu, 14 Aug 2008 06:45:19 -0700 (PDT) Received: from mailgw1.fraunhofer.de (mailgw1.fraunhofer.de [153.96.1.17]) by core3.amsl.com (Postfix) with ESMTP id 25E1E3A6DE1 for ; Thu, 14 Aug 2008 06:45:17 -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 m7EDiDd0025488; Thu, 14 Aug 2008 15:44:14 +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 m7EDiDBI025481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Aug 2008 15:44:13 +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 m7EDiCIl029207; Thu, 14 Aug 2008 15:44:12 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Aug 2008 15:44:11 +0200 Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA101F5AA44@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PSAMP] PSAMP-INFO IE realtiveError Thread-Index: Acj+Eu7LY96plR/nQ228DndIbsBAtgAAEisA References: DEFANGED[22027]:<804B13F8F3D94A4AB18B9B01ACB68FA101F5A5F9@EXCHSRV.fokus.fraunhofer.de> <489AB8F2.2050800@cisco.com> <804B13F8F3D94A4AB18B9B01ACB68FA101F5A810@EXCHSRV.fokus.fraunhofer.de> <489C52A7.6050907@cisco.com> <804B13F8F3D94A4AB18B9B01ACB68FA101F5A819@EXCHSRV.fokus.frau " " nhofer.de> <1218208442.9068.45.camel@localhost> <804B13F8F3D94A4AB18B9B01ACB68FA101F5A81C@EXCHSRV.fokus.fraunhofer.de> <1218221293.9068.61.camel@localhost> <804B13F8F3D94A4AB18B9B01ACB68FA101F5A821@EXCHSRV.fokus.fraunhofer.de> <1218665578.9426.10.camel@localhost> <804B13F8F3D94A4AB18B9B01ACB68FA101F5AA39@EXCHSRV.fokus.fraunhofer.de> <547F018265F92642B577B986577D671C2A5471@VENUS.office> <1218721021.9426.57.camel@localhost> From: "Zseby, Tanja" To: "Andrew Johnson" , "Thomas Dietz" X-Fraunhofer-Email-Policy: accepted Cc: psamp , Juergen Quittek 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Hi Thomas and Andrew, I agree. But I also would add the confidence boundaries levels and the small changes in PSAMP-PROTO as suggested in my first mail. But those changes were mainly agreed by the authors, correct? Kind regards Tanja > -----Original Message----- > From: Andrew Johnson [mailto:andrjohn@cisco.com] > Sent: Thursday, August 14, 2008 3:37 PM > To: Thomas Dietz > Cc: Zseby, Tanja; Paul Aitken; psamp; Juergen Quittek > Subject: RE: [PSAMP] PSAMP-INFO IE realtiveError > > Hi Thomas > > I don't think much has changed. If I filter out the misunderstandings > I think you get something like this: > > Tanja: What's this fixedError thing for? > Paul: It's the uncertainty of the measurement expressed as a fixed > amount of the measured units. > Tanja: That's a confusing name, let's call it absoluteError. > Everyone: OK. > Tanja: Why do we even need relativeError then? > Andrew: I think it might be useful for certain measurement devices. > Tanja: OK, well keep it if you want. > > > In conclusion, fixedError is now called absoluteError and we'll keep > relativeError in case it's needed. > > For those who followed the thread, does that sound fair? > > > Cheers > > Andrew > > > On Thu, 2008-08-14 at 15:25 +0200, Thomas Dietz wrote: > > Hi Tanja, Andrew, Paul, > > > > since the topic seems to be settled now can you please summarize your > > discussion in this thread? I would like to know what to put into an > > updated version of the draft so that it can get published asap. > > > > Best Regards, > > > > Thomas > > > > -- > > Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu > > NEC Europe Ltd. Phone: +49 6221 4342-128 > > NEC Laboratories Europe Fax: +49 6221 4342-155 > > Network Research Division > > Kurfuersten-Anlage 36 > > 69115 Heidelberg, Germany http://www.nw.neclab.eu > > > > NEC Europe Limited Registered in England 2832014 > > Registered Office: NEC House, 1 Victoria Road, London W3 6BL > > > > > -----Original Message----- > > > From: psamp-bounces@ietf.org [mailto:psamp-bounces@ietf.org] On > > > Behalf Of Zseby, Tanja > > > Sent: Donnerstag, 14. August 2008 15:03 > > > To: Andrew Johnson > > > Cc: psamp; Juergen Quittek > > > Subject: Re: [PSAMP] PSAMP-INFO IE realtiveError > > > > > > Hi Andrew, > > > > > > great. So it seems that after a lot of mice stepping on and off the > > > scale we have a common understanding of the terms :-) So to > > > summarize: > > > - we don't need an offset IE > > > - we definitely include the absoluteError IE > > > - we can also include the relativeError IE (maybe you as authors > > > decide?) > > > > > > Kind regards > > > Tanja > > > > > > > -----Original Message----- > > > > From: psamp-bounces@ietf.org [mailto:psamp-bounces@ietf.org] On > > > Behalf > > > > Of Andrew Johnson > > > > Sent: Thursday, August 14, 2008 12:13 AM > > > > To: Zseby, Tanja > > > > Cc: psamp; Juergen Quittek > > > > Subject: Re: [PSAMP] PSAMP-INFO IE realtiveError > > > > > > > > Hi Tanja > > > > > > > > > > > > On Sat, 2008-08-09 at 01:19 +0200, Zseby, Tanja wrote: > > > > > 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? > > > > > > > > Ah I see what you mean now. In general I think that only one > type > > > > of error will be reported at once and that most of the time that > > > > will be an absolute error. > > > > > > > > I think there is still value in providing a way to express a > > > > relative error though. For example, clocks tend to drift over > > > > time so the larger the time measurement the larger the error, > i.e. > > > > accurate to within 1 second per day is 0.0011574%. > > > > > > > > Cheers > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Thu Aug 14 06:47:58 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7646F3A6B7E; Thu, 14 Aug 2008 06:47:58 -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 062D03A6999 for ; Thu, 14 Aug 2008 06:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 TQN1XnLyRRSs for ; Thu, 14 Aug 2008 06:47:57 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A914A3A6405 for ; Thu, 14 Aug 2008 06:47:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,210,1217808000"; d="scan'208";a="17166990" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Aug 2008 13:47:22 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7EDlM9r031999; Thu, 14 Aug 2008 15:47:22 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7EDlM2n029732; Thu, 14 Aug 2008 13:47:22 GMT Received: from [10.61.81.108] (ams3-vpn-dhcp4461.cisco.com [10.61.81.108]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m7EDlLp14607; Thu, 14 Aug 2008 14:47:21 +0100 (BST) Message-ID: <48A4376C.30708@cisco.com> Date: Thu, 14 Aug 2008 14:47:24 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 MIME-Version: 1.0 To: Andrew Johnson References: DEFANGED[22027]:<804B13F8F3D94A4AB18B9B01ACB68FA101F5A5F9@EXCHSRV.fokus.fraunhofer.de> <489AB8F2.2050800@cisco.com> <804B13F8F3D94A4AB18B9B01ACB68FA101F5A810@EXCHSRV.fokus.fraunhofer.de> <489C52A7.6050907@cisco.com> <804B13F8F3D94A4AB18B9B01ACB68FA101F5A819@EXCHSRV.fokus.frau " " nhofer.de> <1218208442.9068.45.camel@localhost> <804B13F8F3D94A4AB18B9B01ACB68FA101F5A81C@EXCHSRV.fokus.fraunhofer.de> <1218221293.9068.61.camel@localhost> <804B13F8F3D94A4AB18B9B01ACB68FA101F5A821@EXCHSRV.fokus.fraunhofer.de> <1218665578.9426.10.camel@localhost> <804B13F8F3D94A4AB18B9B01ACB68FA101F5AA39@EXCHSRV.fokus.fraunhofer.de> <547F018265F92642B577B986577D671C2A5471@VENUS.office> <1218721021.9426.57.camel@localhost> In-Reply-To: <1218721021.9426.57.camel@localhost> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1025; t=1218721642; x=1219585642; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[PSAMP]=20PSAMP-INFO=20IE=20realtiveErr or |Sender:=20; bh=ygSwt/iHxZZJYPfNM6hzkKiz62jSuBh4taTUfNcav3c=; b=MLO7HOGL9IQu5CKf8mJR1dVGDhvXxgMJ+kS7sg6TG/op/ccmokZ8+/z1h9 nvtjNUdcKpmTxDleLoKB/F6umC44Xd9ElBdFNZgD99Sb8/gTVlTw6EPf6/Af VDs2eNos1W; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: psamp , "Zseby, Tanja" , Juergen Quittek 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Andrew, > I don't think much has changed. If I filter out the misunderstandings I > think you get something like this: > > Tanja: What's this fixedError thing for? > Paul: It's the uncertainty of the measurement expressed as a fixed > amount of the measured units. > Tanja: That's a confusing name, let's call it absoluteError. > Everyone: OK. > Tanja: Why do we even need relativeError then? > Andrew: I think it might be useful for certain measurement devices. > Tanja: OK, well keep it if you want. > > > In conclusion, fixedError is now called absoluteError and we'll keep > relativeError in case it's needed. > > For those who followed the thread, does that sound fair? Yes. Tanja, > I agree. But I also would add the confidence boundaries levels and the > small changes in PSAMP-PROTO as suggested in my first mail. > But those changes were mainly agreed by the authors, correct? Yes. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Wed Aug 20 04:00:34 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2DE3A6B2A; Wed, 20 Aug 2008 04:00:34 -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 9428E3A6B2A for ; Wed, 20 Aug 2008 04:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.638 X-Spam-Level: X-Spam-Status: No, score=-0.638 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_20=-0.74, HELO_EQ_DE=0.35] 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 gV2Cju4vu-02 for ; Wed, 20 Aug 2008 04:00:32 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id 4182C3A6A0D for ; Wed, 20 Aug 2008 04:00:32 -0700 (PDT) Received: from u-172-c138.cs.uni-tuebingen.de ([134.2.172.138]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1KVlPw-0003Ub-IJ for psamp@ietf.org; Wed, 20 Aug 2008 12:59:56 +0200 Message-ID: <48ABF960.7020401@informatik.uni-tuebingen.de> Date: Wed, 20 Aug 2008 13:00:48 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: psamp Subject: [PSAMP] PSAMP Protocol: Selection Sequence Statistics 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1114028361==" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1114028361== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010905060006070900000106" This is a cryptographically signed message in MIME format. --------------ms010905060006070900000106 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all, The PSAMP protocol draft specifies: 6.5.3 Selection Sequence Statistics Report Interpretation A Selector MAY be used in multiple Selection Sequences. However, each use of a Selector must be independent, so each separate logical instance of a Selector MUST maintain its own individual Selection State and statistics. The motivation is that the number of observed and selected packets is to be counted for each Selector (or selection step) along a Selection Sequence, right? If I interprete the above paragraph correctly, it forbids the deployment of the same Selector instance in two different Selection Sequences. However, this would be over-restrictive. Consider the following setup of two Selection Sequences consisting of three Selector instances Sampler 1, Filter 1 and Filter 2: +-> Filter 1 Sampler 1 --+ +-> Filter 2 Selection Sequence 1: Sampler 1, Filter 1 Selection Sequence 2: Sampler 1, Filter 2 Although this setup is not allowed according to the PSAMP protocol specification, it still allows gathering the desired statistics. Yet, PSAMP forces me to deploy one more Selector instance: Sampler 1 --> Filter 1 Sampler 2 --> Filter 2 This is a waste of resources. Also, the result is not necessarily the same if the packet selection in Sampler 1 and Sampler 2 is independent. In order to gather the desired statistics for each Selector instance along a Selection Sequence, it is sufficient to fulfill the following: A single instance of a Selector MAY be used in multiple Selection Sequences if it sees the same packets in all Selection Sequences and if the packets are either observed by a single Observation Point or selected by a single Selector instance. In any other case, separate instances of the Selector MUST be used in order to maintain separate individual Selection State and statistics. Note that this specification still disallows setups like: Sampler 1 --+ +-> Filter 1 Sampler 2 --+ In this case, the statistics gathered in Filter 1 are based on aggregated packet streams of two Selection Sequences, so the following sentence from the PSAMP protocol is not fulfilled: Within a Selection Sequence composed of several Primitive Selectors, the number of packets selected for one Selector is equal to the number of packets seen by the next Selector. Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms010905060006070900000106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDgyMDExMDA0OFowIwYJKoZIhvcNAQkEMRYEFO/FYRHb1GUE Z3QBUIGmST7Uz1BIMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQCx9/W+PJXSyi3ltItJWJjCs/RcV3e/Imv26xt89bQaiREB7YYcUbfy9aS+ w8RhX8bC+1l6Jm9ayvDfqgwdENB+Gm48ugiIXUz+A9t52otnUc9TUDFA6xCmugdoDOpROIHO knVLgoOQry9RAbHskveoV8Vbcy/M8hwwmvT/vGykpbpQiFE3iNdd/o9/mwXALELcYJverwR4 HFcvrlYW/mnI28ftCk/FOr7rbHT9KX2hwsTwd3FSqNrq62mKSWjPoNqST5+Po1/zkIQWMfp5 8nC3sQBrhS2deQH2Aet8cZkXutt4HVyShu92b9Q0v/wOdiRsk6nyLRny0zN3mV84VN4TAAAA AAAA --------------ms010905060006070900000106-- --===============1114028361== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --===============1114028361==-- From psamp-bounces@ietf.org Sun Aug 24 04:38:13 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EBD43A6A18; Sun, 24 Aug 2008 04:38:13 -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 27BA03A65A5 for ; Sun, 24 Aug 2008 04:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.034 X-Spam-Level: X-Spam-Status: No, score=-0.034 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_50=0.001] 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 GYkT0mm8vNUy for ; Sun, 24 Aug 2008 04:38:09 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id B10763A6805 for ; Sun, 24 Aug 2008 04:38:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,262,1217822400"; d="scan'208";a="140841259" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 24 Aug 2008 07:38:09 -0400 X-IronPort-AV: E=Sophos;i="4.32,262,1217822400"; d="scan'208";a="265468105" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Aug 2008 07:38:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 24 Aug 2008 13:36:52 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] Netflow/IPFIX workshop: information and request for feedback Thread-Index: AckClBoLkjis1PWCS7uXHoM2ZKJO4gDSYh6g From: "Romascanu, Dan (Dan)" To: Cc: j.schoenwaelder@jacobs-university.de Subject: [PSAMP] FW: [IPFIX] Netflow/IPFIX workshop: information and request for feedback 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Also forwarding to psamp. Dan -----Original Message----- From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Wednesday, August 20, 2008 10:12 AM To: ipfix@ietf.org Cc: nmrg@ibr.cs.tu-bs.de Subject: [IPFIX] Netflow/IPFIX workshop: information and request for feedback Hi, the following Netflow/IPFIX workshop/meeting proposal was sent to the Network Management Research Group (NMRG) mailing list on July 31st. I like to know whether there is support for such an event form the IPFIX community. Please drop a note if you plan to contribute so that I can gauge interest. If you have questions concerning the scope and organization, please contact Ramin Sadre. If the question is of general interest, please keep the NMRG list on CC for now. /js ----- Forwarded message from Ramin Sadre ----- Date: Thu, 31 Jul 2008 17:37:12 +0200 From: Ramin Sadre User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) To: nmrg@ibr.cs.tu-bs.de Subject: [nmrg] Netflow/IPFIX workshop: information and request for feedback Dear list members, (we apologize for multiple postings) as already announced some days ago, the EMANICS network of excellence is currently preparing the EMANICS Workshop on Netflow/IPFIX usage in network management http://www.simpleweb.org/netflow/ The workshop will take place October 30, at the LRZ Munich, Germany. We would highly appreciate your feedback and, of course, your participation. In addition, we kindly ask you to express your opinion on making the workshop a joint Emanics&IRTF-NMRG event. We want the workshop to be an opportunity for people to exchange and discuss their experiences and ideas. To structure the discussions the workshop will be organized into several discussion topics. For each discussion topic, there will be short presentations (5-10 minutes) introducing the topic, followed by a discussion round. Currently, the following topics are planned: 1. "What technologies are available to analyze flow data?" Presentations: * Flow record query languages. * Using SQL databases for flow processing. 2. "What can be expected from distributed analysis techniques?" Presentations: * A distributed architecture for IP flow analysis. 3. "Should we have a standard format for the annotation of Netflow/IPFIX traces?" Presentations: * Labeling flow traces for intrusion detection evaluation. 4. "For what kind of applications can Netflow/IPFIX be used?" Presentations: * Network anomaly characterization using flows. * Application level dependency discovery with flows. * Management of light paths in optical networks using flows. The above list is still preliminary and we welcome your contributions and suggestions. Regards, Ramin Sadre -- !! This message is brought to you via the `nmrg' mailing list. !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust !! your settings, send a mail message to !! or look at https://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. ----- End forwarded message ----- _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp