[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposed addition to path.bandwidth.capacity event




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

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.