Subject: [lmap] First take on the Definition of Cycle_ID

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 22 Feb 2016 14:21:14 -0500

LMAP, please have a look, feel free to add aspects to the 
definition that would be valuable.

Al

Cycle_ID

The Cycle_ID is a special form of Tag that provides
an easily distinguishable index for sets of results (or other aspect) 
from each "cycle" of Repeating Tasks. Each repetition 
of the task and its results (including measurements of multiple 
metrics on a single packet stream, for example) have the 
same Cycle_ID. Some portion of the Cycle_ID will be numerical.

The Cycle_ID must be easily searchable, such that the values 
assigned (by the MA?) should be predictable and meaningful to
a human conducting a search for specific results.

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Mon, 22 Feb 2016 19:49:20 +0000

Al,

>From the framework document:
Cycle-ID: A tag that is sent by the Controller in an Instruction and echoed by the MA in its Report. The same Cycle-ID is used by several MAs that use the same Measurement Method for a Metric with the same Input Parameters. Hence, the Cycle-ID allows the Collector to easily identify Measurement Results that should be comparable.

Th information model says:

In addition the Task Configuration may optionally also be given a Measurement Cycle ID. The purpose of this ID is to easily identify a set of measurement results that have been produced by Measurement Tasks with comparable Options. This ID could be manually incremented or otherwise changed when an Option change is implemented which could mean that two sets of results should not be directly compared.

What is wrong with the Information model definition - is it because the definition is missing the notion of "repetition" and the idea that it should be easily distinguishable?

BR,
Tim
-----Original Message-----
From: MORTON, ALFRED C (AL) [mailto:[email-masked]] 
Sent: Monday, February 22, 2016 1:21 PM
To: [email-masked]
Subject: [lmap] First take on the Definition of Cycle_ID

LMAP, please have a look, feel free to add aspects to the definition that would be valuable.

Al

Cycle_ID

The Cycle_ID is a special form of Tag that provides an easily distinguishable index for sets of results (or other aspect) from each "cycle" of Repeating Tasks. Each repetition of the task and its results (including measurements of multiple metrics on a single packet stream, for example) have the same Cycle_ID. Some portion of the Cycle_ID will be numerical.

The Cycle_ID must be easily searchable, such that the values assigned (by the MA?) should be predictable and meaningful to a human conducting a search for specific results.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 22 Feb 2016 15:31:47 -0500

Hi Tim,

For the current Info model definition, I don't agree that 
concept of a "cycle" matches the notion of modifying options.
The modifications can be tracked with version numbers, 
and the new versions are not cyclic in timing or in their nature.

Yes, for me, a cycle requires repetition over time. So the framework
definition almost gets there by mentioning results that are 
comparable, but it only deals with repetition *across MAs*.
In the Framework def, a repeated measurement task would have the
same Cycle-ID for every repetition, in every MA that performs the 
the same repeated task, and we lose the ability to distinguish
the repetitions over time (without use of additional info, like time).

In summary, there is value in the both of the "consolidating indexes"
described in the Framework and the Info Model as "Cycle-ID", 
but neither of these indexes have anything to do with Cycles!

If we want to compare results, at same time and equivalent locations, we have to
employ the Registered metric and all its parameters, and include the 
location of the measurement points (http://tools.ietf.org/html/rfc7398 ).
Many dimensions to keep equivalent.  

Way beyond the notion of "cycle", IMO.
Al

> From: Carey, Timothy (Nokia - US) [mailto:[email-masked]]
> Sent: Monday, February 22, 2016 2:49 PM
> To: MORTON, ALFRED C (AL); [email-masked]
> Subject: RE: [lmap] First take on the Definition of Cycle_ID
> 
> Al,
> 
> Cycle-ID: A tag that is sent by the Controller in an Instruction and
> echoed by the MA in its Report. The same Cycle-ID is used by several MAs
> that use the same Measurement Method for a Metric with the same Input
> Parameters. Hence, the Cycle-ID allows the Collector to easily identify
> Measurement Results that should be comparable.
> 
> In addition the Task Configuration may optionally also be given a
> Measurement Cycle ID. The purpose of this ID is to easily identify a set
> of measurement results that have been produced by Measurement Tasks with
> comparable Options. This ID could be manually incremented or otherwise
> changed when an Option change is implemented which could mean that two
> sets of results should not be directly compared.
> 
> 
> What is wrong with the Information model definition - is it because the
> definition is missing the notion of "repetition" and the idea that it
> should be easily distinguishable?
> 
> BR,
> Tim
> The Cycle_ID is a special form of Tag that provides an easily
> distinguishable index for sets of results (or other aspect) from each
> "cycle" of Repeating Tasks. Each repetition of the task and its results
> (including measurements of multiple metrics on a single packet stream,
> for example) have the same Cycle_ID. Some portion of the Cycle_ID will
> be numerical.
> 
> The Cycle_ID must be easily searchable, such that the values assigned
> (by the MA?) should be predictable and meaningful to a human conducting
> a search for specific results.
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 23 Feb 2016 17:51:38 +0000

By 'predictable and meaningful' you mean what? 
- some form of timestamp
- some form of increasing integer index? 
or ....

Regards,

Dan

> From: lmap [mailto:[email-masked]] On Behalf Of MORTON, ALFRED
> C (AL)
> Sent: Monday, February 22, 2016 9:21 PM
> To: [email-masked]
> The Cycle_ID is a special form of Tag that provides an easily distinguishable
> index for sets of results (or other aspect) from each "cycle" of Repeating
> Tasks. Each repetition of the task and its results (including measurements of
> multiple metrics on a single packet stream, for example) have the same
> Cycle_ID. Some portion of the Cycle_ID will be numerical.
> 
> The Cycle_ID must be easily searchable, such that the values assigned (by the
> MA?) should be predictable and meaningful to a human conducting a search
> for specific results.
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 23 Feb 2016 14:02:26 -0500

Hi Dan,

Here's an example scenario for analyzing results 
of tests repeated every 15 minutes (I don't intend 
to require some specification for Cycle_ID, 
just show its potential value):

The Cycle_ID could include the 
date, YYYY-MM-DD,
time, HH:MM:SS (and perhaps the time zone, too)
code, decimal number to distinguish between different repeating tests.

<code>; HH:MM:SS ; YYY-MM-DD;  (assuming Zulu time)

The predictable and meaningful aspect is linked to "conducting a search".

Suppose I wanted the results from a test that ran at the beginning of
the scheduled LMAP interim meeting: I can easily construct the first and last
Cycle_IDs and extract the inclusive data range. 

0000001; 17:00:00 ; 2016-02-22;
0000001; 19:00:00 ; 2016-02-22;

All the metrics collected as part of this repeating task would have the
same unique Cycle_ID corresponding to that task. The task could be to
run a quick traceroute, then measure one-way delay, delay variation, and loss
on the same measurement stream.  All these metrics have the same Cycle_ID. 

With the above as a Cycle_ID, I don't need the scheduled time of the task.
I can report the "Red" timestamps pertaining to the actual measurement 
times with the table of results instead. (As I described yesterday,
"Blue" timestamps refer to the schedule times for a task, and "Red" refer
to the actual measurement time interval when packets are on the wire).

OTOH, it's somewhat harder to find the results if *only* the "Red" timestamps
are available, because they will have an unknown part in terms of the 
exact minute, second, and possibly sub-second when the measurement interval started.
You have to compose your query with ranges just to find a single set of 
results. 

And, it may be easier to determine that results for some cycles are missing.

I could take the Cycle_ID one step further, and incorporate repeating tests over
space and time:

<code>; HH:MM:SS ; YYY-MM-DD; <target_location_list>;

where a single MA conducts periodic measurements with a list of target MPs.

So, I'm thinking-up ways that LMAP users might want to index, collate, and access
the mass repeated measurement results once collected. 

Does that help?
Al

> From: lmap [mailto:[email-masked]] On Behalf Of Romascanu, Dan
> (Dan)
> Sent: Tuesday, February 23, 2016 12:52 PM
> Subject: Re: [lmap] First take on the Definition of Cycle_ID
> 
> > LMAP, please have a look, feel free to add aspects to the definition
> that
> > would be valuable.
> >
> > Al
> >
> > Cycle_ID
> >
> distinguishable
> (by the
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 24 Feb 2016 10:21:53 +0000

> Does that help?

It helps a lot. 

The definition will need a little more text to explain and/or an example.

Looks good to me on the user side. We need to hear also the coder side. 

Regards,

Dan

> Sent: Tuesday, February 23, 2016 9:02 PM
> To: Romascanu, Dan (Dan); [email-masked]
> Subject: RE: First take on the Definition of Cycle_ID
> 
> Hi Dan,
> 
> Here's an example scenario for analyzing results of tests repeated every 15
> minutes (I don't intend to require some specification for Cycle_ID, just show
> its potential value):
> 
> time, HH:MM:SS (and perhaps the time zone, too) code, decimal number to
> distinguish between different repeating tests.
> 
> Suppose I wanted the results from a test that ran at the beginning of the
> scheduled LMAP interim meeting: I can easily construct the first and last
> All the metrics collected as part of this repeating task would have the same
> unique Cycle_ID corresponding to that task. The task could be to run a quick
> traceroute, then measure one-way delay, delay variation, and loss on the
> same measurement stream.  All these metrics have the same Cycle_ID.
> 
> times with the table of results instead. (As I described yesterday, "Blue"
> timestamps refer to the schedule times for a task, and "Red" refer to the
> actual measurement time interval when packets are on the wire).
> 
> OTOH, it's somewhat harder to find the results if *only* the "Red"
> timestamps are available, because they will have an unknown part in terms
> of the exact minute, second, and possibly sub-second when the
> measurement interval started.
> I could take the Cycle_ID one step further, and incorporate repeating tests
> over space and time:
> 
> So, I'm thinking-up ways that LMAP users might want to index, collate, and
> access the mass repeated measurement results once collected.
> 
> Does that help?
> Al
> 
> > > From: lmap [mailto:[email-masked]] On Behalf Of MORTON,
> > > ALFRED C (AL)
> > > multiple metrics on a single packet stream, for example) have the
> > > assigned