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

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Sun, 23 Apr 2006 14:23:35 +0300

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. Or, in case message sequence numbers are mandatory anyway, why
does Section 4.5 still refer to units of time? 

Dan

> -----Original Message-----
> From: Al Morton [mailto:[email-masked]] 
> Sent: Friday, April 21, 2006 10:05 PM
> To: Wijnen, Bert (Bert); [email-masked]
> 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
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm

---

From: Al Morton <[email-masked]>
Date: Sun, 23 Apr 2006 11:00:31 -0400

Good morning, Dan.

At 07:23 AM 4/23/2006, Romascanu, Dan \(Dan\) wrote:
>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

And as I clarified below, the DstTime parameter is introduced
> > 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

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 24 Apr 2006 14:53:33 -0700

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" <[email-masked]>
> To: "Romascanu, Dan (Dan)" <[email-masked]>; "Wijnen, Bert (Bert)" <[email-masked]>; <[email-masked]>
> Cc: "Mreview (E-mail)" <[email-masked]>
> Sent: Sunday, April 23, 2006 8:00 AM
> Subject: RE: [ippm] Review of: draft-ietf-ippm-reordering-12.txt
>
> Good morning, Dan.
>

---

From: Al Morton <[email-masked]>
Date: Tue, 25 Apr 2006 11:52:58 -0400

IPPM,

After several off-list exchanges with Bert and Dan, we have a better
statement of the issues Bert raised w.r.t. reordering metrics Sec 4.5:

1. Metrics with multiple output parameters are somewhat problematic
for NM systems, and a simple MetricName:value relationship is desired.

If we defined two metrics in Sec 4.5, they could be called:
      Type-P-Packet-Reordering-Gap-Stream
      Type-P-Packet-Reordering-GapTime-Stream
and then we could easily refer to them in the IANA section,
and get a metric number assigned to each one in the registry.

However, I see that we would have to do the same thing in Sec 4.6.
There are four output parameters that we defined, so we would
need a new metric name for each one:
      Type-P-Packet-Reordering-Free-Run-x-numruns-Stream
      Type-P-Packet-Reordering-Free-Run-q-squruns-Stream
      Type-P-Packet-Reordering-Free-Run-p-numpkts-Stream
      Type-P-Packet-Reordering-Free-Run-a-accpkts-Stream

An alternative to adding all these new metric names would
be to simply revise the (new) IANA section to reflect the existence
of output parameters, but this seems less straightforward.

So the current plan is to add the new metric names and corresponding
entries in the IANA section. (Also, it's possible to revise the
text of section 4.5 to make it more clear the GapTime is optional,
and we'll make those changes while in that neighborhood.)

Back to Bert's Issues:
2. When a metric is reported in units of time, it's much easier
to compare the results between systems if the same resolution
is used, and some standard solution should be developed.

My conclusion is that all the "time" metrics in the current
IPPM registry RFC 4148 would not necessarily be reported
with a standard resolution because IPPM has allowed flexibility
in this area (and even the units might differ: seconds vs. millisec).
In order for the registry to be useful, more standardization
is needed, and the need is larger than the reordering draft.
I believe we need an agreement/solution that covers all
our metrics as pertains to their values stored and reported in the
context of the metric registry.

Also, Randy Presuhn observed that we have have not explicitly
specified the units of time in the reordering draft, possibly
because we been using the word "time" synonymously with "seconds".
This is easily corrected in sections 4.3 and 4.5, where we
would specify units of seconds explicitly.

Constructive comments on any of these issues would be welcome.

Al