Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 1 Sep 2014 22:28:01 +0200

On Fri, Aug 29, 2014 at 06:27:07PM +0800, 邓灵莉/Lingli Deng wrote:
> 
> [邓灵莉/Lingli Deng] Point taken. So the schedule for the
> measurement task, even the one contained a reporting task
> description (as one of the downstream task) is not intended to set
> schedule for the reporting task., right?  What about a measurement
> task that requires instant reporting after each round? Does one
> still need another independent schedule for the reporting task?

I had a more detailed look at the relevant text today and I agree that
it is unclear and leads to a number of questions.

/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: <[email-masked]>
Date: Tue, 2 Sep 2014 09:10:26 +0100

If instant reporting is required a measurement task and reporting task can be included in the same schedule. The draft states that such as sequence of tasks should be executed with minimal gaps. I hoped it was clear that everything is a task and that all tasks are treated equally - therefore you can mix measurement and other tasks freely within a single schedule.

Trevor Burbridge

>-----Original Message-----
>From: Juergen Schoenwaelder [mailto:[email-masked]]
>Sent: 01 September 2014 21:28
>To: 邓灵莉/Lingli Deng
>Cc: [email-masked]; 'Romascanu, Dan (Dan)'; Burbridge,T,Trevor,TUB8 R;
>Eardley,PL,Philip,TUB8 R; [email-masked]
>Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02
>

---

From: 邓灵莉/Lingli Deng <[email-masked]>
Date: Tue, 2 Sep 2014 19:07:17 +0800

Hi Trevor, 

Thanks for the clarification. I fully understand your point that multiple tasks can share a single schedule/timing.

I think concrete examples of the intended schedule structure may be of help here. (You might also want to refer to my original question and JS's reponse last week.)

Assumption: Controller has sent a Schedule X including descriptions about a measurement task A and its related reporting task B. 

For the timing of B, there may be two possibilities: 
Case 1 (instant reporting): B is required to be performed every time after A. Their timings are bounded with the same schedule X.
Case 2 (independent reporting): B's timing is actually specified by another Schedule Y.

If the above is really what you intended (which I got confirmation from you by asking questions), I would wish you add proper description in the main text or use some illustration (not in JSON) in the appendix.

And my further question goes to:
Upon handling Schedule X (either for the instruction, suppression, update, etc.), would it be better if we can make it clear to the MA, whether or not it has to refer to another schedule to fully understand the timing requirements for the reporting task B? 
For example, if a suppression instruction is issued some time later for schedule X, does it also affect reporting task B? 

Lingli

> From: lmap [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, September 02, 2014 4:10 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> If instant reporting is required a measurement task and reporting task can
> be included in the same schedule. The draft states that such as sequence
> of tasks should be executed with minimal gaps. I hoped it was clear that
> everything is a task and that all tasks are treated equally - therefore you
> can mix measurement and other tasks freely within a single schedule.
> 
> 
> Trevor Burbridge
> 
> >From: Juergen Schoenwaelder
> [mailto:[email-masked]]
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Sep 2014 10:04:20 +0200

On Tue, Sep 02, 2014 at 09:10:26AM +0100, [email-masked] wrote:

> If instant reporting is required a measurement task and reporting
> task can be included in the same schedule. The draft states that
> such as sequence of tasks should be executed with minimal gaps. I
> hoped it was clear that everything is a task and that all tasks are
> treated equally - therefore you can mix measurement and other tasks
> freely within a single schedule.

What I find somewhat confusing is that we have a sequence of tasks
that is executed sequentially and we also have a downstream tasks and
it is unclear to me how things interact. One interpretation is that
ma-sched-downstream-tasks-obj really is only about information flow,
that is any downstream tasks do are invoked by being listed in a task
sequence of a schedule.

If this interpretation is correct, then I still find the plumping how
data flows between tasks somewhat unclear. In the general case, there
will be a buffer between a task producing data and a task consuming
data. Perhaps we need to model these buffers explicitely and then we
can say something like task X feeds into buffer A and task Y consumes
data from buffer A. This makes the pluming clearer I think. We could
also put constraints on buffers or in future versions have controls on
buffers (e.g. old data is discarded if buffers fill up). Right now, we
have these magic output selection numbers which I do not find really
clear (how do I know which output selection number I have to use for a
certain task)?

/js

---

From: <[email-masked]>
Date: Wed, 3 Sep 2014 09:16:55 +0100

As it seems I haven't managed to put to bed the question of how to connect different tasks together, I'll make it the primary discussion for the Information Model in Dublin. 

Also see inline...

>Sent: 03 September 2014 09:04
>To: Burbridge,T,Trevor,TUB8 R
>Cc: [email-masked]; [email-masked]; [email-masked];
>> If instant reporting is required a measurement task and reporting task
>> can be included in the same schedule. The draft states that such as
>> sequence of tasks should be executed with minimal gaps. I hoped it was
>> clear that everything is a task and that all tasks are treated equally
>> - therefore you can mix measurement and other tasks freely within a
>> single schedule.
>
>What I find somewhat confusing is that we have a sequence of tasks that is
>executed sequentially and we also have a downstream tasks and it is unclear to
>me how things interact. One interpretation is that ma-sched-downstream-tasks-
>obj really is only about information flow, that is any downstream tasks do are
>invoked by being listed in a task sequence of a schedule.

Yes - exactly.

>If this interpretation is correct, then I still find the plumping how data flows
>between tasks somewhat unclear. In the general case, there will be a buffer
>between a task producing data and a task consuming data. Perhaps we need to
>model these buffers explicitely and then we can say something like task X feeds
>into buffer A and task Y consumes data from buffer A. This makes the pluming
>clearer I think. 

I did consider this idea to have a concept of explicit queues. However I decided it was an additional information object that actually wasn't necessary. If we start to attach more information to queues such as you describe below then they do become useful. I thought this was making things more complicated and harder to understand though than just saying "task A output 2 goes to task B". Instead we'd say "task A output 2 goes to channel X, task B gets input from channel X". Then we need to discuss if a queue persists data if more than one task is consuming from it etc.

>We could also put constraints on buffers or in future versions have
>controls on buffers (e.g. old data is discarded if buffers fill up). Right now, we
>have these magic output selection numbers which I do not find really clear (how
>do I know which output selection number I have to use for a certain task)?

The input and output data interfaces of any particular task do need to be defined by the registry along with the parameters that are used to configure it.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Sep 2014 10:35:11 +0200

On Wed, Sep 03, 2014 at 09:16:55AM +0100, [email-masked] wrote:
> 
> I did consider this idea to have a concept of explicit
> queues. However I decided it was an additional information object
> that actually wasn't necessary. If we start to attach more
> information to queues such as you describe below then they do become
> useful. I thought this was making things more complicated and harder
> to understand though than just saying "task A output 2 goes to task
> B". Instead we'd say "task A output 2 goes to channel X, task B gets
> input from channel X". Then we need to discuss if a queue persists
> data if more than one task is consuming from it etc.
>

To implement this information model, you have to have queues of some
sort and then an implementor has to answer how the queues work, such
as whether data can be only consumed once or multiple times if there
are multiple readers or what to do if the queues fill up. The
likelihood is high that implementers will take different approaches if
we do not detail this. For me, modeling queues explicitely makes
things more obvious and hence simpler.

/js

---

From: Arne Oslebo <[email-masked]>
Date: Thu, 04 Sep 2014 11:46:40 +0200

> I did consider this idea to have a concept of explicit queues. However I decided it was an additional information object that actually wasn't necessary. If we start to attach more information to qu…
The way I understand the information model is that we are actually
saying that "Output X from task A in schedule S goes to task B". With
this method we have to create a different task for each reporting
interval since tasks doesn't have any schedule information in them.

I see that in draft-schoenw-lmap-yang-01 the downstream-task is defined
as a reference to a task, but in the example xml at the end of the
document they are actually referencing a schedule which I think is the
correct way to do things. So what we should be able to specify is
"Output X from task A in schedule S goes to all tasks in schedule T".

Arne

---

From: <[email-masked]>
Date: Thu, 4 Sep 2014 10:56:43 +0100

>From: lmap [mailto:[email-masked]] On Behalf Of Arne Oslebo
>Sent: 04 September 2014 10:47
>To: [email-masked]
>> I did consider this idea to have a concept of explicit queues. However I decided
>it was an additional information object that actually wasn't necessary. If we start
>to attach more information to queues such as you describe below then they do
>become useful. I thought this was making things more complicated and harder to
>understand though than just saying "task A output 2 goes to task B". Instead we'd
>say "task A output 2 goes to channel X, task B gets input from channel X". Then
>we need to discuss if a queue persists data if more than one task is consuming
>from it etc.
>

Yes - I meant within the scope of that schedule.

>"Output X from task A in schedule S goes to all tasks in schedule T".

Good point - and yes the downstream task should also be within the scope of a particular schedule (needs correcting in the Information Model) - so maybe the suggestion of explicit queues does simplify things.