RE: reminder: NM WG call this Wednesday, 8am PDT

["Andrea Westerinen" <andreaw@cisco.com>]

One quick point on #4, CIM distinguishes an endpoint/interface as IPv4,
v6 or both.  Both address formats can be provided for an interface.  I
think that this falls out of the schema-tization of the profile.

Andrea   

-----Original Message-----
From: Jeff W. Boote [mailto:boote@internet2.edu] 
Sent: Tuesday, May 13, 2003 8:25 AM
To: Brian Tierney
Cc: nm-wg@ggf.org
Subject: Re: reminder: NM WG call this Wednesday, 8am PDT


Brian Tierney wrote:
> continued discussion of network profile doc.
>     http://www-didc.lbl.gov/NMWG/NMWG-profile.html

I hope email comments are ok too...

I've been implementing a measurement infrastructure for collecting
one-way delay on the Abilene network recently. Based on my experiences
there, I have a few comments.

1. I don't see anywhere in path.loss.* a property for the actual number
of lost packets. I believe it is useful for applications to be able to
retrieve this value directly. (The "tool" being used to create the
"average packet loss" value almost certainly knows this value.) If
numPackets is large enough, providing the loss as only a percent can be
fairly meaningless, especially if it is defined as a uint16.

2. For path.delay.roundTrip: Do you really want to use the "average" as
the value? That is a rather poor predictor of performance. (You can have
a single outlier skew the entire sample.)

3. I would be tempted to make "priority" a uint32 so that it can map to
the flow label in IPv6.

4. And speaking of IPv6, I don't see a Protocol property. (I suppose it
could be done within the packetType property since that is a string...
But I would imagine most people would want to limit the number of
possible values that could be placed in the "string" properties so they
remain meaningful to applications.)

5. path.delay.*.accuracy: I believe % error could be very misleading
here. Most measurement methodologies will have a fairly small reasonably
fixed error. Therefore reporting this as a percent can be problematic.
Is it % error from the min? med? max? Consider the case when the min and
max differ by orders of magnitude. I believe accuracy should be a fixed
time interval value.

- Actually, I just spotted timeAccuracy. Can someone explain why there
are two accuracy related properties and what they are used for? Perhaps
I just don't understand the intent of the above property?

6. path.delay.*.[min|med|max]: Is there a special value to indicate
infinity? What if there is 100% packet loss?

7. path.delay.*.percentile: I'm glad this is in here... But I wonder if
it could be done in a way that multiple percentiles could be presented?
(Or perhaps that would just be up to the applications using this schema
to communicate what they would like in "percentile Value"?) If even as
few as 10 values were here, it would be possible to create a fairly
reasonable CDF plot of the delays.

jeff