Re: [ippm] Review of: draft-ietf-ippm-reordering-12.txt
"Randy Presuhn" <randy_presuhn@mindspring.com> Tue, 25 April 2006 12:09 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYMLn-0008DO-Co; Tue, 25 Apr 2006 08:09:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8wF-0007cd-4k for ippm@ietf.org; Mon, 24 Apr 2006 17:49:47 -0400
Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY8wC-0005Bw-PL for ippm@ietf.org; Mon, 24 Apr 2006 17:49:47 -0400
Received: from h-68-166-188-143.snvacaid.dynamic.covad.net ([68.166.188.143] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FY8w7-0003Qz-00; Mon, 24 Apr 2006 17:49:40 -0400
Message-ID: <001a01c667e9$897624e0$6501a8c0@oemcomputer>
From: Randy Presuhn <randy_presuhn@mindspring.com>
To: ippm@ietf.org
References: <AAB4B3D3CF0F454F98272CBE187FDE2F0A5F7370@is0004avexu1.global.avaya.com> <6.2.1.2.0.20060423103143.022fb7c8@postoffice.maillennium.att.com>
Subject: Re: [ippm] Review of: draft-ietf-ippm-reordering-12.txt
Date: Mon, 24 Apr 2006 14:53:33 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 789c141a303c09204b537a4078e2a63f
X-Mailman-Approved-At: Tue, 25 Apr 2006 08:09:02 -0400
Cc: "Mreview (E-mail)" <mreview@ops.ietf.org>
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=subscribe>
Errors-To: ippm-bounces@ietf.org
Hi - I think the question is much simpler. Without getting into the question of accuracy or precision of the measurements, what are the UNITS in which they are reported? Randy ----- Original Message ----- > From: "Al Morton" <acmorton@att.com> > To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>; "Wijnen, Bert (Bert)" <bwijnen@lucent.com>; <ippm@ietf.org> > Cc: "Mreview (E-mail)" <mreview@ops.ietf.org> > Sent: Sunday, April 23, 2006 8:00 AM > Subject: RE: [ippm] Review of: draft-ietf-ippm-reordering-12.txt > > Good morning, Dan. > > At 07:23 AM 4/23/2006, Romascanu, Dan \(Dan\) wrote: > >It is still not clear to me how this would work in the case one entity > >determines gaps in units of time and the other uses message sequence > >numbers. > > As I said below, I don't believe that reporting > *either* Gap or GapTime is possible when claiming compliance. > The text (reproduced below) says "may also" which to me says: > "permission to report GapTime, in addition to Gap". > > So any system claiming compliance with section 4.5 would > report Gaps (based on message numbers), > and Gaps would always be a basis for comparison between compliant > systems. GapTime is optional, Gaps are not. > > >Or, in case message sequence numbers are mandatory anyway, why > >does Section 4.5 still refer to units of time? > > And as I clarified below, the DstTime parameter is introduced > in section 4.3.2, and is mandatory for section 4.5: > > > In the case of the Gap metrics of Section 4.5, all the > > > parameters necessary to compute the Gap (in units of msg > > > numbers) and GapTime (in units of time) are mandatory, > > > inherited from earlier metrics (as 4.5.2 states). > > Finally, (in response to your earlier message) > time stamp resolution is an implementation detail > here in IPPM, unless you claim compliance with the active > measurement protocol. Using different Timestamp resolutions certainly > affects the degree to which the results can be compared, but > that's just one of the possible errors and uncertainties, > and it doesn't make comparison impossible. > > hope this helps, > Al > > > > >Dan > > > > > > > > > > > > > -----Original Message----- > > > From: Al Morton [mailto:acmorton@att.com] > > > Sent: Friday, April 21, 2006 10:05 PM > > > To: Wijnen, Bert (Bert); ippm@ietf.org > > > Cc: Romascanu, Dan (Dan); Mreview (E-mail) > > > Subject: Re: [ippm] Review of: draft-ietf-ippm-reordering-12.txt > > > > > > Hi Bert, > > > > > > Thanks for your review and questions. > > > Please see my take on the answers, below. > > > hope this helps, > > > Al > > > > > > At 05:55 AM 4/21/2006, Wijnen, Bert (Bert) wrote: > > > >... > > > >Looks pretty good. > > > > > > > >I have one question that maybe the authors or other WG members can > > > >answer for me and that is: > > > > > > > > In section 4.5, it seems to allow for using msg sequence > > > numbers OR > > > > units of time (without even having defined what the unit is). > > > > > > > >So I wonder how this definitions specifies an exact metric. > > > The metric > > > >would not be comparable from one to the other measurement if one of > > > >them uses msg sequence numbers, while the other uses "units > > > of time". > > > >Even if two of them use "units of time" but different units > > > (e.g. micro > > > >seconds vs > > > >milliseconds) > > > >even then they would not be comparable. > > > > > > I'll tackle the issue of different time resolutions below. > > > > > > In the case of the Gap metrics of Section 4.5, all the > > > parameters necessary to compute the Gap (in units of msg > > > numbers) and GapTime (in units of time) are mandatory, > > > inherited from earlier metrics (as 4.5.2 states). > > > > > > If one reports a metric from this section, then the Gap > > > metric is mandatory, while the GapTime is optional: > > > > > > "Gaps may also be expressed in time:" (equation follows) > > > > > > So, I don't think we should run into a problem when two > > > different testers report metrics that are compliant with > > > section 4.5. They should be able to compare the Gap (msg > > > number-based) metric, at least. > > > > > > > > > >Was it not the goal of IPPM to define EXACT metrics, so that > > > results of > > > >two different tests/measurments could be compared? > > > > > > None of the current IPPM metric RFCs mandate a resolution for > > > time stamps. > > > The IPPM Framework RFC 2330 treats Clock Issues in Section > > > 10, and simply defines the term "resolution" as "the smallest > > > unit by which the clock's time is updated." > > > > > > The One-way Delay RFC 2679 even allows for different > > > resolutions to be used on the Source and Destination clocks > > > (from 3.7.1): > > > > + The resolution of a clock adds to uncertainty about any time > > > > measured with it. Thus, if the source clock has a > > > resolution of > > > > 10 msec, then this adds 10 msec of uncertainty to any > > > time value > > > > measured with it. We will denote the resolution of the source > > > > clock and the destination clock as Rsource and Rdest, > > > > respectively. > > > > > > So, I believe we have specified the metric definitions > > > "exactly", or without ambiguity. But the degree to which > > > measurements from different implementations will be > > > comparable depends on the details of each implementation, > > > including the time stamp resolution and other sources of > > > error or uncertainty (such as time accuracy and skew). > > > > > > > > _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm
- [ippm] Review of: draft-ietf-ippm-reordering-12.t… Wijnen, Bert (Bert)
- Re: [ippm] Review of: draft-ietf-ippm-reordering-… Al Morton
- Re: [ippm] Review of: draft-ietf-ippm-reordering-… Mark Allman
- Re: [ippm] Review of: draft-ietf-ippm-reordering-… Al Morton
- Re: [ippm] Review of: draft-ietf-ippm-reordering-… Mark Allman
- RE: [ippm] Review of: draft-ietf-ippm-reordering-… Romascanu, Dan (Dan)
- RE: [ippm] Review of: draft-ietf-ippm-reordering-… Romascanu, Dan (Dan)
- RE: [ippm] Review of: draft-ietf-ippm-reordering-… Al Morton
- Re: [ippm] Review of: draft-ietf-ippm-reordering-… Randy Presuhn
- RE: [ippm] Review of: draft-ietf-ippm-reordering-… Al Morton
- RE: [ippm] Review of: draft-ietf-ippm-reordering-… Wijnen, Bert (Bert)