Subject: [lmap] lmap example execution diagram

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jul 2016 19:25:16 +0200

Hi,

while talking with Al I created a diagram illustrating the execution
of some schedules on paper in order to make it easier for us to
understand the various interesting points in time we have. We found
this drawing very helpful and so I started to draw it up in ASCII art
so that it fits the RFC format constraints and I added some (very
minimal) explanatory text to it. Our proposal is to add such a diagram
to the information model and in addition I like to propose to align
the examples contained in the YANG and RESTCONF documents with this
diagram since it might be helpful to have examples that together tell
a consistent story.

Feedback welcome.

   ------8<------8<------8<------8<------8<------8<------

In the example, we have two event sources E1 and E2 and three
schedules S1, S2, and S3. The schedule S3 is started by events of
event source E2 while the schedules S1 and S2 are both started by
events of the event source E1. The schedules S1 and S2 have two
actions each and schedule S3 has a single action. The event source E2
has no randomization while the event source has the randomization r.

The diagram below shows a possible timeline of an execution. The time
T is progressing downwards. The dotted vertial line indicates progress
of time while a dotted horizontal line indicates which schedule are
triggered by an event. Tilded lines indicate data flowing from an
action to another schedule. Actions within a schedule are named A1,
A2, etc.

  E2    E1   T           S1           S2            S3
                     sequential    parallel     sequential
             :
          e0 +
             :
             :
        e0+r + .......... + .......... ++
             :            | A1      A1 || A2
             :            +            |+ ~~~~~~~>
             :            | A2         |
             :            |            + ~~~~~~~~>
             :            + ~~~~~~~~~~~~~~~~~~~~~>
             :
	     :
          e1 +
             :
        e1+r + .......... + .......... ++
             :            | A1      A1 ||
             :            |            +|~~~~~~~>
             :            |             | A2
             :            +             +~~~~~~~>
             :            | A2
             :            + ~~~~~~~~~~~~~~~~~~~~>
   e0        + ................................... +
	     :                                     | A1
	  e3 +                                     |
	e3+r + .......... + .......... ++          |
	     :            | A1      A1 || A2       |
	     :            +            ++ ~~~~~~>  |
	     :            | A2                     +
	     :            + ~~~~~~~~~~~~~~~~~~~~>
             V

Note that implementations must handle possible concurrency issues.  In
the example execution, action A1 of schedule S3 is consuming that has
been forwarded to schedule S3 while additional data is arriving from
action A2 of schedule S2.

/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: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Thu, 21 Jul 2016 19:04:19 +0000

Juergen,

The example is accurate.

The change would be that event source "E1" has the randomization r

In the example, we have two event sources E1 and E2 and three schedules S1, S2, and S3. The schedule S3 is started by events of event source E2 while the schedules S1 and S2 are both started by events of the event source E1. The schedules S1 and S2 have two actions each and schedule S3 has a single action. The event source E2 has no randomization while the event source E1 has the randomization r.

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, July 21, 2016 7:25 PM
To: [email-masked]
Subject: [lmap] lmap example execution diagram

Hi,

while talking with Al I created a diagram illustrating the execution of some schedules on paper in order to make it easier for us to understand the various interesting points in time we have. We found this drawing very helpful and so I started to draw it up in ASCII art so that it fits the RFC format constraints and I added some (very
minimal) explanatory text to it. Our proposal is to add such a diagram to the information model and in addition I like to propose to align the examples contained in the YANG and RESTCONF documents with this diagram since it might be helpful to have examples that together tell a consistent story.

Feedback welcome.

In the example, we have two event sources E1 and E2 and three schedules S1, S2, and S3. The schedule S3 is started by events of event source E2 while the schedules S1 and S2 are both started by events of the event source E1. The schedules S1 and S2 have two actions each and schedule S3 has a single action. The event source E2 has no randomization while the event source has the randomization r.

The diagram below shows a possible timeline of an execution. The time T is progressing downwards. The dotted vertial line indicates progress of time while a dotted horizontal line indicates which schedule are triggered by an event. Tilded lines indicate data flowing from an action to another schedule. Actions within a schedule are named A1, A2, etc.

  E2    E1   T           S1           S2            S3

Note that implementations must handle possible concurrency issues.  In the example execution, action A1 of schedule S3 is consuming that has been forwarded to schedule S3 while additional data is arriving from action A2 of schedule S2.

/js