Subject: Re: [lmap] some lmap result report model changes

From: <[email-masked]>
Date: Sat, 2 Apr 2016 13:30:34 +0000

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: 18 March 2016 07:54
To: [email-masked]
Subject: [lmap] some lmap result report model changes

2) It is almost impossible to implement 'conflict' on a per row
   level. The lmap scheduler can likely track which actions were
   running during the execution of an action but it surely does not
   know the internals of the action and hence it can't know how to
   determine conflicts on a per row level. Likewise, the measurement
   action does not know how to determine what else is going on on the
   system and related to the lmap framework. Hence, the conflict
   should be reported as part of ma-report-action-obj and not as a
   result row property.

[phil]
Let me see if I understand. 
A conflict means that something may have interfered /impacted the measurement results being reported, for example "cross traffic" is detected. I agree this isn't something that the scheduler knows about - it's detected by the MA at the time of the measurement. 
Ma-report-action-obj doesn't seem to exist? I guess ma-report-result-obj. 
This reports the meta-data for a single executed action. 
However, if I get it right an action can in fact consist of a series of measurements. Assuming these measurements are close in time then I think it's ok to report conflicts at the action rather than row level. For example, suppose the action was "measure the RTT to test server X by sending 10 test packets in quick succession", then I'd be interested in knowing there was cross-traffic sometime during the 10 pkts - knowing that test pkts 1, 2 and 8 suffered cross-traffic is probably too detailed 

Incidentally I think the draft could do with some example of the difference between action with several measurements (as in the RTT example) and a series of actions (measure the RTT every 10 minutes). Or at least the difference that we expect between these - I guess someone is free to treat my example as 10 actions, each of which sends 1 test packet. 

Thanks
phil

---

From: <[email-masked]>
Date: Sat, 2 Apr 2016 13:35:02 +0000

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: 18 March 2016 07:54
To: [email-masked]
Subject: [lmap] some lmap result report model changes

3) A measurement action may produce different result 'tables'. The
   assumption that there is a single header followed by a set of rows
   is too limited. We need to allow for a set of result 'tables'
   instead of a single one.

[phil]
If I get it right, this concerns where we want to report different subset of the results to different collectors. 
It would then be nice to have a table tailored for each collector. 
The alternative is one table, which has all the possible fields in the table columns but leaves some of the columns empty (for the results that a particular collector doesn't need). Both will work, but I agree it seems more elegant to have several tables, tailored for each collector.
If results are reported to only one collector, then I don't think you'd need more than one table. 

Thanks
phil

---

From: <[email-masked]>
Date: Sat, 2 Apr 2016 13:38:44 +0000

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: 18 March 2016 07:54
To: [email-masked]
Subject: [lmap] some lmap result report model changes

4) The description of ma-report-row-start-time and
   ma-report-row-end-time says that this timestamp is the start and
   the end of the action. If so, they should be reported as part of
   the ma-report-action-obj and not as part of the ma-report-row-obj.

[phil]
For an action that is a series of measurements (say 10 measurements of RTT to test server X, in rapid succession), then I think it makes sense to record the time of those individual measurements.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 2 Apr 2016 13:45:31 -0400

> From: lmap [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Saturday, April 02, 2016 9:39 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [lmap] some lmap result report model changes
> 
> For an action that is a series of measurements (say 10 measurements of
> RTT to test server X, in rapid succession), then I think it makes sense
> to record the time of those individual measurements.
> 
Right. One of the benefits of using IPPM metrics in general, and in this
case in particular, is that the set of info to report has already
been considered. Individual results like this are reported as 
the Time when the packet is sent from source to the server, and the RTT
metric from RFC2681 (and the Registry).

Al

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Apr 2016 14:39:50 +0200

> If results are reported to only one collector, then I don't think you'd need more than one table. 

This is a question of how the results are structured. You either have
a flexible table layout that allows tools to send results of different
measurements in one table or you have a more fixed table layout where
it is more natural to send multiple differently structured
tables. Since we do not any specific assumptions or recommendations, I
think it makes sense to support both.

/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: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Apr 2016 14:42:39 +0200

> For an action that is a series of measurements (say 10 measurements of RTT to test server X, in rapid succession), then I think it makes sense to record the time of those individual measurements.

I think stuff that happens "inside" of a measurement task (timing
details, observed cross traffic for certain packet trains, ...) should
go into the result tables and not into the meta data of the result
record.

/js