Subject: [lmap] Information Model - Reporting Task collisions/interference

From: <[email-masked]>
Date: Thu, 13 Mar 2014 09:36:00 +0000

At IETF 89 we also discussed the requirement to be able to report if a Measurement Task may have conflicted with another Task. While this could be as simple as a Boolean in the Report for each Task, we could potentially consider something more complicated. Since a Boolean would not tell us which Tasks were operating concurrently and whether there might be cause for concern (e.g. it could be a permanently running error reporting task or a passive analysis task).

Therefore it seems likely that we want to discuss two approaches:
1) listing the Tasks that overlapped with the execution of the reporting Task. Simple conceptually and gives the most information to the person/system analysing results.
2) Attempt to classify Tasks by their potential conflict and report a conflict level. E.g. colliding with a passive tasks might be conflict level 1, but colliding with a TCP throughput test might be conflict level 5. Personally I'd be very much against such an approach as (a) I don't want to classify Tasks and (b) It's not really possible to give a general conflict rating to a Task since it will affect different other Tasks to different levels.

So do people think 1) is the way forward? Shall we add "Conflicting Tasks" (as a List of Task Names) to the Task header information in the Report?

Trevor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Mar 2014 10:39:47 +0100

> So do people think 1) is the way forward? Shall we add "Conflicting Tasks" (as a List of Task Names) to the Task header information in the Report?

I agree that 2) is wishful thinking. I am also concerned to add noise
to every report in cases where it is not needed. So this conflict
report should be optional so that in cases where this is really not
needed, you can save the noise in the report channel.

/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: Sharam Hakimi <[email-masked]>
Date: Thu, 13 Mar 2014 13:58:23 +0000

Sorry, I should have put the collision comment in this thread.

The collision problem is another issue. I thought there was agreement for an MA to execute tasks sequentially and there should only be a single active task or task list. That would ensure that there are no collisions. There could be many task lists stored in the MA but only one would be active at any one time. This is all under the control of one MC.

//SH

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, March 13, 2014 5:40 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [lmap] Information Model - Reporting Task collisions/interference

/js

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

---

From: <[email-masked]>
Date: Thu, 13 Mar 2014 14:38:38 +0000

We're talking about the framework decision here (rather than Information Model), but no. The decision discussed was to allow Tasks to conflict/overlap if they are scheduled as such. Within a single schedule they are non-overlapping.

Trevor.

>From: Sharam Hakimi [mailto:[email-masked]]
>Sent: 13 March 2014 13:58
>To: Burbridge,T,Trevor,TUB8 R
>Cc: [email-masked]; Eardley,PL,Philip,TUB8 R; [email-masked]
>Subject: RE: [lmap] Information Model - Reporting Task collisions/interference
>
>The collision problem is another issue. I thought there was agreement for an MA
>to execute tasks sequentially and there should only be a single active task or task
>list. That would ensure that there are no collisions. There could be many task lists
>stored in the MA but only one would be active at any one time. This is all under
>the control of one MC.
>
>//SH
>
>
>
>> At IETF 89 we also discussed the requirement to be able to report if a
>Measurement Task may have conflicted with another Task. While this could be as
>simple as a Boolean in the Report for each Task, we could potentially consider
>something more complicated. Since a Boolean would not tell us which Tasks were
>operating concurrently and whether there might be cause for concern (e.g. it
>could be a permanently running error reporting task or a passive analysis task).
>>
>> 1) listing the Tasks that overlapped with the execution of the reporting Task.
>Simple conceptually and gives the most information to the person/system
>analysing results.
>> 2) Attempt to classify Tasks by their potential conflict and report a conflict level.
>E.g. colliding with a passive tasks might be conflict level 1, but colliding with a
>TCP throughput test might be conflict level 5. Personally I'd be very much against
>such an approach as (a) I don't want to classify Tasks and (b) It's not really
>possible to give a general conflict rating to a Task since it will affect different
>other Tasks to different levels.
>>
>> So do people think 1) is the way forward? Shall we add "Conflicting Tasks" (as a
>List of Task Names) to the Task header information in the Report?
>>
>
>I agree that 2) is wishful thinking. I am also concerned to add noise to every
>report in cases where it is not needed. So this conflict report should be optional
>so that in cases where this is really not needed, you can save the noise in the
>report channel.
>
>/js
>
>--

---

From: Sharam Hakimi <[email-masked]>
Date: Thu, 13 Mar 2014 16:36:50 +0000

Option 2 is really not workable in my opinion not only one has know the conflict level, but say running Two level 3 tasks would not have a problem if they conflicted but running three level 3 will oversubscribe the network. The possibilities are numerous where the MA must have extensive knowledge of not only the conflict level but the interface that is using to effectively identify a conflict. If conflicts are generated where it does not matter then to much unnecessary conflict alarms are raised cluttering the reports as it was mentioned below.

/Sharam 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, March 13, 2014 10:39 AM
To: Sharam Hakimi
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [lmap] Information Model - Reporting Task collisions/interference

Trevor.