Subject: [lmap] Information Model: Task Configuration

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

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

Currently we have a concept of a Task Configuration where task parameters can be configured. The same Task Configuration can then be referenced multiple times from  number of different Schedules.

It was pointed out that this can be very inefficient if we want to run basically the same task with just one parameter changing each time such as the test target. E.g. if we are running against 10 different targets then we largely have to reproduce and transmit to the MA 10 very similar Task Configurations.

The options as I understand them are:

-        Specify all parameters in Task Configurations is fine. Conceptually simple is more important than efficiency

-        Allow a hierarchical inheritance of Task Configurations. I.e. define a general Task Configuration and the specialise for 10 different targets. May be very confusing for people not familiar with such concepts especially at the data model level.

-        Allow task parameters to be specified either by using/referencing a Task Configuration or by supplying them within a Schedule. E.g. this would allow a general Task Configuration to be used but the target could be supplied within the Schedule. Conceptually clean, flexible and allows the optimum balance.

All options are as powerful as each other so it comes down to which is easier to understand and which is more efficient.

Before someone asks, the current model is not quite as clean as the first option on this list since we have Channel selection within the Schedule. I think the agreement was that this shouldn't be treated as a special case so this will change regardless of the decision above.

Trevor

---

From: KEN KO <[email-masked]>
Date: Wed, 15 Oct 2014 14:01:59 +0000

You probably want to hear views from a wider community, but I'll repeat my preference from Dublin. I think the last option listed is preferable. Specifically, all parameters should be specifiable at the Task Configuration level but over-rideable at the Schedule level where they are instantiated.

From: lmap [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, October 15, 2014 7:18 AM
To: [email-masked]
Subject: [lmap] Information Model: Task Configuration

Trevor

---

From: Sharam Hakimi <[email-masked]>
Date: Wed, 15 Oct 2014 17:32:30 +0000

I would agree that the last option would be best. The task list and the targets should not be tied together. One would have a list of tasks (could be one also) and a list of targets that would specify which task is required to be used for that target. This way if all targets use only one task, then that task would only be sent to the MA once.

Sharam

From: lmap [mailto:[email-masked]] On Behalf Of KEN KO
Sent: Wednesday, October 15, 2014 10:02 AM
To: [email-masked]; [email-masked]
Subject: Re: [lmap] Information Model: Task Configuration

Trevor

---

From: KEN KO <[email-masked]>
Date: Wed, 15 Oct 2014 17:44:28 +0000

My view is a little more expansive than what I read Sharam saying. Since the Information Model can't anticipate what value there might be in overriding which parameters for a given Measurement Method, we shouldn't limit the overrides to a specific type of parameter (e.g., target). Allow the schedule to override any parameter.

From: lmap [mailto:[email-masked]] On Behalf Of Sharam Hakimi
Sent: Wednesday, October 15, 2014 11:33 AM
To: [email-masked]; [email-masked]
Subject: Re: [lmap] Information Model: Task Configuration

Sharam

From: lmap [mailto:[email-masked]] On Behalf Of KEN KO
Sent: Wednesday, October 15, 2014 10:02 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [lmap] Information Model: Task Configuration

From: lmap [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, October 15, 2014 7:18 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [lmap] Information Model: Task Configuration

Trevor

---

From: Sharam Hakimi <[email-masked]>
Date: Wed, 15 Oct 2014 17:56:19 +0000

Whether one specifies multiple task lists or supplies a task list with an override list for every target is not going to differ from the execution point of view in my opinion. I think it would be cleaner to specify multiple task lists that are used by different targets. The assumption would be that most targets will use the same task list with a few minor variations.

Sharam

From: KEN KO [mailto:[email-masked]]
Sent: Wednesday, October 15, 2014 1:44 PM
To: Sharam Hakimi; [email-masked]; [email-masked]
Subject: RE: Information Model: Task Configuration

Sharam

Trevor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Oct 2014 09:03:19 +0200

> All options are as powerful as each other so it comes down to which is easier to understand and which is more efficient.

Let me expand on the third option:

    The Task Configuration is a name/value pair list. A bSchedule has
    another name/value pair list that is conceptually appended (or
    prepended - to be decided) to the Task Configuration list. The
    measurement task will have to decide based on the semantics of the
    parameters involved whether a repeated name/value pair is an
    overwrite or an addition. (This is nothing new since the Task
    Configuration even today allows repeated name/value pairs and this
    does make sense.)

I believe this is conceptually simple. More 'static' task
configuration parameters can be shared between schedules while more
'dynamic' task configuration parameters can go into the schedules.

Example:

    For a ping6 ping, you may want to configure relatively static
    parameters such as the flow label to use, the interval between
    each packet, whether it is using IMCPv6 Echo requests or Node
    Information Queries, the DSCP value to use, the packet size,
    etc. in a Task Configuration and in the Schedule you configure the
    target(s) to be probed with these Task Configuration parameters.

/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: Greg Mirsky <[email-masked]>
Date: Fri, 24 Oct 2014 14:10:57 -0700

Hi Juergen, et. al,
what I think Ken is saying, and I agree with that approach, is that, using
your example, Schedule may overwrite *any *parameter configured in a Task
Configuration not just fill in missing parameters.

Regards,
Greg

On Mon, Oct 20, 2014 at 12:03 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > During Dublin we debated (but didn't come to a strong conclusion on) two
> key topics. This is the first of those topics.
> >
> > Currently we have a concept of a Task Configuration where task
> parameters can be configured. The same Task Configuration can then be
> referenced multiple times from  number of different Schedules.
> >
> > It was pointed out that this can be very inefficient if we want to run
> basically the same task with just one parameter changing each time such as
> the test target. E.g. if we are running against 10 different targets then
> we largely have to reproduce and transmit to the MA 10 very similar Task
> Configurations.
> >
> > -        Specify all parameters in Task Configurations is fine.
> Conceptually simple is more important than efficiency
> >
> > -        Allow a hierarchical inheritance of Task Configurations. I.e.
> define a general Task Configuration and the specialise for 10 different
> targets. May be very confusing for people not familiar with such concepts
> especially at the data model level.
> >
> > -        Allow task parameters to be specified either by
> using/referencing a Task Configuration or by supplying them within a
> Schedule. E.g. this would allow a general Task Configuration to be used but
> the target could be supplied within the Schedule. Conceptually clean,
> flexible and allows the optimum balance.
> >
> > All options are as powerful as each other so it comes down to which is
> easier to understand and which is more efficient.
> >
>
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 24 Oct 2014 23:36:16 +0200

Hi,

I understand but I disagree since the semantics of the parameters need
decide whether we overwrite or add another parameters. Hence, it is
best to join the parameter lists and to let the task, based on the
semantics of the parameters, decide what it should do.

For me, the parameters are an ordered list and duplicates are
allowed. The most meaningful operation for me is an append (or
prepend).

Here is an example:

  iperf -u -c localhost -t 10 -t 2

The option -t can only appear once, last option wins.

Another example:

  ping www.ietf.org -c 8 -c 2
  mtr -c 8 -c 2 www.ietf.org

The option -c can only appear once, last option wins.

And one more:

  happy -q 6 -q 1 www.ietf.org www.bing.com

The option -q can only appear once, last option wins. The target can
appear multiple times so both www.ietf.org and www.bing.com are
probed.

/js