Subject: [lmap] Splitting measurement tasks into measurement tasks plus reporting tasks?

From: Steve Miller <[email-masked]>
Date: Mon, 11 Nov 2013 13:28:39 -0500

Hi.  I was thinking through some of the LMAP model, and to some extent doing so in the context of the (not entirely dissimilar) system we use within Verisign.  One thing that our internal system includes is some support for alert checking and generation, as a thing that can be separate from "pure" performance reporting.  I think that might be a useful capability to have in LMAP as well.

   In the framework, I'd think we'd represent that by breaking measurement tasks into two pieces.  The first piece would define just the actual measurement task; the second piece would be a separate reporting task, which would consume the results of the measurement task.  It'd be possible to feed the results of a measurement task into more than one reporting task.

   Let's look at the example from page 7 of http://www.ietf.org/id/draft-burbridge-lmap-information-model-01.txt:

 Example:  A Measurement Task Configuration may configure a single
      Measurement Task for measuring UDP latency.  The Measurement Task
      Configuration could define the destination port and address for
      the measurement as well as the duration, internal packet timing
      strategy and other parameters (for example a stream for one hour
      and sending one packet every 500 ms).  It may also define the
      output type and possible parameters (for example the output type
      can be the 95th percentile mean) where the measurement task
      accepts such parameters.  It does NOT define when the task starts
      (this is defined by the Measurement Schedule element), so it does
      not by itself instruct the MA to actually perform this measurement
      task.

Instead of this single measurement task, we'd have the "core" measurement task:

	Perform the UDP latency check against X every 500ms, between the hours of 10PM and 6AM; call this check "UDP-latency-X"

and then the reporting task implied above:

	Consume the output from measurement task "UDP-latency-X", reporting the 95th percentile mean once an hour; send that report to collector C1

and then we could also add a second reporting task:

	Consume the output from measurement task "UDP-latency-X", computing the exponentially-decaying average loss over the last 30 seconds.  If that loss exceeds 5%, report that immediately; do so to collector C2.  If the exponentially-decaying average loss over the last 30 seconds was in excess of 5% but now is less than 3%, report that immediately as well; do so to collector C2.

   Admittedly, for the regulator use case, I don't know how useful that is, though it seems that there would be some value in having devices that were about to note a SLA violation not wait for an extended period of time to inform the carrier that they are seeing issues.  I think that'd help a lot for the separate-but-overlapping use case I'd articulated previously, in which operators of heavily anycasted infrastructure are looking for devices located in a large number of ISPs that they can tell to check their view of the perfomance of those services, so that they can know that some corner of the Internet is having issues reaching them.

   I don't think this'd be too complicated to implement, either.

   Would this be worth considering?  If so, I'd be happy to draft some language around this.

	-Steve

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Nov 2013 21:42:18 +0100

>    Would this be worth considering?  If so, I'd be happy to draft some language around this.

I hear two suggestions here:

a) Give reporting channels their own independent schedule (right now
   they are essentially tied to the scheduled task).

b) Provide a means for post-processing raw data in order to derive
   certain statistics before the result is shipped via a report
   channel.

Is this a fair summary of the request?

/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: <[email-masked]>
Date: Tue, 12 Nov 2013 09:00:15 +0000

What we are discussing is already explicitly supported in exactly the way Steve has described. The Measurement Task has a schedule and feeds results into one or more reporting channels. These Report Channels then have their own configuration including a schedule in which to report.

The intention is that these report channels can also be used for logging/status/alert type information as well as measurement results.

Trevor.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Juergen Schoenwaelder
>Sent: 11 November 2013 20:42
>To: Steve Miller
>Cc: [email-masked]
>Subject: Re: [lmap] Splitting measurement tasks into measurement tasks plus
>reporting tasks?
>
>>    Hi.  I was thinking through some of the LMAP model, and to some extent
>doing so in the context of the (not entirely dissimilar) system we use within
>Verisign.  One thing that our internal system includes is some support for alert
>checking and generation, as a thing that can be separate from "pure"
>performance reporting.  I think that might be a useful capability to have in LMAP
>as well.
>>
>>    In the framework, I'd think we'd represent that by breaking measurement
>tasks into two pieces.  The first piece would define just the actual measurement
>task; the second piece would be a separate reporting task, which would consume
>the results of the measurement task.  It'd be possible to feed the results of a
>measurement task into more than one reporting task.
>>
>> 	Perform the UDP latency check against X every 500ms, between the
>hours of 10PM and 6AM; call this check "UDP-latency-X"
>>
>> 	Consume the output from measurement task "UDP-latency-X", reporting
>the 95th percentile mean once an hour; send that report to collector C1
>>
>> 	Consume the output from measurement task "UDP-latency-X",
>computing the exponentially-decaying average loss over the last 30 seconds.  If
>that loss exceeds 5%, report that immediately; do so to collector C2.  If the
>exponentially-decaying average loss over the last 30 seconds was in excess of 5%
>but now is less than 3%, report that immediately as well; do so to collector C2.
>>
>>    Admittedly, for the regulator use case, I don't know how useful that is, though
>it seems that there would be some value in having devices that were about to
>note a SLA violation not wait for an extended period of time to inform the carrier
>that they are seeing issues.  I think that'd help a lot for the separate-but-
>overlapping use case I'd articulated previously, in which operators of heavily
>anycasted infrastructure are looking for devices located in a large number of ISPs
>that they can tell to check their view of the perfomance of those services, so that
>they can know that some corner of the Internet is having issues reaching them.
>>
>_______________________________________________
>lmap mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/lmap

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Nov 2013 10:17:33 +0100

> The intention is that these report channels can also be used for logging/status/alert type information as well as measurement results.

OK. I stand corrected on a) since the channels include a scheduling
mechanism. Concerning status and logging, this is less clear to me
since there are now also separate channels for logging and status.
According to the framework, it seems the status information goes to
the controller not to the collector. The same seems to hold true for
logging information. Actually, I think the framework should be
clearer. Right now, it says:

   Control Protocol: The protocol delivering Instruction(s) from a
   Controller to a Measurement Agent.  It also delivers logging
   information and capabilities information from the Measurement Agent
   to the Controller.

This is pretty clear. But it is silent about status information (or is
capability information a subset of status information and hence it is
implicit that status information is included). Section 8.4.1 seems to
indicate that status is flowing from the MA to the Controller (and I
note that logging information does not seem to show up in the protocol
model). If the intention is that status and logging information goes
to the controller, then perhaps change this to:

   Control Protocol: The protocol delivering Instruction(s) from a
   Controller to a Measurement Agent.  It also delivers logging
   information, capability information and status information from the
   Measurement Agent to the Controller.

Do we need to define the terms logging information, capability
information and status information?

/js

---

From: <[email-masked]>
Date: Tue, 12 Nov 2013 10:15:56 +0000

Yes we probably do need to clear this up in the next iteration of the information model and architecture documents.

A Report Channel in the information model can be set with a URL of a Controller interface to report logging and status information. However, we probably should rename it.

Trevor.

>From: Juergen Schoenwaelder [mailto:[email-masked]]
>Sent: 12 November 2013 09:18
>To: Burbridge,T,Trevor,TUB8 R
>Cc: [email-masked]; [email-masked]
>> What we are discussing is already explicitly supported in exactly the way Steve
>has described. The Measurement Task has a schedule and feeds results into one
>or more reporting channels. These Report Channels then have their own
>configuration including a schedule in which to report.
>>
>> The intention is that these report channels can also be used for
>logging/status/alert type information as well as measurement results.
>>
>
>OK. I stand corrected on a) since the channels include a scheduling mechanism.
>Concerning status and logging, this is less clear to me since there are now also
>separate channels for logging and status.
>According to the framework, it seems the status information goes to the
>controller not to the collector. The same seems to hold true for logging
>information. Actually, I think the framework should be clearer. Right now, it says:
>
>This is pretty clear. But it is silent about status information (or is capability
>information a subset of status information and hence it is implicit that status
>information is included). Section 8.4.1 seems to indicate that status is flowing
>from the MA to the Controller (and I note that logging information does not seem
>to show up in the protocol model). If the intention is that status and logging
>information goes to the controller, then perhaps change this to:
>
>Do we need to define the terms logging information, capability information and
>status information?
>
>/js
>
>--

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Nov 2013 11:52:52 +0100

> A Report Channel in the information model can be set with a URL of a Controller interface to report logging and status information. However, we probably should rename it.

Now I am getting really confused. Do you believe status/logging is
going via the Report Channel??

/js

---

From: <[email-masked]>
Date: Tue, 12 Nov 2013 11:02:05 +0000

Not _the_ Report Channel, but _a_ Report Channel, yes. 

We already have multiple channels to split or duplicate measurement results so there is no problem re-using that part of the information model for the delivery of other data.

Trevor.

>Sent: 12 November 2013 10:53
>> A Report Channel in the information model can be set with a URL of a
>Controller interface to report logging and status information. However, we
>probably should rename it.
>>
>
>Now I am getting really confused. Do you believe status/logging is going via the
>Report Channel??
>
>/js
>
>--

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Nov 2013 12:10:10 +0100

> We already have multiple channels to split or duplicate measurement results so there is no problem re-using that part of the information model for the delivery of other data.

A report channel by definition delivers to a collector. So which
information do you think goes where? (I do not care about 'the' or 'a'
- I am lost somewhere else.)

/js

---

From: <[email-masked]>
Date: Tue, 12 Nov 2013 11:12:53 +0000

In the information model the report channel delivers information to a specified URL. I don't see why that can't be the Controller. Or if we want we can talk about the Controller having a Collector interface we can do that as well. This is all terminology.

As I said we need to tidy up some of the naming and definitions, but technically I don't see any problems - we designed it to work this way.

Trevor.

>Sent: 12 November 2013 11:10
>> We already have multiple channels to split or duplicate measurement results so
>there is no problem re-using that part of the information model for the delivery
>of other data.
>>
>
>A report channel by definition delivers to a collector. So which information do
>you think goes where? (I do not care about 'the' or 'a'

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Nov 2013 12:20:20 +0100

> As I said we need to tidy up some of the naming and definitions, but technically I don't see any problems - we designed it to work this way.

For me, this is not at all clear. In fact, the latest info model also
has a status channel and a logging channel. It is great if we can ship
stuff anywhere - but I think we would be even better off if we have a
clear view who should be the receiver / consumer of status and logging
information. I think this is actually an architectural question to
answer.

/js

---

From: Steve Miller <[email-masked]>
Date: Tue, 12 Nov 2013 13:56:11 -0500

I think that's close but I'm not quite sure it's right.  I think part of the gotcha here is that the spec tends to express Measurement Tasks as things that have a definite start and end time, while I'm thinking of things that are running continuously.

   That is, if we wanted to do a DNS query once a second, forever, the current model would express that more as:

	Measurement Task "DNS Performance": Perform a DNS loss/latency/jitter check once a second, for 300 seconds, reporting avg/min/max loss, latency and jitter plus a histogram of the latencies.

	Report Channel "Collector C": Report to collector at 0,5,10,15,20,25,30,35,40,45,50,55 minutes after the hour.

	Measurement Schedule: Run the Measurement Task "DNS Performance" at 0,5,10,15,20,25,30,35,40,45,50,55 minutes after the hour and report using Report Channel "Collector C".

but each of those reports has a very definite start and end time -- there's no way there to define a report via a rolling window.

   In the current framework, to get what I'm thinking about, I can *almost* do it, but I'd have to do that separately.  First, to get the performance numbers every five minutes, we'd have what's above, more or less:

	Measurement Task "DNS Performance": Perform a DNS loss/latency/jitter check once a second, for 300 seconds, reporting avg/min/max loss, latency and jitter plus a histogram of the latencies.

	Report Channel "Collector C 300Secs": Report to collector at 0,5,10,15,20,25,30,35,40,45,50,55 minutes after the hour.

	Measurement Schedule: Run the Measurement Task "DNS Performance" at 0,5,10,15,20,25,30,35,40,45,50,55 minutes after the hour and report using Report Channel "Collector C 300Secs".

and then to get some sort of report immediately, it seems like about as close as we'd get would be:

	Measurement Task "DNS Badness": Perform a DNS loss/latency/jitter check once a second, for 300 seconds, reporting avg/min/max loss, latency and jitter immediately if the loss is worse than 1%, the latency is more than 200ms, or the jitter is more than 200ms.

	Report Channel "Collector C 1Sec": Report to collector once a second.

	Measurement Schedule: Run the Measurement Task "DNS Badness" at 0,5,10,15,20,25,30,35,40,45,50,55 minutes after the hour and report using Report Channel "Collector C 1Sec".

which has a couple of issues:

	- now we're sending twice as much traffic to each destination as we were before (which in this example isn't such a big deal but it's not hard to imagine that a file-download test or an RTP test wouldn't be so forgiving (-: )

	- it's not truly a rolling window, so you either have to clamp the accelerated reporting until you have enough baseline to be useful (that is, you don't want to report "OMG! 100% loss!"  if just the first packet is lost) or you have to put up with noisy reports

	- I think the collector gets a report every second, even if that report is empty

   Maybe a way to look at this would be to have the concepts of:

	- never-ending measurements, which run continuously

and

	- async report channels, where you could express simple conditions to control whether or not a report occurs

or maybe async report channels are really some sort of async measurement schedule:

	Run the test named "DNS Badness" continuously; report using the channel "Collector C" whenever loss is more than 1% or the latency is more than 200ms or the jitter is more than 200ms over the last 300 seconds.

   I could be convinced that I'm thinking too hard about this or that my perception of the measurement model as viewing Measurement Tasks as discrete things with discrete start times and durations is simply incorrect.

   Did that make anything more clear?

   Also, to address some of what you and Trevor were discussing: I don't know that I necessarily regard these async reports as logging or status.  I think they're closer to "normal" reports, they just happen asynchronously.  I could be convinced to treat this as logging or status, too, if that'd be helpful somehow.

	-Steve

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Nov 2013 20:25:55 +0100

I think you touch on several issues:

a) Are reports send if nothing is pending to be reported?

   I think the answer should be no but this can be discussed.

b) Should we support a notion of filters that can be applied, that is
   only result records passing a filter expression are actually reported.

c) In a previous email, someone suggested to have aggregation
   functions that can be applied generically to test results
   (e.g., calculation of avg, min, max, ...).

d) Should we support a report timing that kind of says "report
   immediately if a result record is available"

These are all fair questions one can ask and it is going to be a
trade-off between simplicity and functional richness. Perhaps we need
to look at what deployed systems really do so we do not get over board
building aggregation and filtering features into the model that can
also easily be applied on the collector's end.

/js

---

From: <[email-masked]>
Date: Wed, 13 Nov 2013 08:53:41 +0000

(d) we have in the information model.

(a)-(c) are interesting questions. (a) could always be a configurable parameter. (b) and (c) I've kept away from for reasons of complexity, but they could be useful tools. My initial reaction is that we don't need pre-processing as (i) the amount of data returned is not likely to be huge in most scenarios; (ii) some of this can be done within the test - for example a stream of ping packets can be a single measurement and report avg, min, max etc.

Trevor.

>Sent: 12 November 2013 19:26
>To: Steve Miller
>Cc: [email-masked]
>>    I think that's close but I'm not quite sure it's right.  I think part of the gotcha
>here is that the spec tends to express Measurement Tasks as things that have a
>definite start and end time, while I'm thinking of things that are running
>continuously.
>>
>> 	Measurement Task "DNS Performance": Perform a DNS
>loss/latency/jitter check once a second, for 300 seconds, reporting avg/min/max
>loss, latency and jitter plus a histogram of the latencies.
>>
>> 	Report Channel "Collector C": Report to collector at
>0,5,10,15,20,25,30,35,40,45,50,55 minutes after the hour.
>>
>> 	Measurement Schedule: Run the Measurement Task "DNS Performance"
>at 0,5,10,15,20,25,30,35,40,45,50,55 minutes after the hour and report using
>Report Channel "Collector C".
>>
>> but each of those reports has a very definite start and end time -- there's no
>way there to define a report via a rolling window.
>>
>>    In the current framework, to get what I'm thinking about, I can *almost* do
>it, but I'd have to do that separately.  First, to get the performance numbers every
>five minutes, we'd have what's above, more or less:
>>
>> 	Measurement Task "DNS Performance": Perform a DNS
>loss/latency/jitter check once a second, for 300 seconds, reporting avg/min/max
>loss, latency and jitter plus a histogram of the latencies.
>>
>> 	Report Channel "Collector C 300Secs": Report to collector at
>0,5,10,15,20,25,30,35,40,45,50,55 minutes after the hour.
>>
>> 	Measurement Schedule: Run the Measurement Task "DNS Performance"
>at 0,5,10,15,20,25,30,35,40,45,50,55 minutes after the hour and report using
>Report Channel "Collector C 300Secs".
>>
>> 	Measurement Task "DNS Badness": Perform a DNS loss/latency/jitter
>check once a second, for 300 seconds, reporting avg/min/max loss, latency and
>jitter immediately if the loss is worse than 1%, the latency is more than 200ms, or
>the jitter is more than 200ms.
>>
>> 	Measurement Schedule: Run the Measurement Task "DNS Badness" at
>0,5,10,15,20,25,30,35,40,45,50,55 minutes after the hour and report using
>Report Channel "Collector C 1Sec".
>>
>> 	- now we're sending twice as much traffic to each destination as we were
>before (which in this example isn't such a big deal but it's not hard to imagine that
>a file-download test or an RTP test wouldn't be so forgiving (-: )
>>
>> 	- it's not truly a rolling window, so you either have to clamp the
>accelerated reporting until you have enough baseline to be useful (that is, you
>don't want to report "OMG! 100% loss!"  if just the first packet is lost) or you have
>to put up with noisy reports
>>
>> 	Run the test named "DNS Badness" continuously; report using the
>channel "Collector C" whenever loss is more than 1% or the latency is more than
>200ms or the jitter is more than 200ms over the last 300 seconds.
>>
>>    I could be convinced that I'm thinking too hard about this or that my
>perception of the measurement model as viewing Measurement Tasks as discrete
>things with discrete start times and durations is simply incorrect.
>>
>>    Also, to address some of what you and Trevor were discussing: I don't know
>that I necessarily regard these async reports as logging or status.  I think they're
>closer to "normal" reports, they just happen asynchronously.  I could be
>convinced to treat this as logging or status, too, if that'd be helpful somehow.
>>
>> 	-Steve
>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 14 Nov 2013 13:35:20 +0100

Trevor,

concerning (b) and (c), I think we should not consider this as a
requirement for LMAP 1.0 but perhaps we should consider how such
filtering and processing steps could be added in a later version of
LMAP. In other words, we may want to think about how we can make the
information model extensible such that (b) and (c) could be added
nicely in a later phase.

/js

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Thu, 14 Nov 2013 12:40:01 +0000

>From a functional perspective the Controller interface needs tighter security controls (Keys), but the collectors do not.
To that effect splitting them makes good sense to me.

  If that's too difficult up front, it just makes implementation more difficult and costly.

Just my 2 cents...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, November 14, 2013 6:35 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [lmap] Splitting measurement tasks into measurement tasks plus reporting tasks?

Trevor,

concerning (b) and (c), I think we should not consider this as a requirement for LMAP 1.0 but perhaps we should consider how such filtering and processing steps could be added in a later version of LMAP. In other words, we may want to think about how we can make the information model extensible such that (b) and (c) could be added nicely in a later phase.

/js

On Wed, Nov 13, 2013 at 08:53:41AM +0000, [email-masked] wrote:
> >From: [email-masked] [mailto:[email-masked]] On Behalf 
> >Of Juergen Schoenwaelder
> >Subject: Re: [lmap] Splitting measurement tasks into measurement 
> >tasks plus reporting tasks?
> >
> >to look at what deployed systems really do so we do not get over 
> >board building aggregation and filtering features into the model that 
> >can also easily be applied on the collector's end.
> >
> >/js
> >
> >here is that the spec tends to express Measurement Tasks as things 
> >that have a definite start and end time, while I'm thinking of things 
> >that are running continuously.
> >>
> >>    That is, if we wanted to do a DNS query once a second, forever, 
> >> the current
> >model would express that more as:
> >>
> >loss/latency/jitter check once a second, for 300 seconds, reporting 
> >avg/min/max loss, latency and jitter plus a histogram of the latencies.
> >>
> >at 0,5,10,15,20,25,30,35,40,45,50,55 minutes after the hour and 
> >report using Report Channel "Collector C".
> >>
> >it, but I'd have to do that separately.  First, to get the 
> >performance numbers every five minutes, we'd have what's above, more or less:
> >>
> >loss/latency/jitter check once a second, for 300 seconds, reporting 
> >avg/min/max loss, latency and jitter plus a histogram of the latencies.
> >>
> >at 0,5,10,15,20,25,30,35,40,45,50,55 minutes after the hour and 
> >report using Report Channel "Collector C 300Secs".
> >>
> >> and then to get some sort of report immediately, it seems like 
> >> about as close as
> >we'd get would be:
> >>
> >check once a second, for 300 seconds, reporting avg/min/max loss, 
> >latency and jitter immediately if the loss is worse than 1%, the 
> >latency is more than 200ms, or the jitter is more than 200ms.
> >>
> >0,5,10,15,20,25,30,35,40,45,50,55 minutes after the hour and report 
> >using Report Channel "Collector C 1Sec".
> >>
> >before (which in this example isn't such a big deal but it's not hard 
> >to imagine that a file-download test or an RTP test wouldn't be so 
> >forgiving (-: )
> >>
> >accelerated reporting until you have enough baseline to be useful 
> >(that is, you don't want to report "OMG! 100% loss!"  if just the 
> >first packet is lost) or you have to put up with noisy reports
> >>
> >> 	- I think the collector gets a report every second, even if that 
> >> report is
> >empty
> >>
> >> 	- async report channels, where you could express simple conditions 
> >> to
> >control whether or not a report occurs
> >>
> >> or maybe async report channels are really some sort of async 
> >> measurement
> >schedule:
> >>
> >channel "Collector C" whenever loss is more than 1% or the latency is 
> >more than 200ms or the jitter is more than 200ms over the last 300 seconds.
> >>
> >perception of the measurement model as viewing Measurement Tasks as 
> >discrete things with discrete start times and durations is simply incorrect.
> >>
> >that I necessarily regard these async reports as logging or status.  
> >I think they're closer to "normal" reports, they just happen 
> >asynchronously.  I could be convinced to treat this as logging or status, too, if that'd be helpful somehow.
> >>
> >> 	-Steve
> >>

---

From: <[email-masked]>
Date: Wed, 27 Nov 2013 17:00:39 +0000

I take two questions from this discussion:

1. can a Measurement Task run indefinitely?
2. can a single Measurement Task create more than one Measurement Report? (for instance, one the long term average, the other an immediate alarm that a parameter has gone below a threshold, say)

1. I think this just needs some explanatory text on these lines:
The Controller may want a MA to run the same Measurement Task indefinitely (for example, "run the 'upload speed' Measurement Task once an hour until further notice"). To avoid the MA generating traffic forever after a Controller has permanently failed, it is suggested that the Measurement Schedule includes a time limit ("run the 'upload speed' Measurement Task once an hour for the next 30 days") and that the Measurement Schedule is updated regularly (say, every 10 days).

Does this work?

2. think this needs a bit more discussion. I can see it might be useful (if we have a strict 1:1 Task:Result, then the example above would need 2 Tasks and hence 2 lots of data to be sent. For some Tasks this would be ok, for others not). So I'm OK if people think it won't add too much complexity to the Information Model and Protocol. 

(Incidentally this is in tension with the email "Only Report raw measurement results". Perhaps we could instead describe this as two linked Tasks (each with one Result) which in fact create only one pkt stream; perhaps this is just confusing.) 

Thoughts?

Thanks
phil

> Steve Miller
> Sent: 12 November 2013 18:56
> To: [email-masked]
>    I think that's close but I'm not quite sure it's right.  I think
> part of the gotcha here is that the spec tends to express Measurement
> Tasks as things that have a definite start and end time, while I'm
> thinking of things that are running continuously.
> 
>    That is, if we wanted to do a DNS query once a second, forever, the
> current model would express that more as:
> 
> at 0,5,10,15,20,25,30,35,40,45,50,55 minutes after the hour and report
> using Report Channel "Collector C".
> 
> but each of those reports has a very definite start and end time --
> there's no way there to define a report via a rolling window.
> 
>    In the current framework, to get what I'm thinking about, I can
> *almost* do it, but I'd have to do that separately.  First, to get the
> at 0,5,10,15,20,25,30,35,40,45,50,55 minutes after the hour and report
> using Report Channel "Collector C 300Secs".
> 
> 	- now we're sending twice as much traffic to each destination as
> we were before (which in this example isn't such a big deal but it's
> not hard to imagine that a file-download test or an RTP test wouldn't
> be so forgiving (-: )
> 
> accelerated reporting until you have enough baseline to be useful (that
> is, you don't want to report "OMG! 100% loss!"  if just the first
> packet is lost) or you have to put up with noisy reports
> 
> report is empty
> to control whether or not a report occurs
> 
> measurement schedule:
>    I could be convinced that I'm thinking too hard about this or that
> my perception of the measurement model as viewing Measurement Tasks as
>    Also, to address some of what you and Trevor were discussing: I
> don't know that I necessarily regard these async reports as logging or
> status.  I think they're closer to "normal" reports, they just happen
> asynchronously.  I could be convinced to treat this as logging or
> status, too, if that'd be helpful somehow.
> 
> 	-Steve
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Nov 2013 08:09:10 +0100

Hi,

I think instructions must be considered some sort of soft state in
general. An MA that for whatever reason looses connectivity to the
controller for a very long time or permanently should stop doing
measurements at some point in time and not continue indefinitely.

Concerning the second point, I do not really see a problem with
allowing a measurement task to create multiple result records.  I can
see that this is useful and easy to implement. I do not see how not
allowing this would simplify anything.

/js

---

From: Steven Miller <[email-masked]>
Date: Sat, 30 Nov 2013 17:07:08 -0500

Funny that I just sent Phil private mail where I described the 
heartbeat system (and related auto-shutdown logic) we'd put in place and 
how it proved largely to be much more trouble than it was worth...  Our 
stuff shut down after 10 minutes or so of not hearing from our 
equivalent of a controller, on the theory that maybe we'd botched a 
measurement definition and eaten all the bandwidth.  Until we cranked 
that particular timer it was pretty easy for us to get false positives.  
I wouldn't be averse to something taking itself offline if it's gone for 
an extended period without reaching its controller, or at least maybe 
after a few days -- longer than a typical service outage? -- it stops 
doing tests until it succeeds in reaching the controller.

     -Steve