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

["Cottrell, Les" <cottrell@SLAC.Stanford.EDU>]

Point 1.  Would appear to be correct, presumably we would need both numPackets and lostPackets. Does numPackets need to be uint32 given that with unint16 one can only measure losses as small as 1/2^16 or an accuracy of .0015% which is achievable on some links today.

Point 2. It appears we already have the median which is a more robust estimator. Average can be easier to deal with mathematically so it may be useful to have both. Maybe median should be mandatory. Also some pings report the standard deviation which is useful to understand the stability. It is also less robust than say the Inter Quartile Range, which is harder to estimate.  I would like to see the standard deviation added as optional.

Point 7. I like the idea of allowing (promoting?) more percentiles. However, I can see long discussions on what the percentiles should be (e.g. uniformly distributed or something like 25%, 75%, 10%, 90%, 5%, 95%, 1%, 99%, and how many should there be). 

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