Subject: WG input needed on "Periodic Streams"

From: "Will E. Leland" <[email-masked]>
Date: Fri, 17 Mar 2000 13:55:57 -0500 (EST)

As Chairs, we need discussion and insight from the IPPM list on the
new I-D on periodic streams. We do not want to encourage a wide range
of specific (and not widely useful) metrics, but rather a small set
of generally useful metrics.  We think the current draft represents
a class of traffic not well captured by the existing metrics.  However,
we seek your input.

The key questions for the working group are:

1) Is this an area in which a metric would be useful?
   This draft represents the convergence of two independent proposals,
   which leads us to believe there's a good chance the metric would
   be used.  While the previous metrics have stressed Poisson traffic
   to avoid synchronizing with network activity, this draft seems to
   present a well-motivated reason to use periodic streams that is
   potentially important to a significant class of applications.

2) Is the proposed metric itself well-defined and useful?
    Does it give the right information to be useful for these streams?
    Are there better alternatives?

3) If the class of stream is important and the proposed metric useful,
    how should the draft be improved?  One specific concern we have already
    forwarded to the authors is that the metric can be better mapped
    to the IPPM metric framework.  In particular, the progression between
    singleton to sample is muddied here.

If we do not see some interest from the Working Group, we'll view that
as a clear statement that this metric is not needed.

-- Will & Matt

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Mon, 27 Mar 2000 04:45:46 +0200 (CEST)

>     Are there better alternatives?

I find these questions hard, if not impossible to answer from just the
current draft. Before finalizing the draft, I think that there should be
at least a preliminary implementation plus some practical experience to
show that this actually measures something useful.

Then, paragraphs 4.2.1 to 4.2.4 confuse me: If I understand it correctly,
the metric itself consists of global definitions (4.2.1) and (4.2.4). To
extract the data one has to do measurements at SRC and DST (4.2.2 and
4.2.3).  Wouldn't it make more sense to define the submetrics first, then
merge 4.2.1 and 4.2.4 into 1, with some discussion on how to get there
from the indivisual measurements?

Finally, there is no paragrpaph 4.3 in the draft, is this correct?

2 minor comments:

4.5  5th + sign ("Depending on..")
    I think the choice of GPS or NTP is an implementation detail. The
    metric should be reported with an experimental error, and this will
    be larger for a setup with just NTP. It's up to the user to determine
    if the error is still acceptable.

4.7.3.  Shouldn't the + signs be +/- ? (in reported value is true value
    +/- random error).  If one can deterimen the random error, it's not
random anymore.

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                    Email: [email-masked]
RIPE Network Coordination Centre     WWW: http://www.ripe.net/home/henk
Singel 258                         Phone: +31.20.535-4414,  Fax -4445
1016 AB Amsterdam                   Home: +31.20.4195305
The Netherlands                   Mobile: +31.6.55861746  
------------------------------------------------------------------------------

The Committee (...) was unable to reach a consensus that substantial merit was
lacking. Thus, the appeal was deemed meritorious.          (Orlando NABC #19).

---

From: "Matthew J Zekauskas" <[email-masked]>
Date: Mon, 27 Mar 2000 04:50:04 -0500

I'll tackle the nits, because they derive from the delay & loss RFCs.

>     if the error is still acceptable.

You are correct, in that the metric should be reported with the
experimental error, and if NTP yeilds satisfactory results, that's
fine.  This bullet just warns that NTP may not be what you want
to use if delay values are small.

It also states that no one has yet tried this out.  That is still true,
at least for any documented cases, to my knowledge (if someone has tried
it and documented the results, speak up!).  I personally have played
with NTP in a setting, but there were other problems (the particular
path had lots of guaranteed jitter) so I couldn't disambiguate the
contribution due to NTP; and so I can't say how useful it is.

I also know of another group that was testing NTP (unfortunately, I
don't believe anything was published), but decided that they needed
the improved accuracy of GPS for their application.

I believe this text is taken directly from the other RFCs; I have no
objection to modifying it.

>     +/- random error).  If one can deterimen the random error, it's not

This too was taken from the other RFCs.  The + signs just indicate
that the components are additive.  The "random error" might be positive
or negative for any given singleton in the sample.

--Matt