Subject: Re: [lmap] Calculation of Cycle-Number

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Jul 2016 15:00:09 +0200

On Mon, Jun 27, 2016 at 09:19:50PM -0400, MORTON, ALFRED C (AL) wrote:
> LMAP,
> 
> At the latest Interim meeting, I agreed to prepare text that
> calculates the variable part of a Cycle-ID. This is planned
> to be the numeric index to a specific *recurring* event, 
> or cycle among many cycles in the results.
> We are referring to the numeric part as Cycle-Number.
> (The other part of Cycle-ID is the Cycle-Context-ID, which 
> can be alphanumeric and is not intended to be modified at the MA 
> or elsewhere.)
> 
> See the meeting notes for further background:
> https://www.ietf.org/proceedings/interim/2016/06/13/lmap/minutes/minutes-interim-2016-lmap-3
> 
> I propose to calculate the Cycle-Number based on the time and 
> date of each recurring schedule event, which is a component of
> the Measurement Schedule. The MA has to calculate the time and
> date of each recurring schedule event, and may use its own format. 
> See below for generation of a Cycle-Number.
> Measurement Actions may be aligned with event time or have
> some random time offset.
> 
> Since the LMAP Collector does not possess the Measurement Schedule
> as described in Section 5.4 of RFC 7594,
> it has no knowledge of recurring event time and dates, and
> cannot perform the same calculation. Section 8.4.2 of RFC 7594
> identifies the Measurement Schedule as sensitive information,
> so this should remain as described by the LMAP Framework.
> 
> For a Collector to infer the Cycle-Number 
> from the time and date of Measurement Results, the Collector
> needs to know the times of recurring schedule events, 
> or at least: one of the event times, 
> the duration of the recurring event, and
> confirmation that the event timing has not been changed
> (changes may be needed to avoid an attacker who intends to
> bias the measurements). According to the LMAP Framework,
> the Collector has none of this information.
> 
> Even if the Collector has information necessary to infer the 
> Cycle-Number, its calculations can be subject to errors from
> the following sources:
> 
> * There may be overlapping measurements from concurrent 
>   recurring schedules (which would likely use different cycle
>   durations, referenced to different recurring events). 
> * There may be a 'wait for X' step in a measurement task that
>   causes an Action/Measurement to be delayed such that the 
>   actual measurement time occurs in a subsequent cycle.
> 
> with inference of the wrong Cycle-number as the result.
> Overlapping Measurements are described in Section 5.3.2 of RFC 7594.
> 
> Measurement Time alone does not lead to the correct 
> recurring schedule event for calculation of the Cycle-Number.
> 
> 
> -=-=-=-=-=- Note: there are many date, time and datetime formats
> in various languages, this is a simple approximation -=-=-=-=-=-=-=
> 
> The MA calculates that the next recurring event will occur on
> Date = YYYY-MM-DD, at Time = HHMMSS, according to information 
> from the Controller.
> 
> A simple Cycle-Number can be formed by converting the date and
> time to strings, and concatenating the strings:
> 
> Cycle-Number = print( str(Date) + "-" + str(Time) ) #possibly truncate time to HHMM
> 
> All MAs have synchronized clocks, so they all produce the same
> Cycle-Number and report it with the measurement results for that
> recurring event when they are operating on the same recurring schedule.
>

Hm. How is this different from sending the date-and-time of the event
that triggered the execution of a schedule? YANG uses the RFC 3339
profile of the ISO 8601 format, that is, YYYY-MM-DDTHH:MM:SS+00:00 (if
you are operating in UTC). This is what I suggested before but somehow
I thought during the interim that you wanted something that

(a) is purely numeric and
(b) has a sufficiently course grained resolution and
(c) hides all randomization effects

and hence for this one would have to configure a resolution and then
round down the actual event time-stamp according to the configured
resolution and then report the result as a number, e.g. YYYYMMDDHHMMSS
(where some portions at then end may always be zero depending on the
configured resolution, e.g., if I set the resolution to 5 minutes
than of course SS will always be 00).

I guess (since you are not explicitely writing it) that you assume the
next recurring event is precise to calculate and not impacted by any
variation due to randomization or simply exceution delays and hence
multiple systems will come up with the same cycle number. Frankly,
this is not the case even with your proposal. Consider simple periodic
schedules; they will have a defined interval but not necessarily a
defined and thus synchronized start time. So multiple systems
executing the same periodic schedules will not give you the
predictable cycle numbers you are looking for.

If we were to go with an approach where you configure a
cycle-number-resolution in seconds and then you calculate a numeric
cycle-number as outlined above, then the questions are whether this is
a global configuration knob or whether different ma-schedule-obj's can
have different cycle-number-resolutions or whether such a
cycle-number-resolution is even seen as a property of an event source
(which may make sense since the event configuration really determins
what a suitable cycle-number-resolution value is).

/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: Wed, 13 Jul 2016 14:30:57 -0400

Hi Juergen,

I think we can agree on some simple format for this
(mostly) numeric part of the Cycle-ID.  In the community
definition-writing, the Cycle-ID was split in two parts
and here we are focusing on what we called the numeric part. 
I have no objection to a minimal number of alpha characters,
and "." is needed in both alpha and numeric, 
so converting an internal date and time to YYYYMMDD.HHMM 
would satisfy the use case I've described previously.

We could define one exact format for the cycle number,
and call it "type 1" in case folks want to extend to 
different format later. Or define the resolution as you 
suggested, perhaps as a property of an event where resolution
could be aligned with the repeating interval.

You've raised the issue of synchronizing the repeating events
among all the MAs using the same schedule, these produce measurement
results we wish to easily associate later with the Cycle-ID. 
The periodic events need to have a defined interval (duration)
and a defined, synchronized start time. Schedule events 
seem to have both available:

       +--rw events
          +--rw event* [name]
             +--rw name                    lmap:identifier
             +--rw (event-type)?
             |  +--:(periodic)
             |  |  +--rw periodic
             |  |     +--rw interval    uint32
             |  |     +--rw start?      yang:date-and-time
             |  |     +--rw end?        yang:date-and-time

The recurring Actions performed for each event can be affected 
variation due to randomization or execution delays.
Hence, each Action should have the Cycle-ID assigned
as soon as it is calculated & formatted, at the start
of the event, or an Action unexpectedly delayed could be
assigned the subsequent Cycle-ID.

hope this helps,
Al

PS: I'd prefer not to use the RFC 3339
profile of the ISO 8601 format directly, 
YYYY-MM-DDTHH:MM:SS+00:00

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Tuesday, July 05, 2016 9:00 AM
> To: MORTON, ALFRED C (AL)
> Cc: [email-masked]
> Subject: Re: [lmap] Calculation of Cycle-Number
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 19 Jul 2016 10:22:56 +0200

Al,

I think we either encode the cycle number as an RFC 3339 date and time
value or as a number, perhaps even seconds since 1st Jan 1970. I do
not see which problem we solve by introducing yet another encoding _at
the data exchange between an MA and a Collector_. How the collector
stores data in its database is a Collector's implementation detail. I
guess my preference really is the RFC 3339 date and time format since
almost all programming languages have functions to deal with this
format. Many databases also understand this format.

While the format is one sub-issue, the other sub-issue is how exactly
the cycle number is calculated. I asked question in a prior post about
details [1] (e.g., where the resolution should be configured) but got
no response.

I think we should leave Berlin with a concrete solution on the table
that people agree on or we drop the cycle number altogether (and leave
it to the Collector to calculate a cycle number from the timestamps
included in the reports).

/js

[1] https://mailarchive.ietf.org/arch/search/?email_list=lmap

On Wed, Jul 13, 2016 at 02:30:57PM -0400, MORTON, ALFRED C (AL) wrote:
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 21 Jul 2016 08:59:48 -0400

Hi Juergen,

It seems that each recurring event has a time associated with it,
and that all event times can be calculated based on the 
start time of the first event and the period, so that the MA knows 
when to begin each set of Actions that are part of the recurring event.
(IOW, I can schedule recurring events to start at HH:00, HH:15, HH:30, HH:45
on all Mas where I want to use Cycle-ID.)

Since the MA knows each recurring event time, it can calculate 
the numeric part of the Cycle-ID. Each event time would be present 
in some OS-dependent format, and available for reduction to 
the desired resolution.

My colleagues want the numeric part pf Cycle-ID to be easy to type
as part of a query, so that's why the numeric format(s) I keep using
are short, numeric, and avoid a lot of separation characters. 
The calculation and format they want is as simple as

$ date "+%Y%m%d.%H%M"
20160711.1800            (this is fully numeric)

for the recurring event beginning at 6pm on July 11, 2016.
Other MA OS may need to apply additional formatting to 
produce the YYYYMMDD.HHMM result.

I don't find seconds since 1st Jan 1970 to be meaningful to 
someone typing a query, and RFC 3339  YYYY-MM-DDTHH:MM:SS+00:00
is certainly more than needed.

I'm willing to live with a single format and resolution, so
I don't need the resolution to be variable based on the repeating 
period of the recurring events. The Collector should simply indicate
that Cycle-ID is to be included with the results of each Action
in the recurring event schedule.

In previous versions of the Information Model, we had cycle-id
in ma-task-obj and ma-report-task-object, for example:

     object {
         string                       ma-task-name;
         ma-metric-registry-obj       ma-task-metrics<0..*>;
        [ma-option-obj                ma-task-options<0..*>;]
        [boolean                      ma-task-suppress-by-default;]
        [string                       ma-task-cycle-id;]
     } ma-task-obj;

I'm not sure if this is still the best way for the Controller to
indicate that the option to use cycle-id is wanted, but it is 
a starting point.

I've covered the desired calculation, format, and how the Controller 
indicates the need for cycle-id calculation and inclusion with the
results, subject to further discussion.

I'm willing to meet and discuss the topic further today, face to face,
with anyone still here at IETF. Suggest a time.

regards,
Al

> Sent: Tuesday, July 19, 2016 4:23 AM
> > > > Cycle-Number = print( str(Date) + "-" + str(Time) ) #possibly
> truncate
> > > time to HHMM
> > > >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jul 2016 15:36:14 +0200

> in some OS-dependent format, and available for reduction to 

This is not as simple as in the example since you can create way more
complex recurring schedules. There is not necessarily a natural
'cycle-number interval' for the schedules we allow - or they may be
tough to calculate. For example, you can schedule to run something on
every Friday 13th. What is the 'cycle-number interval' for such a
recurring schedule and how do I calculate it?

> produce the YYYYMMDD.HHMM result.

I think our focus is which data is exchanged over the network and how
it is encoded while traveling over the network. We are not designing a
user interface. If a Collector receives data from an MA, then it needs
to stick the data somewhere (e.g. some form of a database). Since I do
not think we assume human Collectors, the data formats should make it
easy to process the data and to stick it in databases.

> in the recurring event schedule.

I think our disconnect is how a user accesses data stored in a
Collector's database and how we encode data shipped from an MA to a
Collector.

> indicate that the option to use cycle-id is wanted, but it is 

This was the cycle-id as described in section 3 of RFC 7594, namely a
tag value. This has been replaced by a general tagging mechanism.
The cycle-number is an idea that was proposed later and right now
I am not sure how an MA would know when to generate one and how to
infer the cycle-number

> with anyone still here at IETF. Suggest a time.

What about 6pm at one of the tables in the Wintergarten?

/js

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 21 Jul 2016 10:44:27 -0400

Hi Juergen,

I'm clearly talking about periodic events (cyclic), and if we
need to restrict the scope to periodic only, that's fine with me.
We could calculate the numeric part of a cycle-id for an event on
"Friday the 13th", and it would have a 13 in it, but this doesn't
help anyone, AFAICT.

I also want the Collector to receive the results and stick it 
in databases. Database searches/queries benefit from indexes, 
and cycle-id is the index that we've already found useful in a 
large-scale measurement system. I want to add that index with
the results, so that ingestion can be efficient.

It's almost never mentioned in discussion that we are designing a 
system for large scale deployment. The MA has autonomy and probably some 
spare cycles before measurements start, so it can calculate a 
cycle-id. The Collector is an aggregation point serving many MAs
and we need to conserve its processing, IMO. Sending results in
a form ready for ingestion seems most efficient there.

I realize this definition of cycle-id has expanded functionality
from the original, but when I had to write and present the topic
to get the concept restored in the information model, I tried to 
write a more direct replacement for the database index our 
measurement systems use now.

> What about 6pm at one of the tables in the Wintergarten?

Ok, That's where we'll meet, see you then, anyone else on the
list with opinions is welcome too.

Al

> Sent: Thursday, July 21, 2016 9:36 AM

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jul 2016 17:03:24 +0200

> a form ready for ingestion seems most efficient there.
 
The calculation itself is hardly keeping any CPU busy (compared to
everything else coing on). I think we are effectively talking about
this (in Python syntax)

  cyclno = secs - (secs % itv)

where secs is the event time in seconds since epoch and itv is the
cycle-interval in seconds. This should be trivial to do for any
collector.

If we distribute this calculation (I remain personally unconvinced
that this is necessary but I will not object to this if people feel
strongly that the above calculation is too hard to scale on a
collector) then it needs to be clear to all MAs how to obtain the itv
value. BTW, what I find more seriously missing in the report is the
(recurring) event time without the optionally added randomization.
This would be a useful addition to the report since there is currently
no way to obtain the randomization that was added. (And if you want to
calculate a cycle-number, you likely want the event time without any
randomization added. Am I correct here Al?

> measurement systems use now.

And this is appreciated, Al. But things are a bit more complex then
they may appear to you and thus I kept pushing for more details.

> list with opinions is welcome too.

Cool, see you in about an hour.

/js

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 21 Jul 2016 11:49:08 -0400

Hi Juergen,

As you just said,
> ... BTW, what I find more seriously missing in the report is the

This is one of the reasons the MA should do the calculation,
the details of the schedule including events are not sent to the
Collector.  This was part of my rationale in the message that started
the thread:
Al> Since the LMAP Collector does not possess the Measurement Schedule
Al> as described in Section 5.4 of RFC 7594,
Al > it has no knowledge of recurring event time and dates, and
Al > cannot perform the same calculation. Section 8.4.2 of RFC 7594
Al > identifies the Measurement Schedule as sensitive information,
Al > so this should remain as described by the LMAP Framework.

> randomization added. Am I correct here Al?

Yes, I want to calculate the cycle-number based on each recurring event time
without any randomization added.

But the MA has to do the calculation, for all the reasons I gave in
my first message to this thread (which seems to be missing from the archive,
but Juergen's first reply is there...)

Al

> Sent: Thursday, July 21, 2016 11:03 AM

---

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

I met Al today and the outcome is that we have a concrete proposal
for the cycle-number.

a) We add ma-event-cycle-interval as an optional element to ma-event-obj.

   ma-event-cycle-interval:        The optional ma-event-cycle-interval
                                   defines the duration of the time
                                   interval in seconds that is used to
                                   calculate cycle numbers.  No cycle
                                   number is calculated if ma-event-
                                   cycle-interval does not exist.

b) We add ma-report-result-event-time as a non-optional element to
   ma-report-result-obj.

   ma-report-result-event-time:    The date and time of the event that
                                   triggerent the schedule of the action
                                   that produced the reported result
                                   values.  The date and time does not
                                   include any added randomization.

c) We add ma-report-result-cycle-number as an optional element to
   ma-report-result-obj.

   ma-report-result-cycle-number:  An optional cycle number derived from
                                   ma-report-result-event-time.  It is
                                   the time closest to ma-report-result-
                                   event-time that is a multiple of the
                                   ma-event-cycle-interval of the event
                                   that triggered the execution of the
                                   schedule.  The value is only present
                                   in an ma-report-result-obj if the
                                   event that triggered the execution of
                                   the schedule has a defined ma-event-
                                   cycle-interval.  The cycle number is
                                   represented in the format
                                   YYYYMMDD.HHMMSS where YYYY represents
                                   the year, MM the month (1..12), DD
                                   the day of the months (01..31), HH
                                   the hour (00..23), MM the minute
                                   (00..59), and SS the second (00..59).

/js