Subject: [lmap] determining passive vs. active nature of measurement task

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 18 Feb 2014 15:12:41 +0000

Hi Phil,
In the email below (I'm replying using a different subject line for this), you made the following statement
Counter arguments are that it's not necessarily clear cut what's a passive and what's an active Task, and that it adds some complexity to have to classify all tasks as active or passive and to tell the MA this. An active task misconfigured as passive is nasty.
I've been trying to get my head around this statement and have to say that I really don't understand it.
Is there really an intention for "passive" vs. "active" to be a configurable parameter of a Measurement Method or Measurement Task? If so, how would that work? And is there really a set of Measurement Methods whose active/passive nature is ambiguous, unknown, or configurable (per the specification that defines the Measurement Method)? If so, I'd like concrete examples of such Measurement Methods so I can better understand.

For example, let's look at a simple "ping" (I'm using "ping" here to mean a client capability that initiates IPv4 ICMP echo). If a MA tells its Controller that it supports ping (I'm hoping we consider this a possible Measurement Method capability), and the Controller wants to configure this, I wouldn't expect the Controller to be able to configure ping to run in passive mode. It is illogical for ping configuration parameters to include such a configuration option (and I've never seen an implementation that includes such a configuration option). Furthermore, every ping implementation that I've ever seen knows which of its configuration options are mandatory and which are optional, and the correct syntax, in order for it to actually run. For example, it has to have a target IP address or URL. If it is incorrectly configured, this generates an error condition.

An implementation of a Measurement Method in a MA needs to be compliant with whatever spec defines that Measurement Method, and needs to expose configuration parameters consistent with its spec (and perhaps the Registry). If we can't assume compliant Measurement Methods in a MA, then I think the scope of the problem we're trying to solve becomes too huge to solve in the timeframe we've given ourselves. So hopefully we aren't trying to include non-compliant or ill-defined Measurement Method implementations in lmap scope.

Anyway, I look forward to learning about Measurement Methods that allow for active/passive configuration and understanding why they are not resilient when this parameter is configured in a manner inconsistent with the Method's other configuration parameters (i.e., why the Measurement Method is not designed with internal configuration consistency checks).
Barbara

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, February 18, 2014 3:48 AM
To: STARK, BARBARA H; [email-masked]
Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03)

Barbara,
Thanks for the comments.

With these two bullets I was pointing out the implications of the proposed way of not allowing overlapping Tasks (don't start, and never start, a (second) Task if a (first) Task is still on-going).

On your second comment below, I meant something on the lines of your last sentence: understanding the impact of one sort of traffic on another sort. I was just saying that such a test could still be achieved, but would have to be defined as a single test rather than two. I agree this is quite complex - but some people have mentioned a test on these lines

On your first bullet, I have some sympathy with this. It is a technical impact.
Counter arguments are that it's not necessarily clear cut what's a passive and what's an active Task, and that it adds some complexity to have to classify all tasks as active or passive and to tell the MA this. An active task misconfigured as passive is nasty.

Possible approaches are:

-       Leave as original proposal. No overlapping Tasks, therefore passive have to be run at a separate time to active tasks

-       Modify original proposal, so the MA has a list of Tasks and runs through them one a time. Doesn't affect the 2 bullets you mention

-       Allow MA to do what it wants, ie start overlapping Tasks (but record this in the Results). Solves your 2 bullets, but also can have multiple overlapping active tasks

-       Distinguish active and passive tasks. Keep original proposal for active tasks; passive tasks can be run simultaneously.

phil

From: STARK, BARBARA H [mailto:[email-masked]]
Sent: 17 February 2014 13:57
To: Eardley,PL,Philip,TUB8 R; [email-masked]<mailto:[email-masked]>
Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03)

*           Rather than running a Passive Measurement Task continuously in the background, instead it is run when there are no other Tasks operating
<bhs> I think this one item in the proposal is problematic and I don't see a need for it. Lots of devices are continually running passive measurements, and I don't want them to have to turn these off to start an active measurement. I'm also completely at a loss as to what the harm is. For example, in an RG, ADSL line statistics are always being captured, as are Ethernet frames in/out and IP packets in/out. The firewall is logging various messages it sees (and I really don't want to turn that off in order to run an active measurement). There has also been the suggestion that the "responding" end of an active measurement task can simultaneously do passive measurements on the traffic of that active measurement task. IMO, these are 2 separate tasks (though, given the next bullet, we may not have a common definition of Measurement Task, either). Anyway, unless the device is so incredibly processor- or memory-limited that it can't collect passive measurements while doing active measurements (a serious design flaw, IMO, which would make me question this device's ability to even accurately do a single active measurement task), I see no reason to disable any passive measurements while other measurements are occurring. Multiple passive measurements can also run simultaneously. Oh -- and measuring internal processor- and memory-utilization during the running of measurement tasks is also a passive measurement task that I wouldn't want to see disabled.

*           Rather than testing for the impact of cross-traffic by having two Tasks that run simultaneously, instead a single Task generates two types of traffic.
<bhs> This is the point that makes me wonder if we're using the same definition of "Task". Since Measurement Task is an instantiation of a Measurement Method, this would imply that the Measurement Method would have to be defined in a way that allows it to generate all of the needed types of traffic. But the Measurement Methods (and the Registry of Measurement Methods) are being defined external to lmap. This assumption would have the lmap framework imposing requirements on Measurement Methods and the associated Registry in order to run certain tests. That makes me very uneasy.
I'm also not understanding the proposed cross-traffic test, but maybe that's beside the point. I thought cross-traffic was something where we wanted to know whether or not there was any cross traffic present prior to starting certain Active Measurement Tasks, or during an Active Measurement Task (which BTW would require something to do some passive measuring while the Active Measurement Task was happening). Understanding what sort of impact one type of traffic has on the simultaneous running of another type of traffic, from the same MA, strikes me as a rather complex thing to measure, and I'm not sure I want to do much design around that, right now.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 18 Feb 2014 11:40:41 -0500

Hi Barbara,

Briefly, there are Hybrid methods of measurement that combine techniques from
the purely active and passive ends of the continuum.

One such method proposed is to tag user traffic with the usual info found in
active measurement packets, like sequence numbers and/or timestamps.

IPPM has seen proposals in the Hybrid class, and will like discuss one in London.

hope this helps,
Al 
________________________________________
From: lmap [[email-masked]] On Behalf Of STARK, BARBARA H
Sent: Tuesday, February 18, 2014 10:12 AM
To: [email-masked]; [email-masked]
Subject: [lmap] determining passive vs. active nature of measurement task

***Security Advisory: This Message Originated Outside of AT&T ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.

Hi Phil,
In the email below (I’m replying using a different subject line for this), you made the following statement
Counter arguments are that it’s not necessarily clear cut what’s a passive and what’s an active Task, and that it adds some complexity to have to classify all tasks as active or passive and to tell the MA this. An active task misconfigured as passive is nasty.
I’ve been trying to get my head around this statement and have to say that I really don’t understand it.
Is there really an intention for “passive” vs. “active” to be a configurable parameter of a Measurement Method or Measurement Task? If so, how would that work? And is there really a set of Measurement Methods whose active/passive nature is ambiguous, unknown, or configurable (per the specification that defines the Measurement Method)? If so, I’d like concrete examples of such Measurement Methods so I can better understand.

For example, let’s look at a simple “ping” (I’m using “ping” here to mean a client capability that initiates IPv4 ICMP echo). If a MA tells its Controller that it supports ping (I’m hoping we consider this a possible Measurement Method capability), and the Controller wants to configure this, I wouldn’t expect the Controller to be able to configure ping to run in passive mode. It is illogical for ping configuration parameters to include such a configuration option (and I’ve never seen an implementation that includes such a configuration option). Furthermore, every ping implementation that I’ve ever seen knows which of its configuration options are mandatory and which are optional, and the correct syntax, in order for it to actually run. For example, it has to have a target IP address or URL. If it is incorrectly configured, this generates an error condition.

An implementation of a Measurement Method in a MA needs to be compliant with whatever spec defines that Measurement Method, and needs to expose configuration parameters consistent with its spec (and perhaps the Registry). If we can’t assume compliant Measurement Methods in a MA, then I think the scope of the problem we’re trying to solve becomes too huge to solve in the timeframe we’ve given ourselves. So hopefully we aren’t trying to include non-compliant or ill-defined Measurement Method implementations in lmap scope.

Anyway, I look forward to learning about Measurement Methods that allow for active/passive configuration and understanding why they are not resilient when this parameter is configured in a manner inconsistent with the Method’s other configuration parameters (i.e., why the Measurement Method is not designed with internal configuration consistency checks).
Barbara

Barbara,
Thanks for the comments.

With these two bullets I was pointing out the implications of the proposed way of not allowing overlapping Tasks (don’t start, and never start, a (second) Task if a (first) Task is still on-going).

On your second comment below, I meant something on the lines of your last sentence: understanding the impact of one sort of traffic on another sort. I was just saying that such a test could still be achieved, but would have to be defined as a single test rather than two. I agree this is quite complex – but some people have mentioned a test on these lines

On your first bullet, I have some sympathy with this. It is a technical impact.
Counter arguments are that it’s not necessarily clear cut what’s a passive and what’s an active Task, and that it adds some complexity to have to classify all tasks as active or passive and to tell the MA this. An active task misconfigured as passive is nasty.

Possible approaches are:

-       Modify original proposal, so the MA has a list of Tasks and runs through them one a time. Doesn’t affect the 2 bullets you mention

phil

•           Rather than running a Passive Measurement Task continuously in the background, instead it is run when there are no other Tasks operating
<bhs> I think this one item in the proposal is problematic and I don’t see a need for it. Lots of devices are continually running passive measurements, and I don’t want them to have to turn these off to start an active measurement. I’m also completely at a loss as to what the harm is. For example, in an RG, ADSL line statistics are always being captured, as are Ethernet frames in/out and IP packets in/out. The firewall is logging various messages it sees (and I really don’t want to turn that off in order to run an active measurement). There has also been the suggestion that the “responding” end of an active measurement task can simultaneously do passive measurements on the traffic of that active measurement task. IMO, these are 2 separate tasks (though, given the next bullet, we may not have a common definition of Measurement Task, either). Anyway, unless the device is so incredibly processor- or memory-limited that it can’t collect passive measurements while doing active measurements (a serious design flaw, IMO, which would make me question this device’s ability to even accurately do a single active measurement task), I see no reason to disable any passive measurements while other measurements are occurring. Multiple passive measurements can also run simultaneously. Oh -- and measuring internal processor- and memory-utilization during the running of measurement tasks is also a passive measurement task that I wouldn’t want to see disabled.

•           Rather than testing for the impact of cross-traffic by having two Tasks that run simultaneously, instead a single Task generates two types of traffic.
<bhs> This is the point that makes me wonder if we’re using the same definition of “Task”. Since Measurement Task is an instantiation of a Measurement Method, this would imply that the Measurement Method would have to be defined in a way that allows it to generate all of the needed types of traffic. But the Measurement Methods (and the Registry of Measurement Methods) are being defined external to lmap. This assumption would have the lmap framework imposing requirements on Measurement Methods and the associated Registry in order to run certain tests. That makes me very uneasy.
I’m also not understanding the proposed cross-traffic test, but maybe that’s beside the point. I thought cross-traffic was something where we wanted to know whether or not there was any cross traffic present prior to starting certain Active Measurement Tasks, or during an Active Measurement Task (which BTW would require something to do some passive measuring while the Active Measurement Task was happening). Understanding what sort of impact one type of traffic has on the simultaneous running of another type of traffic, from the same MA, strikes me as a rather complex thing to measure, and I’m not sure I want to do much design around that, right now.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 18 Feb 2014 16:56:23 +0000

> Briefly, there are Hybrid methods of measurement that combine techniques
> from the purely active and passive ends of the continuum.
> 

But do implementations of these methods or the specifications describing these methods allow for specific configuration of "active" and "passive", and do they allow for active/passive to be configured in such a way that the method (or a specific task instance of the method) is misconfigured but somehow valid? Do we need to consider a configuration server that configures parameters for one of these methods but doesn't understand the method sufficiently to be able to configure those parameters correctly, as being a good and compliant lmap Controller? Or are the specifications for these methods written in such a way that it is unclear how to configure them correctly, to make them do what is desired of them?

I'm not understanding the use case of a Controller that doesn't know what the Method it is configuring *is*, and how to configure it correctly.
Barbara

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 18 Feb 2014 12:23:28 -0500

It's fair to say that the Controller will know if the requested metric/method is
active or passive, IF we continue with a naming convention that includes this
distinction in the name prefix <link to IPPM registry drafts would be ideal here>.
(In fact, this raises a possible issue in my mind with registry index numbers.
It's just something to check later, if may affect the Information model instead.)

But the future metrics/methods are not decided, and Hybrid metrics/methods
could end-up in their own sub-registry, with a different name prefix, or not.

So the problem is less about distinguishing active from passive, but that there 
are more possibilities than these two and whether all Hybrid should be treated
as active when it comes to "Suppress", and what the Framework draft should 
say now when there are details like this to-be-decided.

Al

________________________________________
From: STARK, BARBARA H
Sent: Tuesday, February 18, 2014 11:56 AM
To: MORTON, ALFRED C (AL); [email-masked]; [email-masked]
Subject: RE: determining passive vs. active nature of measurement task

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 18 Feb 2014 19:17:08 +0000

So here is a suggestion regarding whether or not suppression applies to passive measurements, that I think would provide flexibility.

Suppression ensures no IP packets related to Measurement Tasks are sent out any IP interface. Suppression MAY impact the operation of internal MA processes as well (e.g., passive Measurement Tasks).

This implies it cannot be assumed whether or not passive measurements (or subset of passive measurements) will or won't be impacted by suppression.

If the Controller's entity happens to know (a priori, and not per the Information Model -- e.g., this entity developed, specified, or is otherwise fully familiar with the design of the specific MA) that the MA will or won't impact passive measurements (or certain passive measurements), then this entity can have its Controller issue suppression commands with this knowledge in mind.

If an MA's behavior is unknown, and it's desired to ensure passive measurements are untouched, then the entity's Controller will need to provide a specific list of Measurement Tasks/Schedules/Methods for suppression to apply to.

If an MA's behavior is unknown, and it's desired to ensure passive measurements are stopped or reports do not get generated, then the entity's Controller will need to explicitly stop those passive measurements or disable report channels.

This allows flexibility in MA design (e.g., if a service provider in the UK wants MAs to disable all measurements in reaction to suppression, they can specify their MAs to do that; and if a service provider in the US wants their MAs not to disable passive measurements in reaction to suppression, they can specify their MAs to do that), while ensuring the stated suppression goal of stopping Measurement Task traffic in the network is accomplished.
Barbara

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 18 Feb 2014 20:49:30 +0100

> say now when there are details like this to-be-decided.

I vote for thinking about any mechanisms needed to deal with
overlapping measurement tasks and to stay away from hard coding
any policy.

There may be valid reasons for overlapping active measurements, there
may be valid reasons for enforcing non-overlapping passive measurements.

Lets focus on the mechanism and leave it to deployments to configure a
policy that makes sense.

/js

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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 20 Feb 2014 05:21:52 +0000

+1
Barbara

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> 
> I vote for thinking about any mechanisms needed to deal with overlapping
> measurement tasks and to stay away from hard coding any policy.
> 
> There may be valid reasons for overlapping active measurements, there may
> be valid reasons for enforcing non-overlapping passive measurements.
>

---

From: Brian Trammell <[email-masked]>
Date: Thu, 20 Feb 2014 07:24:19 +0100

+1 as well.

cheers,

Brian

On 20 Feb 2014, at 06:21, STARK, BARBARA H <[email-masked]> wrote:

> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: Brian Trammell <[email-masked]>
Date: Thu, 20 Feb 2014 07:22:37 +0100

+1 as well.

cheers,

Brian

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Thu, 20 Feb 2014 10:43:17 +0000

Also there is the "multi-MA" overlapping test issue that I mentioned earlier.

One way to handle this is "only one  MA" per element - 
Another would be (more complicated) something inter-probe but then we'd have to boil the ocean with all the different existing probe server functions.

My preference is overlapping test avoidance is the Assumption of one MA per device.

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Brian Trammell
Sent: Thursday, February 20, 2014 12:24 AM
To: [email-masked]
Subject: [lmap] Fwd: determining passive vs. active nature of measurement task

+1 as well.

cheers,

Brian

On 20 Feb 2014, at 06:21, STARK, BARBARA H <[email-masked]> wrote:

>> overlapping measurement tasks and to stay away from hard coding any policy.
>> 
>> Lets focus on the mechanism and leave it to deployments to configure 
>> a policy that makes sense.
>> 
>> /js
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 20 Feb 2014 11:49:25 +0100

> My preference is overlapping test avoidance is the Assumption of one MA per device.

This is an implementation issue and the framework should stay silent
about the packaging.

I believe it is possible to build 'elements' or 'devices' (all not
well defined terms anyway) that can host multiple MAs without causing
resource contention as much as I believe it is possible that build
'elements' or 'devices' that host only a single MA that suffers from
resource shortage. The market will sort this out.

/js

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Thu, 20 Feb 2014 11:21:24 +0000

The MA / Probe vendors, and even existing testing standards vendors haven't fixed it by working together or making a overlapping test schema.

We could very easily slightly modify the MA resource check in both the IETF & BBF to look for resource use collision.

The "watch for transit traffic" in-fact suggests avoiding overlapping test collisions.

If we apply the same "collision domain" avoidance principle to the CPU & Memory use we would then create a MA framework that all independent MA's could avoid collisions, much like the same way MAC ports us Collision detection.

Agreeable ?

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, February 20, 2014 4:49 AM
To: Bugenhagen, Michael K
Cc: 'Brian Trammell'; [email-masked]'
Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task

On Thu, Feb 20, 2014 at 10:43:17AM +0000, Bugenhagen, Michael K wrote:
> One way to handle this is "only one  MA" per element - Another would 
> be (more complicated) something inter-probe but then we'd have to boil the ocean with all the different existing probe server functions.
> 

This is an implementation issue and the framework should stay silent about the packaging.

I believe it is possible to build 'elements' or 'devices' (all not well defined terms anyway) that can host multiple MAs without causing resource contention as much as I believe it is possible that build 'elements' or 'devices' that host only a single MA that suffers from resource shortage. The market will sort this out.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 20 Feb 2014 13:28:45 +0100

> If we apply the same "collision domain" avoidance principle to the CPU & Memory use we would then create a MA framework that all independent MA's could avoid collisions, much like the same way MAC…

I can't parse this.

/js

---

From: "Aamer Akhter (aakhter)" <[email-masked]>
Date: Thu, 20 Feb 2014 13:01:44 +0000

Hi Michael,

There are multiple approaches to the problem. In fact this reminds me of the IPSLA group scheduling feature, which is used for more dispersed scheduling to relieve (among other things) local CPU contention.

http://www.cisco.com/c/en/us/td/docs/ios/ipsla/configuration/guide/15_s/sla_15_0s_book/sla_multi_scheduler.html

That said, there may be constraints in the test request itself such that a delayed/early  test is just not acceptable either.

aa

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Bugenhagen, Michael K
Sent: Thursday, February 20, 2014 6:21 AM
To: 'Juergen Schoenwaelder'
Cc: 'Brian Trammell'; [email-masked]'
Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task

Agreeable ?

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Thursday, February 20, 2014 4:49 AM
To: Bugenhagen, Michael K
Cc: 'Brian Trammell'; [email-masked]'
Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task

/js

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Thu, 20 Feb 2014 14:14:47 +0000

Ok.... I'll try to clarify.

A CPU and Memory can both be utilized by different MA's on the same element (so say the vendors I've worked with).
The MA's when running therefore dip from the same resource well, so if either the CPU or the Memory utilization gets to high it the entire system slows down.
So as an abstract concept level - that is a resource pool collision domain.

 If there is a "MIB" that indicates Memory Use, and CPU use... (assumption)

We can create monitoring logic that watches CPU & Memory utilization before a test is conduct (at initiation)
And then perform (during the test) continuous monitoring of CPU / MEM utilization with Threshold crossing event logic
	
 i.e. - ping the CPU / Mem. Utilization every second watching for a Threshold crossing event - which triggers the test to stop and mark test results as invalid.
		In a pyshical appliance this is easy, it's harder in a virtualized probe it's tougher because CPU utilization doesn't reflect congestion directly.

Thanks,
Mike

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, February 20, 2014 6:29 AM
To: Bugenhagen, Michael K
Cc: 'Brian Trammell'; [email-masked]'
Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task

I can't parse this.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 20 Feb 2014 15:26:57 +0100

> 		In a pyshical appliance this is easy, it's harder in a virtualized probe it's tougher because CPU utilization doesn't reflect congestion directly.

So how do I translate all that back into the framework / information
model documents we have? What exact change or addition do you suggest?
Can't this be left to the definition of measurement tasks where this
is relevant? (A traceroute likely is not CPU or memory bound, for
example.) I like to understand what in concrete terms is missing or
unclear in the WG documents.

/js

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Thu, 20 Feb 2014 14:37:59 +0000

I would suggest we add that to the "resource check" functional area for the MA.

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, February 20, 2014 8:27 AM
To: Bugenhagen, Michael K
Cc: 'Brian Trammell'; [email-masked]'
Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task

On Thu, Feb 20, 2014 at 02:14:47PM +0000, Bugenhagen, Michael K wrote:
> We can create monitoring logic that watches CPU & Memory utilization 
> before a test is conduct (at initiation) And then perform (during the 
> test) continuous monitoring of CPU / MEM utilization with Threshold 
> crossing event logic
> 	

So how do I translate all that back into the framework / information model documents we have? What exact change or addition do you suggest?
Can't this be left to the definition of measurement tasks where this is relevant? (A traceroute likely is not CPU or memory bound, for
example.) I like to understand what in concrete terms is missing or unclear in the WG documents.

/js

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Thu, 20 Feb 2014 14:44:02 +0000

Aamer,

   That's pretty cool, I hadn't seen that document approach.

I don't think all the vendors would want to match any specific test lifecycle management schema, originally I hoped that we'd provide them a list of tests with attributes that they could run and the scheduling would be left up to them.

But what I've proposed is for test overlap avoidance between two different schedulers on the same box so although this is a good way to schedule, unless all tests are run under a single MA that won't help.  But this is a nice framework.

Thanks,
Mike

-----Original Message-----
From: Aamer Akhter (aakhter) [mailto:[email-masked]] 
Sent: Thursday, February 20, 2014 7:02 AM
To: Bugenhagen, Michael K; 'Juergen Schoenwaelder'
Cc: 'Brian Trammell'; [email-masked]'
Subject: RE: [lmap] Fwd: determining passive vs. active nature of measurement task

Hi Michael,

aa

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Bugenhagen, Michael K
Sent: Thursday, February 20, 2014 6:21 AM
To: 'Juergen Schoenwaelder'
Cc: 'Brian Trammell'; [email-masked]'
Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task

Agreeable ?

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Thursday, February 20, 2014 4:49 AM
To: Bugenhagen, Michael K
Cc: 'Brian Trammell'; [email-masked]'
Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task

/js

---

From: "Aamer Akhter (aakhter)" <[email-masked]>
Date: Thu, 20 Feb 2014 14:48:21 +0000

Indeed- the group scheduling approach does needs common scheduler :-) 

-----Original Message-----
From: Bugenhagen, Michael K [mailto:[email-masked]] 
Sent: Thursday, February 20, 2014 9:44 AM
To: Aamer Akhter (aakhter); 'Juergen Schoenwaelder'
Cc: 'Brian Trammell'; [email-masked]'
Subject: RE: [lmap] Fwd: determining passive vs. active nature of measurement task

Aamer,

Thanks,
Mike

-----Original Message-----
From: Aamer Akhter (aakhter) [mailto:[email-masked]]
Sent: Thursday, February 20, 2014 7:02 AM
To: Bugenhagen, Michael K; 'Juergen Schoenwaelder'
Cc: 'Brian Trammell'; [email-masked]'
Subject: RE: [lmap] Fwd: determining passive vs. active nature of measurement task

Hi Michael,

aa

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Bugenhagen, Michael K
Sent: Thursday, February 20, 2014 6:21 AM
To: 'Juergen Schoenwaelder'
Cc: 'Brian Trammell'; [email-masked]'
Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task

Agreeable ?

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Thursday, February 20, 2014 4:49 AM
To: Bugenhagen, Michael K
Cc: 'Brian Trammell'; [email-masked]'
Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 20 Feb 2014 15:48:31 +0100

Michael,

what is 'that' and what is the resource check" functional area? Can
you make a concrete text proposal? It helps tremendously in WG
processes if discussions lead at some time to concrete actionable
proposals.

/js

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Thu, 20 Feb 2014 16:12:03 +0000

I will but I'm at a meeting this week so it will be next week some time -

Thanks,
Mike

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, February 20, 2014 8:49 AM
To: Bugenhagen, Michael K
Cc: 'Brian Trammell'; [email-masked]'
Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task

Michael,

what is 'that' and what is the resource check" functional area? Can you make a concrete text proposal? It helps tremendously in WG processes if discussions lead at some time to concrete actionable proposals.

/js

On Thu, Feb 20, 2014 at 02:37:59PM +0000, Bugenhagen, Michael K wrote:
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]

---

From: <[email-masked]>
Date: Fri, 21 Feb 2014 11:51:28 +0000

The current text on "Starting and stopping Measurement Tasks" is in S5.3.
The start of this section says:

The LMAP WG is neutral to what the actual Measurement Task is.  The
   WG does not define a generic start and stop process, since the
   correct approach depend on the particular Measurement Task; the
   details are defined as part of each Measurement Method, and hence
   potentially by the IPPM WG.

I'm sceptical that a memory & cpu check would be needed in practice before every time the MA runs a test. After all, the operator of the measurement system knows the capability of the devices on which it deploys an MA, can do checks in the labs before deployment, and can be cautious about not hitting the device hard. for me, if the resources like cpu and memory run short, then that's a failure condition and not a temporary 'do not run this test at the moment'

Indeed, as S4.2 says
This simplifies the design of MAs (critical for a large-scale
   infrastructure) and allows a Measurement Schedule to be tested on
   specific types of MA before deployment to ensure that the end user
   experience is not impacted (due to CPU, memory or broadband-product
   constraints).

And S5.2.0 (near end) says
The MA can inform the Controller about a Failure.  There are two
   broad categories of failure: ...
(2) the MA cannot execute the Measurement Task or
   deliver the Report (for example, the MA unexpectedly has no spare CPU
   cycles; or the Collector is not responding).  Note that it is not
   considered a failure if a Measurement Task (correctly) doesn't start;
   for example if the MA detects cross-traffic, this is reported to the
   Collector in the normal manner.

Best wishes,
phil 

> Sent: 20 February 2014 16:12
> what is 'that' and what is the resource check" functional area? Can you
> make a concrete text proposal? It helps tremendously in WG processes if
> discussions lead at some time to concrete actionable proposals.
> 
> /js
> 
> > > A CPU and Memory can both be utilized by different MA's on the same
> element (so say the vendors I've worked with).
> > > The MA's when running therefore dip from the same resource well, so
> if either the CPU or the Memory utilization gets to high it the entire
> system slows down.
> > >  i.e. - ping the CPU / Mem. Utilization every second watching for a
> Threshold crossing event - which triggers the test to stop and mark
> test results as invalid.
> > > 		In a pyshical appliance this is easy, it's harder in a
> virtualized probe it's tougher because CPU utilization doesn't reflect
> congestion directly.
> > >
> >