I had to suss out from Jin that this in fact will work. For the case of Netest, the method will either be through 'packet train dispersion' or 'statistical estimation'
I agree that it's definitely important to represent how such an observation was made. But I'm not sure a new property needs to be proposed for this. For example, why not just use the "measurementMethod?"
Also, consider all of the additional parameters added to that first example of path.delay.roundTrip and consider producing something like "nettestMethod" or "nettestOptions".I agree. With remote measurements as netest is making, even the most exacting measurement of some metric degeneates down to an estimation if you go far down enough into the implementation. Jin would argue otherwise ;}
Measured/Estimated is, in particular, one of those ideas that is hard to interpret, in general. One person's measurement is another person's estimation. For example, I would argue that unless you have direct SNMP access to each of the switches along a path, you probably only have an estimate.
Bruce
--On Wednesday, May 07, 2003 01:29:20 PM -0700 "Martin C. Stoufer" <mcstoufer@lbl.gov> wrote:
During the current development cycle of Netest (http://www- didc.lbl.gov/NCS/netest), Jin is now able to calculate the bandwidth capacity by two different means. The first is a direct observation of network characteristics, the second is an approximation from measurement frequencies and statistical inferrences. I noticed that our current enumeration of properties for this event does not take into account how the value was derived. I think this is just as important as to how the value was measured. To put it out for discussion, would it be useful to incorporate another property to enumerate this? I.e., ValueDerivationMethod = {Measured|Estimated} It is not clear to me now wheather or not this can be utilized in other event's property lists. -Martin S.
-- * Martin C. Stoufer * * DIDC/DSD/ITG * * Lawrence Berkeley National Lab * * MS 50B-2215 510-486-8662 *