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

From: <[email-masked]>
Date: Sat, 2 Apr 2016 00:11:51 +0000

Al,
Not sure if this got resolved, sorry if this email is now redundant.

In your example, I'd have thought that cycle-id would be something like "tests-during-lmap-meeting".  Then it would be easy for someone to extract all the relevant results from all the relevant Mas. I think if you want to distinguish between tests during the first 15 minutes and the last 15 minutes, then you have two options - during data analysis, look at the timestamp in the results - or create two cycle-ids "tests-during-first-part-of-lmap-meeting" and "tests-during-last-part-of-lmap-meeting"

phil

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of MORTON, ALFRED C (AL)
Sent: 23 February 2016 16:02
To: Romascanu, Dan (Dan) <[email-masked]>; [email-masked]
Subject: Re: [lmap] 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):

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

> -----Original Message-----
> From: lmap [mailto:[email-masked]] On Behalf Of Romascanu, Dan
> (Dan)
> Sent: Tuesday, February 23, 2016 12:52 PM
> To: MORTON, ALFRED C (AL); [email-masked]
> Subject: Re: [lmap] First take on the Definition of Cycle_ID
> 
> By 'predictable and meaningful' you mean what?
> - some form of timestamp
> - some form of increasing integer index?
> or ....
> 
> Regards,
> 
> Dan
> 
> 
> > -----Original Message-----
> > From: lmap [mailto:[email-masked]] On Behalf Of MORTON, 
> > ALFRED C (AL)
> > Sent: Monday, February 22, 2016 9: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.
> >
> 
> 
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

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