Subject: [lmap] Multiple metrics measured on same active measurement traffic.

From: <[email-masked]>
Date: Thu, 23 Jul 2015 17:30:10 +0000

I was just discussing with Al and Marcelo the issue of when you want to measure multiple metrics from (for instance) the same active measurement traffic. folloiwng the discussion in the WG meeting.

There's a separate entry in the registry for each of these metrics. For the above requirement, they also need to have the same run-time parameters.

basically we want to make sure that the measurement agent knows that the same active traffic can be used to measure all the metrics . even if the MA is a simple device. it would be bad news to send separate active measurement traffic for each metric.

The first thing that should help is for the names of the metrics in the registry are sensible. then you get a hint that it may be possible. eg "Act_UDP_Latency_Poisson_mean" and "Act_UDP_Loss_Poisson_mean"

The main way is that the Instruction has a single Schedule with several Tasks listed in it, ie run these tasks at the same time. In this case, the most likely reason is that several measurements are to be made on the same traffic. The other possibility is that one Task is just creating loading traffic and the other Tasks are 'normal' ones. Perhaps we should recommend that the former should be in a separate Schedule? so that the MA knows for sure.

best wishes,

phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 23 Jul 2015 21:59:25 +0200

> The main way is that the Instruction has a single Schedule with several Tasks listed in it, ie run these tasks at the same time. In this case, the most likely reason is that several measurements ar…

I do not think so. The MA simply kicks of tasks, it does not
understand what the tasks do. My understand is that a task actually
declares (via references to the registry) which metrics it is going to
produce. So if a task points to the two registry entries

	 Act_UDP_Latency_Poisson_mean
	 Act_UDP_Loss_Poisson_mean

that it is clear that once you run this task, you will get both
metrics. I more or less assume that the number of metrics a task can
produce is a more or less static property of a task.

Perhaps it would help a lot if there were example metric registry
entries somewhere in draft-ietf-ippm-metric-registry-04.txt. The
artwork on page 11 kind of leaves me a bit puzzled. I guess the answer
is 'read the whole document carefully' but then having easy to
understand examples is often helpful...

/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: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Fri, 24 Jul 2015 02:18:09 -0400

Hi Juergen,

Draft-Morton-IPPM-initial-entries (sorry but that file name has been mangled by my keyboard
But the file is linked with the related documents on IPPM pages)

Has examples, and perhaps the most relevant is the last, section 8 I believe.
Note that this is an attempt to specify multiple entries with minimum 
redundant sections.

Regards,
Al
________________________________________
From: lmap [[email-masked]] On Behalf Of Juergen Schoenwaelder [[email-masked]]
Sent: Thursday, July 23, 2015 3:59 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [lmap] Multiple metrics measured on same active measurement traffic.

/js

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

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Fri, 24 Jul 2015 06:36:54 +0000

Phil,

I guess I don't understand the context of the comment. Was the context of the comment from the f2f meeting's discussion of multiple task registry entries for a task - were we said multiple metrics (task registry entries) can be assigned to a task which is then scheduled?

BR,
Tim

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 23, 2015 7:30 PM
To: [email-masked]
Subject: [lmap] Multiple metrics measured on same active measurement traffic.

best wishes,

phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 24 Jul 2015 08:39:07 +0200

Hi Al,

thanks for this pointer. I would have loved if there would have been
something structured machine readable but it perhaps IANA creates this
somehow. Looking at section 8, I already have the question whether
LMAP should refer to the URN or the URI. Is there any recommendation
that we should make?

/js

PS: I wonder whether the capitalization rules for names not make
    things more complex than needed - but then perhaps the names are
    too hard to type anyway.

---

From: <[email-masked]>
Date: Fri, 24 Jul 2015 07:41:39 +0000

Just a slight correction here: if you want multiple tasks to run simultaneously then you create parallel schedules with the same execution time. If multiple tasks are within a single schedule they will run in sequence.

Trevor.

From: lmap [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 23 July 2015 18:30
To: [email-masked]
Subject: [lmap] Multiple metrics measured on same active measurement traffic.

best wishes,

phil

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Fri, 24 Jul 2015 05:28:33 -0400

Hi Juergen,

The "machine-readable" view was also the subject of one of Barbara
Stark's reviews of the registry, and discussed at the last IPPM session.
Our view has been that this is a registry for implementers to read,
and that they are likely to be humans.

Personally, I think the URL will be more useful to humans and the 
URI for a wider audience. But maybe I don't understand yet the
full implications of those assignments.

regards,
Al

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Friday, July 24, 2015 2:39 AM
> To: MORTON, ALFRED C (AL)
> Cc: [email-masked]; [email-masked]
> somehow. Looking at section 8, I already have the question whether LMAP
> should refer to the URN or the URI. Is there any recommendation that we
> should make?
> 
> /js
> 
> > Draft-Morton-IPPM-initial-entries (sorry but that file name has been
> > mangled by my keyboard But the file is linked with the related
> > documents on IPPM pages)
> >
> > > I was just discussing with Al and Marcelo the issue of when you want
> to measure multiple metrics from (for instance) the same active
> measurement traffic. folloiwng the discussion in the WG meeting.
> > >
> > > There's a separate entry in the registry for each of these metrics.
> For the above requirement, they also need to have the same run-time
> parameters.
> > >
> > > basically we want to make sure that the measurement agent knows that
> the same active traffic can be used to measure all the metrics . even if
> the MA is a simple device. it would be bad news to send separate active
> measurement traffic for each metric.
> > >
> > > The first thing that should help is for the names of the metrics in
> the registry are sensible. then you get a hint that it may be possible.
> eg "Act_UDP_Latency_Poisson_mean" and "Act_UDP_Loss_Poisson_mean"
> > >
> > > The main way is that the Instruction has a single Schedule with
> several Tasks listed in it, ie run these tasks at the same time. In this
> case, the most likely reason is that several measurements are to be made
> on the same traffic. The other possibility is that one Task is just
> creating loading traffic and the other Tasks are 'normal' ones. Perhaps
> we should recommend that the former should be in a separate Schedule? so
> that the MA knows for sure.
> > >
> >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 24 Jul 2015 11:33:45 +0200

> and that they are likely to be humans.

Hm. Given the fine granularity of the metric definitions, I expect a
number of metrics that likely asks for tools. IANA anyway seems to
prefer to store all registry data in XML format (or something that
exports into an XML format). Did you talk to IANA how they like to
maintain this?

> full implications of those assignments.

For tools, having multiple identifiers for the same thing makes life
more complex. You (IPPM) seem to have plenty of identifiers for the
same thing.

/js