Subject: Re: [lmap] Defining Status and Logging (Capabilities and Failure)

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 2 Dec 2013 14:17:28 +0100

Steve,

my point was to take some details out of the information model - I did
not mean to say any of the currently listed state in the information
model is not useful. In fact, I believe there is even more stuff that
can be useful for certain measurements. My point was that if we make
state reporting to support data analysis a measurement task, then we
do not have to detail this state information in the information model
and we can leave it to a state reporting measurement task definition.

The thing I am less clear about is the information needed by the
controller to do its job. I prefer that we do not require or assume
any complex measurement task specific logic in the controller in order
to set parameters for the measurement tasks. I prefer that measurement
tasks are smart enough to understand their environment and to generate
warnings/errors where appropriate or to adapt where possible.

/js

On Sat, Nov 30, 2013 at 05:22:00PM -0500, Steven Miller wrote:
>    FWIW I like the idea that feeding operational state back is just
> another measurement task.  The stuff in the current I-D does seem
> like a long list, though as I read it with an eye to things I
> thought could easily be thrown out, I found myself thinking that
> most or all of that is stuff I'd like to have available if I was
> trying to figure out after the fact why something had started
> performing poorly.  For example, knowing the gateway that was in use
> at a time more-or-less around when a given measurement started
> reporting poor results might let me cross-correlate that back to a
> device for which I have some other failure information, a la "oh,
> that was this router, yeah, there was a device-down alert for that
> at the same time, that explains it."
> 
>     -Steve
> 
> On 11/29/2013 7:01 AM, Juergen Schoenwaelder wrote:
> >On Fri, Nov 29, 2013 at 10:56:05AM +0000, [email-masked] wrote:
> >>Yes, it's always possible to report info to the Collector and from there (via an out-of-scope mechanism) to the Controller. The example we gave was the results of one test leading to some follow-up tests. Maybe this type of interaction should be assumed where we have to analyse the results before deciding what Task to do next - if you're trying to diagnose a fault.
> >>Whereas if you're trying to decide how big a file to use for your download speed test, that depends on operational state (the interface speed)
> >You can design this into the test itself by making the test adapt to
> >the interface speed and perhaps also at the statistical properties of
> >the download, e.g. you request a big file but abort the transfer once
> >you have sufficient data received. The more self-contained tests can
> >be, the less the controller needs to understand about every test,
> >which leads to a great simplification overall.
> >>The info model has lots of optional stuff concerning operational state. Who decides what's sent? Does the Controller's Request-for-operational-info include the list of things it wants to learn? Or not - and then does the MA reply with all Operational-info? Everything that's changed since it last sent? Any operational-info at its choice?
> >>Do we allow extensibility? Ie can the operator of the measurement system include its own additional operational-info fields? If yes, how?
> >>
> >>My guesses would be:
> >>Request-for-operational-info(list) or (all)
> >>Can define own operator /vendor specific fields
> >I think it is fair to assume that there is a mechanism that allows a
> >controller to select the operational state it is interested
> >in. Whether there is an "everything since last time" filter, I do not
> >know - this requires some state to be kept on the device. And yes, I
> >believe operational state needs to be extensible and hence I suggested
> >to actually reduce stuff we currently have in the information model so
> >that we do not spend lots of time discussing what operational state
> >might all be useful (since this depends to a large extend on the tests
> >you are running).
> >
> >/js
> >
> 
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>