Subject: [lmap] Information Model suggested modifications

From: <[email-masked]>
Date: Mon, 2 Dec 2013 10:31:17 +0000

For the forthcoming edit of the Information Model I have been collecting suggestions. Aside from the ones dealing with readability, corrections, explanations, examples and alignment with the Framework draft, I have the following suggested amendments:

1) Implementation of status/logging as just another Measurement Task reporting on just another (if desired) reporting Channel. In nomenclature terms this would still go to a Collector, but the Controller is able to implement a Collector interface of its own if it needs this information.

2) Allow Measurement Tasks multiple outputs than can be separated onto multiple Channels. This would allow error output to be separated for example or for alarms to be escalated immediately. Simple change and already adopted into the Framework

3) Extend Interface choice to Channels as well as Measurement Tasks. This would, for example, allow a report or an alarm to be sent over GPRS or other interface.

4) Add Boolean "send null reports" to Channel information. Allows the suppression of empty reports or choice to receive empty reports for heartbeat purposes.

5) Add selection of either "UTC" or "local time" to the Schedule. The support of local time is needed, for example, for the probe to manage its own schedule through daylight changing or to test within a defined peak or evening period.

6) Give example of a Channel to a local datastore that can be used by a Measurement Task for alarms or aggregate statistics. No changes to the Information Model itself except: we would need to define when the data expires on these local datastores. Need to add the concept of a datastore and an expiry either as "max storage size" or "retention period".

The one that I am still tracking but isn't yet formed enough to be included:

A) Include a definition of a way to suppress or back-off measurements/reports if the controller/collector is unreachable.

If I don't hear any objections then I'll go ahead and include 1-6.

Trevor Burbridge

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 2 Dec 2013 12:52:06 +0100

Trevor,

with this becoming a WG document, I think this needs to go to the lmap
WG mailing list. For me, it is not clear how much change the various
items involve - so it is hard to say something. For example 2), how do
you identify the multiple outputs and map them to different channels?

Concerning 1), this is really for tracking state in order to do proper
data analysis later on. I am not sure this is the right thing to do in
order to let the controller know how to set proper parameters for a
give probe.

/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: Mon, 2 Dec 2013 12:53:21 +0100

On Mon, Dec 02, 2013 at 12:52:06PM +0100, Juergen Schoenwaelder wrote:
> WG mailing list. 

Oops, this is on the lmap mailing list. Good. I guess my brain is still
not fully awake. Monday morning problem. Sorry,

/js

---

From: <[email-masked]>
Date: Mon, 2 Dec 2013 12:04:48 +0000

>-----Original Message-----
>From: Juergen Schoenwaelder [mailto:[email-masked]]
>Sent: 02 December 2013 11:52
>To: Burbridge,T,Trevor,TUB8 R
>Cc: [email-masked]; Eardley,PL,Philip,TUB8 R; [email-masked]
>Subject: Re: Information Model suggested modifications
>
>Trevor,
>
>with this becoming a WG document, I think this needs to go to the lmap WG
>mailing list. For me, it is not clear how much change the various items involve - so
>it is hard to say something. For example 2), how do you identify the multiple
>outputs and map them to different channels?

I think this is a simple change. Instead of specifying a single Channel in the Measurement Task Schedule there will instead be an array of Channels. First measurement task output will go to the first Channel etc. 

Instead of just an array of Channels, I could use a List of OutputID: Channel pairs but I think this is unnecessary complexity as the OutputID would just be a positive integer in any case.

>Concerning 1), this is really for tracking state in order to do proper data analysis
>later on. I am not sure this is the right thing to do in order to let the controller
>know how to set proper parameters for a give probe.

I'm just suggesting that everything that is 'pushed' from the probe can be defined by a Measurement Task. That includes what sync rate, if the Hub has powered up, memory errors etc. as well as classic measurement results. We don't need to define where it goes to as that will be left to the specific measurement system embodiment.

>> For the forthcoming edit of the Information Model I have been collecting
>suggestions. Aside from the ones dealing with readability, corrections,
>explanations, examples and alignment with the Framework draft, I have the
>following suggested amendments:
>>
>> 1) Implementation of status/logging as just another Measurement Task
>reporting on just another (if desired) reporting Channel. In nomenclature terms
>this would still go to a Collector, but the Controller is able to implement a
>Collector interface of its own if it needs this information.
>>
>> 2) Allow Measurement Tasks multiple outputs than can be separated onto
>> multiple Channels. This would allow error output to be separated for
>> example or for alarms to be escalated immediately. Simple change and
>> already adopted into the Framework
>>
>> 3) Extend Interface choice to Channels as well as Measurement Tasks. This
>would, for example, allow a report or an alarm to be sent over GPRS or other
>interface.
>>
>> 4) Add Boolean "send null reports" to Channel information. Allows the
>suppression of empty reports or choice to receive empty reports for heartbeat
>purposes.
>>
>> 5) Add selection of either "UTC" or "local time" to the Schedule. The support of
>local time is needed, for example, for the probe to manage its own schedule
>through daylight changing or to test within a defined peak or evening period.
>>
>> 6) Give example of a Channel to a local datastore that can be used by a
>Measurement Task for alarms or aggregate statistics. No changes to the
>Information Model itself except: we would need to define when the data expires
>on these local datastores. Need to add the concept of a datastore and an expiry
>either as "max storage size" or "retention period".
>>
>>
>> A) Include a definition of a way to suppress or back-off measurements/reports
>if the controller/collector is unreachable.
>>
>>

---

From: <[email-masked]>
Date: Mon, 2 Dec 2013 18:18:24 +0000

A few comments.
Yes, some of these would imply some mods to the framework:

1 - would affect framework
But, thinking about it more, personally I'd be inclined to be more direct, ie define the status /logging (capability /failure) msg as going to the controller. Unless we think that these msgs will really go to the collector sometimes. 
If we end up with different Controller-MA and MA-Collector protocols, then it has implications for the implementation of a Controller. 

2 - not yet in framework, happy to add it

3 - yes, will need to check how well the framework talks about multiple interfaces

4 - think this is sensible (also worth mentioning in framework)

5 - ok

6 - I think this is reasonable idea, though doesn't affect protocol on the wire, so I don't think it's compulsory to include it in lmap1.0 
if people are happy for it to be included, then it should also be discussed in the framework. 

A - the framework says, by implication
- if the controller is unreachable then the MA runs to the end of its schedule and stops. I prefer this to trying to define what unreachable means, via a heartbeat or something. Ie the MA gets its instruction and then gets on with it, autonomously.
- if the collector is unreachable (no ACK when it sends its measurement Report) then it sends a failure msg to the Controller. Think I'd leave it to implementation decision what it does beyond this (as there are lots of possibilities and don't think the right answer will always be the same. eg keep or throw away the results? How long to wait to hear about a new reporting channel from the controller?)
	
> From: Burbridge,T,Trevor,TUB8 R
> Sent: 02 December 2013 10:31
> To: [email-masked]
> Cc: Eardley,PL,Philip,TUB8 R; marcelo bagnulo braun
> ([email-masked]); Juergen Schoenwaelder (j.schoenwaelder@jacobs-
> university.de)
> Subject: Information Model suggested modifications
> 
> For the forthcoming edit of the Information Model I have been
> collecting suggestions. Aside from the ones dealing with readability,
> corrections, explanations, examples and alignment with the Framework
> draft, I have the following suggested amendments:
> 
> reporting on just another (if desired) reporting Channel. In
> nomenclature terms this would still go to a Collector, but the
> Controller is able to implement a Collector interface of its own if it
> needs this information.
> 
> 3) Extend Interface choice to Channels as well as Measurement Tasks.
> This would, for example, allow a report or an alarm to be sent over
> GPRS or other interface.
> 
> suppression of empty reports or choice to receive empty reports for
> heartbeat purposes.
> 
> 5) Add selection of either "UTC" or "local time" to the Schedule. The
> support of local time is needed, for example, for the probe to manage
> its own schedule through daylight changing or to test within a defined
> peak or evening period.
> 
> Information Model itself except: we would need to define when the data
> expires on these local datastores. Need to add the concept of a
> datastore and an expiry either as "max storage size" or "retention
> period".
> 
> 
> A) Include a definition of a way to suppress or back-off
> measurements/reports if the controller/collector is unreachable.
> 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 2 Dec 2013 20:03:41 +0100

> If we end up with different Controller-MA and MA-Collector protocols, then it has implications for the implementation of a Controller. 

Some status information needs to go to the collector so that data
analysis can take it into account. Some status information may need to
go to the controller if we assume the controller will tune its
instructions based on the status information. The question is to what
extend we assume the controller to be smart about this or whether we
expect measurement tests to be smart to adapt and/or to report proper
warnings / errors.

> - if the controller is unreachable then the MA runs to the end of its schedule and stops. I prefer this to trying to define what unreachable means, via a heartbeat or something. Ie the MA gets its…

In other words, an MA that got the instruction to run a download test
every hour will do this for years even if the rest of the measurement
infrastructure ceased to exist. Or in other words, you are suggesting
that as a best practice a controller should send only reasonably
time-bound schedules and the controller renew them in due time to
address this issue?

> - if the collector is unreachable (no ACK when it sends its measurement Report) then it sends a failure msg to the Controller. Think I'd leave it to implementation decision what it does beyond this…

To the controller? Or over the logging channel? Do we assume that the
logging channel is always "bound" to the controller?

/js

---

From: <[email-masked]>
Date: Tue, 3 Dec 2013 09:07:10 +0000

> > - if the controller is unreachable then the MA runs to the end of its
> schedule and stops. I prefer this to trying to define what unreachable
> means, via a heartbeat or something. Ie the MA gets its instruction and
> then gets on with it, autonomously.
> 
> that as a best practice a controller should send only reasonably time-
> bound schedules and the controller renew them in due time to address
> this issue?

yes

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Dec 2013 10:15:47 +0100

> > bound schedules and the controller renew them in due time to address

If we adopt this approach, I think we need to discuss this explicitely
somewhere. But where? In the framework?

/js

---

From: <[email-masked]>
Date: Tue, 3 Dec 2013 09:38:58 +0000

We (framework authors) are currently preparing a new version.
With this draft text:-

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?

> Sent: 03 December 2013 09:16
> To: Eardley,PL,Philip,TUB8 R
> Cc: Burbridge,T,Trevor,TUB8 R; [email-masked]; [email-masked]
> > > schedule and stops. I prefer this to trying to define what
> > > unreachable means, via a heartbeat or something. Ie the MA gets its
> > > instruction and then gets on with it, autonomously.
> > >
> > > In other words, an MA that got the instruction to run a download
> > > test every hour will do this for years even if the rest of the
> > > measurement infrastructure ceased to exist. Or in other words, you
> > > are suggesting that as a best practice a controller should send
> only
> > > reasonably time- bound schedules and the controller renew them in
> > > due time to address this issue?
> >
> > yes
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Dec 2013 11:26:24 +0100

> 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 tra…

Yes.

/js

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 3 Dec 2013 13:13:42 +0000

> 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?

So, sort of a Measurement Task Lifetime, similar to lifetimes of IP addresses and such?
The Controller could set the lifetime of a measurement task, and then reset the lifetime once it has passed its half-life.
The MA would immediately start decrementing the lifetime once it's set.
MA operators would be free to determine what they think the right lifetime is, just like for DHCP address lifetimes and RA prefix lifetimes.
Barbara

---

From: <[email-masked]>
Date: Tue, 3 Dec 2013 15:00:41 +0000

>From: STARK, BARBARA H [mailto:[email-masked]]
>Sent: 03 December 2013 13:14
>To: Eardley,PL,Philip,TUB8 R; [email-masked]
>Cc: [email-masked]; Burbridge,T,Trevor,TUB8 R; [email-masked]
>Subject: RE: Information Model suggested modifications
>
>The Controller could set the lifetime of a measurement task, and then reset the
>lifetime once it has passed its half-life.
>MA operators would be free to determine what they think the right lifetime is,
>just like for DHCP address lifetimes and RA prefix lifetimes.

The information model already has a start and end date/time for each schedule, so the change would be simply recommending this approach as general practice. I think it's probably still worth leaving the end date/time as optional for those who have small measurement systems and want to ignore best practice.

I'm not sure that stopping testing when the MA can't get connectivity is really the requirement though. Maybe the more precise requirement is whether the MA has a fail-over Controller and how this is done? Should we add an optional secondary Controller into the Information Model and specify the fail-over mechanism in the Framework?

>Barbara

Trevor.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Dec 2013 16:09:09 +0100

> I'm not sure that stopping testing when the MA can't get connectivity is really the requirement though. Maybe the more precise requirement is whether the MA has a fail-over Controller and how this…

A fail-over only helps if there is something to fail-over to.

For example, if the owner of the measurement infrastructures goes
bankrupt, what is going to happen with the deployed probes? This is
not a fail-over situation and one would hope that the probes stop at
some time to do measurements (and we won't have to wait until the
results have eaten up all storage and the box hosting the MA simply
fails badly because of resource shortage; sure well implemented MAs
will never do this. ;-).

Back to fail-over: There are many tricks you can do if the controller
is identified by a URI to provide controller service. I am not sure
yet fail-over is something we have to engineer into LMAP 1.0. (Lets
keep it simple and ship early.)

/js

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 3 Dec 2013 15:11:53 +0000

> I'm not sure that stopping testing when the MA can't get connectivity is really
> the requirement though. Maybe the more precise requirement is whether
> the MA has a fail-over Controller and how this is done? Should we add an
> optional secondary Controller into the Information Model and specify the
> fail-over mechanism in the Framework?

I would prefer not to have a fail-over Controller. There are plenty of ways to deal with fail-over in the network, such as using DNS SRV records for the Controller URL. Having multiple configured URLs within lots of devices is much less flexible than DNS SRV. Other DNS records can also be used.

Fail-over should be centrally managed, and not done at the extremities (at the MAs). IMO.
Barbara

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 03 Dec 2013 16:20:19 +0100

I believe that the RIPE-Atlas probes cease to do measurements if they loose
connectivity with the RIPE-Atlas infrastructure for a prolonged time.

If needed, I can try to get the details posted.

Bert

On 12/3/13 4:09 PM, Juergen Schoenwaelder wrote:
> will never do this.;-).

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Dec 2013 17:23:37 +0100

Hi,

it is always nice to know what existing implementations actually
do. If deployed systems do not periodically rewrite the schedule in
order to handle this corner case but instead use a different mechanism
to stop probes that are loosing connectivity for a longer time, then
there might be something to learn from.

/js

On Tue, Dec 03, 2013 at 04:20:19PM +0100, Bert Wijnen (IETF) wrote:
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: "Sharam Hakimi" <[email-masked]>
Date: Tue, 3 Dec 2013 13:45:28 -0500

A failover controller would be a nice to have but it gets complicated. A
simple hello message sent from the MC to the MAs once a day(or any other
agreed time period) would let the MAs know that the Controller is alive.
For example if the MA misses 3 hello messages then it would stop it
testing operation until it establishes connection with the MC.

Sharam 

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Juergen
Schoenwaelder
Sent: Tuesday, December 03, 2013 11:24 AM
To: Bert Wijnen (IETF)
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [lmap] Information Model suggested modifications

Hi,

/js

---

From: "Weil, Jason" <[email-masked]>
Date: Thu, 5 Dec 2013 09:39:15 -0500

/Chair hat off

Personally I prefer this approach. I would think an MA should check in
with the Controller at some time interval (interval could be provided by
the controller along with some number of retry attempts) for a health
check. If a Controller goes away for whatever reason and it is responsible
for controlling 250,000 probes, it would be nice for those probes to stop
performing their assigned tasks until the Controller returns.

Jason

>> fails badly because of resource shortage; sure well implemented MAs

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Thu, 5 Dec 2013 15:04:07 +0000

What happens if the collector isn't available ... ??

Same behavior?

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Weil, Jason
Sent: Thursday, December 05, 2013 8:39 AM
To: Bert Wijnen (IETF); [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [lmap] Information Model suggested modifications

/Chair hat off

Personally I prefer this approach. I would think an MA should check in with the Controller at some time interval (interval could be provided by the controller along with some number of retry attempts) for a health check. If a Controller goes away for whatever reason and it is responsible for controlling 250,000 probes, it would be nice for those probes to stop performing their assigned tasks until the Controller returns.

Jason

On 12/3/13 10:20 AM, "Bert Wijnen (IETF)" <[email-masked]> wrote:

>I believe that the RIPE-Atlas probes cease to do measurements if they 
>loose connectivity with the RIPE-Atlas infrastructure for a prolonged 
>time.
>

---

From: "Weil, Jason" <[email-masked]>
Date: Thu, 5 Dec 2013 11:35:16 -0500

The case of an unreachable Collector seems more implementation dependent.
It becomes a function of the amount of memory on the MA, the preferred
reporting/collection interval, and business requirements of the
measurement system. The flexibility to support varying reporting
requirements should be supported.

I think I need to pull back slightly from my former comment to add that
the MA to Controller reachability test resulting action should be flexible
as well. A test administrator may want some scheduled tests to not start
when the Controller is no longer reachable and others to continue. Of
course this could be solved by other means such as having the Controller
provide a short test schedule for some tests (e.g. run these tests for the
next 24hrs) and long or infinite duration for others and just require the
MA to check back frequently (every 24hrs in the former example) to the
Controller for its next test schedule.

Jason

On 12/5/13 10:04 AM, "Bugenhagen, Michael K"
<[email-masked]> wrote:

>To: Bert Wijnen (IETF); [email-masked]; [email-masked];
>[email-masked]; [email-masked]; [email-masked]
>check. If a Controller goes away for whatever reason and it is
>responsible for controlling 250,000 probes, it would be nice for those
>probes to stop performing their assigned tasks until the Controller
>returns.
>
>Jason
>
>This E-mail and any of its attachments may contain Time Warner Cable
>proprietary information, which is privileged, confidential, or subject to
>copyright belonging to Time Warner Cable. This E-mail is intended solely
>for the use of the individual or entity to which it is addressed. If you
>are not the intended recipient of this E-mail, you are hereby notified
>that any dissemination, distribution, copying, or action taken in
>relation to the contents of and attachments to this E-mail is strictly
>prohibited and may be unlawful. If you have received this E-mail in
>error, please notify the sender immediately and permanently delete the
>original and any copy of this E-mail and any printout.

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Thu, 5 Dec 2013 16:48:48 +0000

Given it can be difficult to audit the MA list between a Collector, and the Controller it might be a good thing if they ever lose either connection for the MA to signal the loss to the other side.

So if the MA loses the Collector - it would once a day tell the Controller it's lost collector connectivity
If the MA loses the controller - it can inform the collector it's lost controller connectivity

This way it's easier (you have a list that can easily be generated) to communicate those to the other person (assuming they are two different groups).

Just an idea - 

-----Original Message-----
From: Weil, Jason [mailto:[email-masked]] 
Sent: Thursday, December 05, 2013 10:35 AM
To: Bugenhagen, Michael K; 'Bert Wijnen (IETF)'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [lmap] Information Model suggested modifications

The case of an unreachable Collector seems more implementation dependent.
It becomes a function of the amount of memory on the MA, the preferred reporting/collection interval, and business requirements of the measurement system. The flexibility to support varying reporting requirements should be supported.

I think I need to pull back slightly from my former comment to add that the MA to Controller reachability test resulting action should be flexible as well. A test administrator may want some scheduled tests to not start when the Controller is no longer reachable and others to continue. Of course this could be solved by other means such as having the Controller provide a short test schedule for some tests (e.g. run these tests for the next 24hrs) and long or infinite duration for others and just require the MA to check back frequently (every 24hrs in the former example) to the Controller for its next test schedule.

Jason

On 12/5/13 10:04 AM, "Bugenhagen, Michael K"
<[email-masked]> wrote:

>with the Controller at some time interval (interval could be provided 
>by the controller along with some number of retry attempts) for a 
>health check. If a Controller goes away for whatever reason and it is 
>proprietary information, which is privileged, confidential, or subject 
>to copyright belonging to Time Warner Cable. This E-mail is intended 
>solely for the use of the individual or entity to which it is 
>addressed. If you are not the intended recipient of this E-mail, you 
>are hereby notified that any dissemination, distribution, copying, or 
>action taken in relation to the contents of and attachments to this 
>E-mail is strictly prohibited and may be unlawful. If you have received 
>this E-mail in error, please notify the sender immediately and 
>permanently delete the original and any copy of this E-mail and any printout.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Dec 2013 17:59:48 +0100

Hi,

somehow it feels a bit strange to send configuration updates as a keep
alive mechanism. We do have a suppression mechanism because we do not
want to reconfigure MAs just to suppress execution of tests for a
certain (typically short) period of time. We could have solved that by
configuration updates as well but we did not (and I think this feels
right).  Hence, I would expect that we do the same here - one could
think of this as an automated suppression that gets activated once
connectivity to the controller has been lost for a certain time
period.

Concerning the collector, if the MA can't report for a while, I assume
it will discard results. Ideally the controller will notice at some
time (via unspecified mechanisms) that no data is being received
anymore and it can take action. If the MA looses connectivity to the
controller, there however nothing anymore left to take any actions. So
in this case, I believe the MA should stop all measurements. And I
would keep things simple - if the MA has not managed to talk to its
controller for a certain longer time, it starts to suppress all
measurements. A simple 'auto suppression' parameter (set it to a week
or a months - whatever is a suitable safety timeout) should be enough.

/js

---

From: <[email-masked]>
Date: Fri, 6 Dec 2013 16:02:02 +0000

I agree with Juergen and Jason on Collector failure. There are various things the measurement system might want to do. It can report to the Controller (S5.2 p16, failure reporting). 

I agree it seems a bit strange to send configuration updates as a keep alive mechanism. However, there was a caution against adding a heartbeat mechanism - Steve (?) mentioned that he'd found it gave far more false positives than true positives.

I don't think we can insist on the MA reporting a Controller failure to the Collector - at least where there are multiple collectors it might get confusing, and some collectors might not have a link back to the controller. 

Thanks
phil

> Sent: 05 December 2013 17:00
> To: Weil, Jason
> Cc: Bugenhagen, Michael K; 'Bert Wijnen (IETF)';
> Burbridge,T,Trevor,TUB8 R; [email-masked]'; Eardley,PL,Philip,TUB8 R;
> [email-masked]'; [email-masked]'
> connectivity to the controller has been lost for a certain time period.
> 
> > I think I need to pull back slightly from my former comment to add
> > that the MA to Controller reachability test resulting action should
> be
> > flexible as well. A test administrator may want some scheduled tests
> > to not start when the Controller is no longer reachable and others to
> > continue. Of course this could be solved by other means such as
> having
> > the Controller provide a short test schedule for some tests (e.g. run
> > these tests for the next 24hrs) and long or infinite duration for
> > others and just require the MA to check back frequently (every 24hrs
> > in the former example) to the Controller for its next test schedule.
> >
> > Jason
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > >Personally I prefer this approach. I would think an MA should check
> > >in with the Controller at some time interval (interval could be
> > >provided by the controller along with some number of retry attempts)
> > >for a health check. If a Controller goes away for whatever reason
> and
> > >it is responsible for controlling 250,000 probes, it would be nice
> > >for those probes to stop performing their assigned tasks until the
> > >Controller returns.
> > >
> > >Jason
> > >
> > >>I believe that the RIPE-Atlas probes cease to do measurements if
> > >>they loose connectivity with the RIPE-Atlas infrastructure for a
> > >>prolonged time.
> > >>
> > >>> bankrupt, what is going to happen with the deployed probes? This
> > >>> is not a fail-over situation and one would hope that the probes
> > >>> stop at some time to do measurements (and we won't have to wait
> > >>> until the results have eaten up all storage and the box hosting
> > >>> the MA simply fails badly because of resource shortage; sure well
> > >>> implemented MAs will never do this.;-).
> > >proprietary information, which is privileged, confidential, or
> > >subject to copyright belonging to Time Warner Cable. This E-mail is
> > >intended solely for the use of the individual or entity to which it
> > >is addressed. If you are not the intended recipient of this E-mail,
> > >you are hereby notified that any dissemination, distribution,
> > >copying, or action taken in relation to the contents of and
> > >attachments to this E-mail is strictly prohibited and may be
> > >unlawful. If you have received this E-mail in error, please notify
> > >the sender immediately and permanently delete the original and any
> copy of this E-mail and any printout.
> action taken in relation to the contents of and attachments to this E-
> mail is strictly prohibited and may be unlawful. If you have received