Subject: Re: [lmap] Information Model: Connecting Tasks

From: <[email-masked]>
Date: Wed, 15 Oct 2014 14:32:35 +0100

During Dublin we debated (but didn't come to a strong conclusion on) two key topics. This is the second of those topics.

We currently allow Task outputs to be directed to other Tasks. There is a mistake in the current draft but conceptually the way it should have been expressed was that the output of a Scheduled Task can be directed to another Scheduled Task. This is achieved by specifying the destination Scheduled Task as part of the origin Scheduled Task. We've gone through a few tweaks around this theme and people still find it hard to understand.

Therefore an option was put on the table to make the concept of queues between Scheduled Tasks explicit. A Scheduled Task would output to a queue. Another Scheduled Task would input from a queue.

The advantage was debated to be:

-        Guides implementation

-        Queue object now or in future can have parameters defining its behaviour (e.g. maximum size, drop oldest or latest data when full etc.). Even if such parameters were not desired today the queue object would enable such parameters to be added in future

It would be good to repeat the debate and get comments from others who weren't in Dublin.

Trevor.

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Wed, 15 Oct 2014 21:48:07 +0000

Trevor,

Again - I believe you were seeking a wider audience viewpoint but..
In Dublin - I believe I expressed that I didn't think queues were necessary. It seems abit over-engineered.
I know from a TR-069 data model standpoint I have been able to model the Scheduled task that is simply directed to another task as you suggested.

BR,
Tim

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, October 15, 2014 8:33 AM
To: [email-masked]
Subject: Re: [lmap] Information Model: Connecting Tasks

-          Guides implementation

Trevor.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 15 Oct 2014 18:54:48 -0400

One case to consider, a measurement task completes but for some reason
the reporting task has not been received yet. Queuing the measurement result
would potentially save it for later, when the reporting task appears.

I also agree with Trevor's point that it guides implementation,
but I'm not married to an explicit queue. There has to be storage
when the reporting task takes place sometime after measurement.

Regards,
Al

________________________________________
From: lmap [[email-masked]] On Behalf Of Carey, Timothy (Timothy) [[email-masked]]
Sent: Wednesday, October 15, 2014 5:48 PM
To: [email-masked]; [email-masked]
Subject: Re: [lmap] Information Model: Connecting Tasks

Trevor,

Again – I believe you were seeking a wider audience viewpoint but..
In Dublin – I believe I expressed that I didn’t think queues were necessary. It seems abit over-engineered.
I know from a TR-069 data model standpoint I have been able to model the Scheduled task that is simply directed to another task as you suggested.

BR,
Tim

During Dublin we debated (but didn’t come to a strong conclusion on) two key topics. This is the second of those topics.

We currently allow Task outputs to be directed to other Tasks. There is a mistake in the current draft but conceptually the way it should have been expressed was that the output of a Scheduled Task can be directed to another Scheduled Task. This is achieved by specifying the destination Scheduled Task as part of the origin Scheduled Task. We’ve gone through a few tweaks around this theme and people still find it hard to understand.

-          Guides implementation

It would be good to repeat the debate and get comments from others who weren’t in Dublin.

Trevor.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Oct 2014 10:44:39 +0200

On Wed, Oct 15, 2014 at 09:48:07PM +0000, Carey, Timothy (Timothy) wrote:
> In Dublin - I believe I expressed that I didn't think queues were
> necessary. It seems abit over-engineered.  I know from a TR-069 data
> model standpoint I have been able to model the Scheduled task that
> is simply directed to another task as you suggested.

Timothy,

while you can hide the queues in the information model, they will
exist in implementations and they will have impact on how an
implementation behaves. If a measurement task produces data faster
than say a reporting task picks it up, then at some time something
happens, e.g., the measurement task gets blocked or data is getting
dropped (either new incoming data, or old data purged, or something
random). Even if we decide that we do not want to go into defining
different queues and their behaviour today (which may be reasonable in
order to get a first version finished and implementation experience),
we may want implementations to report queue specific statistics
(e.g. a drop rate) and we may want future version of LMAP to provide
more details for configuring the behavior of the queues. By making
queues first class citizens now, we are open to such future LMAP
extensions and we allow implementations to provide proprietary
extensions for example to report queue statistics even now.

The only technical concern I have heard is that the current
information model does by design now allow to have multiple consumers
of data. If this restriction is desirable, I am sure we can also have
it with explicit queues.

/js (sorry for repeating my proposal once more ;-)

-- 
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: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Fri, 17 Oct 2014 21:56:42 +0000

Juergen,

If you make queues part of the information model then we will require that the scheduling be done via a queue interface as the information element is part of the specification. I just wanted to avoid over engineering at this point.

As to the technical concern: The only technical concern I have heard is that the current information model does by design now allow to have multiple consumers of data. I guess if you provide abit more explanation as to what you are asking for here. 

As I understand the model, A scheduled task has a list of Downstream tasks. An instance of a Downstream task has a filter based on the Output selections - multiple Downstream tasks can have the same output selection as far as I understand it. A downstream task is also associated with one or more other Tasks that is the object of the downstream tasks. 

So multiple consumers (tasks that objects of a downstream task) of data (output selection of the scheduled task) is possible. Did I misunderstand something?

Thanks,
Tim

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, October 17, 2014 3:45 AM
To: Carey, Timothy (Timothy)
Cc: [email-masked]; [email-masked]
Subject: Re: [lmap] Information Model: Connecting Tasks

On Wed, Oct 15, 2014 at 09:48:07PM +0000, Carey, Timothy (Timothy) wrote:
> model standpoint I have been able to model the Scheduled task that is 
> simply directed to another task as you suggested.

Timothy,

while you can hide the queues in the information model, they will exist in implementations and they will have impact on how an implementation behaves. If a measurement task produces data faster than say a reporting task picks it up, then at some time something happens, e.g., the measurement task gets blocked or data is getting dropped (either new incoming data, or old data purged, or something random). Even if we decide that we do not want to go into defining different queues and their behaviour today (which may be reasonable in order to get a first version finished and implementation experience), we may want implementations to report queue specific statistics (e.g. a drop rate) and we may want future version of LMAP to provide more details for configuring the behavior of the queues. By making queues first class citizens now, we are open to such future LMAP extensions and we allow implementations to provide proprietary extensions for example to report queue statistics even now.

The only technical concern I have heard is that the current information model does by design now allow to have multiple consumers of data. If this restriction is desirable, I am sure we can also have it with explicit queues.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Oct 2014 08:36:13 +0200

> If you make queues part of the information model then we will require that the scheduling be done via a queue interface as the information element is part of the specification. I just wanted to avo…

I do not understand this.
 
> As to the technical concern: The only technical concern I have heard is that the current information model does by design now allow to have multiple consumers of data. I guess if you provide abit m…

Please read my previous post. My motivation is now what you claim.

/js

---

From: Arne Oslebo <[email-masked]>
Date: Mon, 20 Oct 2014 20:20:28 +0200

I agree with Timothy and would prefer not to include anything about
queues in the information model. If we need to define queuing behavior
then I think it is better done as part of the task definition. Queuing
requirements for logging and reporting might be different. This will
also make it easier for people who do not agree with the standardized
queuing behavior to come up with their own solutions.

Arne

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Oct 2014 22:16:42 +0200

> queuing behavior to come up with their own solutions.

Are you saying that every output channel of every task should have an
independent queue but we better don't say so because being silent
about queues allows everybody to implement what they like? I fail to
see how we will get robust interoperable behaviour by leaving this
completely open to interpretation and implementation choice. By robust
I mean implementations that still behave in a predictable way in case
of resource shortage (e.g. memory) or malfunctioning tasks in a chain
of tasks (which may eventually lead to resource shortage).

/js

---

From: Arne Oslebo <[email-masked]>
Date: Tue, 21 Oct 2014 09:14:39 +0200

On 20. okt. 2014 22:16, Juergen Schoenwaelder wrote:
> independent queue 
No, I'm saying that tasks that need it can have an input queue.
> but we better don't say so because being silent
I don't disagree that it can be good to standardize the queuing
behavior, but  I do not think it belongs in the information model. It
has already been mentioned that we need a repository of common tasks
like logging and reporting, and I think it's better to define the
queuing behavior when we define these tasks.

Arne

---

From: Arne Oslebo <[email-masked]>
Date: Tue, 21 Oct 2014 09:17:22 +0200

On 20. okt. 2014 23:22, MORTON, ALFRED C (AL) wrote:
> From: lmap [[email-masked]] On Behalf Of Juergen Schoenwaelder [[email-masked]]
> Sent: Monday, October 20, 2014 4:16 PM
> To: Arne Oslebo
> Cc: [email-masked]
> ACM:
> +1, the need for queuing output between schedule events seems rather obvious.
> Clarity and consistency can be achieved if we embrace the concept, we can 
> still stop short of requirements for the size of the queue, etc. allowing
> vendors to provide their size of choice.
It might be obvious that we need queuing, but I do not think it is
obvious what kind of queuing mechanism we need. I think it is a bad idea
to introduce a common queuing element in the information model that
forces us to implement a specific queuing mechanism for all types of
tasks. For logging it might be good to have some kind of priority based
queue so that errors have a higher priority than warning or
informational messages, but for reporting a normal FIFO might be best.
That is why I would prefer to standardize queuing behavior as part of
the task definition and not in the information model.

Arne

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 21 Oct 2014 09:00:19 -0400

Hi Arne,

There's a misunderstanding somewhere between:

Al wrote:
> still stop short of requirements for the size of the queue, etc. ...

Arne wrote:
...I think it is a bad idea
to introduce a common queuing element in the information model that
forces us to implement a specific queuing mechanism for all types of
tasks.

----

I agree that queue design and feature specifics could be part of the task definition.
The queue in the Information Model is abstract, the same way tasks are abstract.
Implementors will have freedom until they choose a task to build.

Can you live with the abstract notion of a queue in the Info Model?

Al

PS: Arne replied to a my message from yesterday  which mailman discarded due to
out-going address issues, see below.
________________________________________
From: Arne Oslebo [[email-masked]]
Sent: Tuesday, October 21, 2014 3:17 AM
To: MORTON, ALFRED C (AL); Juergen Schoenwaelder
Cc: [email-masked]
Subject: Re: [lmap] Information Model: Connecting Tasks

Arne

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Tue, 21 Oct 2014 13:06:35 +0000

Juergen,

My comment on making the queue a formal part of the information model would be that there would be an expectation to make these first class objects in the data models and associated protocols.
Also testing and certification would also assume queue behavior.
I am not against using queues to implement this solution. I just didn't need to model the queues to implement the behavior of the existing information model when I developed the TR-069 data model and protocol.

As to the technical concern - Sorry I misread you post "does NOW allow" as "does NOT allow". No I have no concerns that the information model "does allow" multiple consumers of an output through modeling of multiple Tasks.

Thanks,
Tim

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, October 20, 2014 1:36 AM
To: Carey, Timothy (Timothy)
Cc: [email-masked]; [email-masked]
Subject: Re: [lmap] Information Model: Connecting Tasks

 

/js

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 22 Oct 2014 11:34:29 -0400

Re-sending the discarded message as a test,
as instructed by ietf-action.
________________________________________
From: MORTON, ALFRED C (AL)
Sent: Monday, October 20, 2014 5:22 PM
To: Juergen Schoenwaelder; Arne Oslebo
Cc: [email-masked]
Subject: RE: [lmap] Information Model: Connecting Tasks

/js

ACM:

I don't understand the damage we cause if we recognize the queue,
but willing to listen...

Al

---

From: Sharam Hakimi <[email-masked]>
Date: Wed, 22 Oct 2014 16:22:32 +0000

What I think needs to be specified is that an MA must have enough capability(CPU power, memory, etc.) to execute a single defined task( run task, log, transfer results). Beyond that really should be up to the implementation. If one can design an inexpensive device with multiple core CPUs and Gigs of memory that allows for multiple concurrent tasks then that is up to the implementer. 

I do not think we should manage implementations, rather specify the resource requirement for every defined task.

Sharam

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of MORTON, ALFRED C (AL)
Sent: Wednesday, October 22, 2014 11:34 AM
To: [email-masked]
Subject: Re: [lmap] Information Model: Connecting Tasks

/js

ACM:

Al

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 22 Oct 2014 20:43:28 +0200

> I do not think we should manage implementations, rather specify the resource requirement for every defined task.

Using LMAP, I can configure (a) how frequently a measurement test is
executed (and hence how much data it produces) and (b) how frequently
a reporting task is executed. In other words, the amount of buffer
space I need depends on the schedule(s) and hence it is out of the
control of the implementation. Even if an implementation tries to
reject schedules that may potentially overrun resources, once you
loose connectivity it surely can run out of resources again.

Assuming an implementation has always sufficient resources is
unrealistic and definitely not something that can be specified.

Note: We are not talking about the execution of a single task but
instead about how data is passed between tasks.

/js

---

From: Sharam Hakimi <[email-masked]>
Date: Thu, 23 Oct 2014 15:16:39 +0000

As an example, when a car is designed each part in the car defines the power requirement for it to run. The Battery/Alternator system is designed based on as many parts that can run concurrently and that is up to implementation. Not all MAs will be created equal and I do not believe that we need to specify an implementation. The user will dictate what their requirement is and the implementation would need to match that. How many queues to handle is up to the implementation.

Today One server can handle 100 TWAMP connection and perform the test and another can handle 1000. TWAMP does not specify the implementation, just what is required to schedule, run, capture results and report results for one instance.

Sharam 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2014 2:43 PM
To: Sharam Hakimi
Cc: MORTON, ALFRED C (AL); [email-masked]
Subject: Re: [lmap] Information Model: Connecting Tasks

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 23 Oct 2014 20:07:36 +0200

Making queues explicit in the information model != specify the
implementation. Without some form of queues, you can't pass
information between tasks that run on different schedules.

Following you analogy, I am saying we should say that the car has an
engine instead of pretending all it has is a gas pedal. Once your car
stops, it will become important to know whether you need to look for
electicity or some other type of fuel.

I guess analogies do not help much...

/js

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 23 Oct 2014 14:19:24 -0400

I agree with Juergen's comment below.

We are debating concepts in the Information Model  (it's not even a data model yet).
Perhaps it is the uncertainty of what will be agreed that causes problems here.

Trevor, I hope we will have a more concrete proposal (with the queue concept)
to review before IETF-91, then this issue can be put to bed.

Al
________________________________________
From: Juergen Schoenwaelder [[email-masked]]
Sent: Thursday, October 23, 2014 2:07 PM
To: Sharam Hakimi
Cc: MORTON, ALFRED C (AL); [email-masked]
Subject: Re: [lmap] Information Model: Connecting Tasks

/js

---

From: Arne Oslebo <[email-masked]>
Date: Thu, 23 Oct 2014 23:11:35 +0200

> Perhaps it is the uncertainty of what will be agreed that causes problems here.
Even if implementation details have been brought into the discussion I
think the key issue is whether we should include the concept of queues
as a formal entity in the information model. This was discussed at the
interim meeting as well and there people seemed to prefer not defining
queues as a formal entity. Trevor said he would informally mention
queues in the description so hopefully he will have a new version ready
soon.

Arne

---

From: Sharam Hakimi <[email-masked]>
Date: Fri, 24 Oct 2014 15:20:08 +0000

Now that I think we agree not to specify processing power or resource requirements for passing parameters between tasks, it is back to just trying to specify a queue mechanism to try to pass some parameters between tasks. Some parameters can be part of the schedule, for example:

	Run Task A
	If Task A completes with success Run Task B  
					Else goto Task C 

	Task B
	Task C

One would not need to pass any parameter between A and B even though the result of Task A is used to make a decision on the execution of the schedule by the MA. 

I am not sure how easy it would be to get consensus on the Queue structure if we do not know what needs to be passed between what tasks or what the consequence of that would be. 

Sharam

-----Original Message-----
From: MORTON, ALFRED C (AL) [mailto:[email-masked]] 
Sent: Thursday, October 23, 2014 2:19 PM
To: Juergen Schoenwaelder; Sharam Hakimi
Cc: [email-masked]
Subject: RE: [lmap] Information Model: Connecting Tasks

Al

/js

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 24 Oct 2014 14:46:13 -0700

Hi Juergen,
I agree that specifying behavior is important to arrive to interoperable
implementations. I don't think that specifying particular mechanism, i.e.
queue, is critical. I don't think that when considering queue we assume it
as infinite resource. If that is the case, then I can present
implementation without a queue as queue of zero depth. Thus the only
difference between queued and un-queued output would be when it may get
overrun. What I'd like to have is defined behavior of end-points of the
output channel.

Regards,
Greg

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Oct 2014 18:55:18 +0100

Please tell me how you pass results from a measurement task to
reporting task scheduled later without a queue.

Thanks,

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Oct 2014 18:57:27 +0100

We are talking about passing measurement results to a reporting tasks.
The word 'parameter' may confuse this little detail. And a specific
corner case does not help us to resolve the general case, namely that
measurement tasks and reporting tasks run according to independent
schedules.

/js

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Mon, 27 Oct 2014 18:52:58 +0000

I still believe that most tests are actually scripts vs. a task... 

  A task is a work item... that can contain a script ?

Enjoy the meeting - I'm on vacation for a good part of this one so I dind't bother trying to ask for travel.

Best regards,
Mike

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Monday, October 27, 2014 12:57 PM
To: Sharam Hakimi
Cc: MORTON, ALFRED C (AL); [email-masked]
Subject: Re: [lmap] Information Model: Connecting Tasks

We are talking about passing measurement results to a reporting tasks.
The word 'parameter' may confuse this little detail. And a specific corner case does not help us to resolve the general case, namely that measurement tasks and reporting tasks run according to independent schedules.

/js

On Fri, Oct 24, 2014 at 03:20:08PM +0000, Sharam Hakimi wrote:
> Trevor, I hope we will have a more concrete proposal (with the queue 
> concept) to review before IETF-91, then this issue can be put to bed.
> 
> Al
> > From: Juergen Schoenwaelder 
> > [mailto:[email-masked]]
> > executed (and hence how much data it produces) and (b) how 
> > frequently a reporting task is executed. In other words, the amount 
> > of buffer space I need depends on the schedule(s) and hence it is 
> > out of the control of the implementation. Even if an implementation 
> > tries to reject schedules that may potentially overrun resources, 
> > once you loose connectivity it surely can run out of resources again.
> >