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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 21 Apr 2006 11:55:24 +0200

Dan Romascanu (new OPS AD) asked on MIB Doctors list for review
of this document, since it is on IESG agenda for April 27th.

So I reviewed the document.

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.

Was it not the goal of IPPM to define EXACT metrics, so that results of
two different tests/measurments could be compared?

Bert

_______________________________________________
ippm mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm

---

From: Al Morton <[email-masked]>
Date: Fri, 21 Apr 2006 15:04:32 -0400

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

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.

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

---

From: Mark Allman <[email-masked]>
Date: Fri, 21 Apr 2006 16:21:09 -0400

> two different tests/measurments could be compared?

I thought we agree to get rid of the "units of time" notion in that it
makes it either damn hard or impossible for the receiver to know what is
expected (as opposed to a sequence number, which makes it trivial).

allman

---

From: Al Morton <[email-masked]>
Date: Sat, 22 Apr 2006 01:01:22 -0400

>expected (as opposed to a sequence number, which makes it trivial).

Yes, but your comments on this applied to section 3.

We use the message number in the reordering singleton definition.
We also agreed to keep SrcTime as a mandatory parameter, and mention
time and bytes only as secondary means to determine order.
When we discussed this in Minneapolis last year, you came to the
mic to agree with this, even where we did not implement your
comments verbatim (as with the SrcTime parameter).
A summary of comments and responses is here:
http://www3.ietf.org/proceedings/05mar/slides/ippm-1.pdf

We're discussing a later section here (4.5), and you expressed no objections
about using time to quantify the extent of reordering, AFAIK.

Al

---

From: Mark Allman <[email-masked]>
Date: Sat, 22 Apr 2006 15:46:33 -0400

Al-

> We use the message number in the reordering singleton definition.  We
> also agreed to keep SrcTime as a mandatory parameter, and mention time
> and bytes only as secondary means to determine order.  When we
> discussed this in Minneapolis last year, you came to the mic to agree
> with this, even where we did not implement your comments verbatim (as
> with the SrcTime parameter).  A summary of comments and responses is
> here: http://www3.ietf.org/proceedings/05mar/slides/ippm-1.pdf
> 
> We're discussing a later section here (4.5), and you expressed no
> objections about using time to quantify the extent of reordering,
> AFAIK.

Doh!  This is what I get for not going back and looking at the draft.
You're right that my objection was in terms of determining the
out-of-orderness and not determining the extent or the characteristics
this dynamic created.  I do support the use of time for characterizing
reordering events, just not for determining the event.  But, somehow I
misread the context of Bert's note.  In any case, sorry for the spurious
chud.  I'll shut up now! :)

allman