Re: [ippm] Review of: draft-ietf-ippm-reordering-12.txt

["Randy Presuhn" <randy_presuhn@mindspring.com>]

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).
> > >
> > >
> 
>