Subject: [lmap] Suppression for a defined duration

From: KEN KO <[email-masked]>
Date: Wed, 24 Sep 2014 15:49:47 +0000

Trevor,

During continued WT-304 sessions after our joint workshop last week, Dave Thorne pointed out that the Suppression object needs an optional field for duration of the suppression event. It does of course include optional start and stop datetime fields, but those fields are dependent on the datetime clocks in all the MAs across the network being in reasonably good synchronization. To preclude issues due to clocks being out of sync, suppression should be able to specify a fixed duration.

Your thoughts? I've also included Dave in case he wants to chime in.

Ken

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Sep 2014 23:44:21 +0200

> Your thoughts? I've also included Dave in case he wants to chime in.

I prefer to not add this. Instead, make sure boxes run ntp or
something like that. The reason is: What happens if a device reboots
during suppression? In that case, am I expected to be able to
calculate how long the suppression continues? What if my time
synchronization changes? Or is the idea that I calculate an absolute
end time stamp once I receive the suppression and then I still depend
on time synchronization to do the right thing?

I believe we have to trust that boxes have a meaningful notion of time
for basically all of the scheduling to work correctly. If clocks are
unusable for suppression, then they will also be unusable to starting
tasks at other scheduled times. So there better are NTP synchronized
clocks. Perhaps we should add an explicit statement about this
somewhere.

/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: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 24 Sep 2014 22:23:14 +0000

> > During continued WT-304 sessions after our joint workshop last week, Dave
> Thorne pointed out that the Suppression object needs an optional field for
> duration of the suppression event. It does of course include optional start
> and stop datetime fields, but those fields are dependent on the datetime
> clocks in all the MAs across the network being in reasonably good
> synchronization. To preclude issues due to clocks being out of sync,
> suppression should be able to specify a fixed duration.
> >
> I prefer to not add this. Instead, make sure boxes run ntp or something like
> that. The reason is: What happens if a device reboots during suppression? In
> that case, am I expected to be able to calculate how long the suppression
> continues? What if my time synchronization changes? Or is the idea that I
> calculate an absolute end time stamp once I receive the suppression and
> then I still depend on time synchronization to do the right thing?
> 
> I believe we have to trust that boxes have a meaningful notion of time for
> basically all of the scheduling to work correctly. If clocks are unusable for
> suppression, then they will also be unusable to starting tasks at other
> scheduled times. So there better are NTP synchronized clocks. Perhaps we
> should add an explicit statement about this somewhere.
> 
> /js

I thought that since it can't be assumed that a device maintains any aspect of its Instruction when rebooted or power-cycled, that the best practice procedure would be to re-send suppression to a rebooted device. Of course, it's probably even less desirable to have the Controller try to figure out how much of a duration is left in this case. It's easier for the Controller to just have a static end time. Also, since it's unlikely that the Controller actually suppresses all MAs at the same time, it's unlikely that all MAs would start suppressing at the same time. Duration would cause different ends to suppression based on when the MA actually got the message. Unless the Controller is calculating different duration for each device.

As it relates to ntp, most devices do lose their time configuration during power cycling, and use a "relative to start-up" time until they manage to get in touch with their favorite ntp server. Continued inability to communicate with an ntp server isn't supposed to prevent proper operation. It just messes with timestamps on logs. But generally, if there's Internet connectivity that allows communication with a Controller, then there's communication with an ntp server. And we've said the MA isn't to do any Measurement Tasks until it registers with its Controller (so if it's rebooting it has to register before it does Measurement Tasks).

Hmm. I'm sort of ambivalent but tending to agree with Juergen.
Barbara

---

From: <[email-masked]>
Date: Thu, 25 Sep 2014 11:29:24 +0100

I don't understand what the benefit is, although I don't violently object to adding the suppression duration as a field.

Is the situation that people are worried about where the device re-boots, the internal clock now thinks it's 1970, it now gets a suppress with "start now, end 26 Sept 2014"? But there's a bigger problem - the instruction has a start time for measurements, so it would never start measuring anyway. So the MA has to realise something's wrong and re-set its clock anyway.
	
related topic. If the MA is in suppression and re-boots, it would probably be nice if it's still in suppression after re-boot. Think this is hard to solve with things we define at the IETF - seems device /implementation dependent how to handle the issue (after re-boot - maybe the "suppress state" can be in persistent memory, maybe the device assumes its instruction is stale and doesn't do any measurements until it's re-contacted the controller, etc.) I'd have thought the device /MA's behaviour after re-boot will be consistent - it isn't something that the controller will want to regularly alter - so don't think this needs to be part of the information model. 

Phil

> -----Original Message-----
> From: lmap [mailto:[email-masked]] On Behalf Of STARK, BARBARA H
> Sent: 24 September 2014 23:23
> To: Juergen Schoenwaelder; KEN KO
> Cc: Burbridge,T,Trevor,TUB8 R; Thorne,DJ,David,TUB8 R; [email-masked]
> Subject: Re: [lmap] Suppression for a defined duration
> 
> > > During continued WT-304 sessions after our joint workshop last
> week,
> > > Dave
> > Thorne pointed out that the Suppression object needs an optional
> field
> > for duration of the suppression event. It does of course include
> > optional start and stop datetime fields, but those fields are
> > dependent on the datetime clocks in all the MAs across the network
> > being in reasonably good synchronization. To preclude issues due to
> > clocks being out of sync, suppression should be able to specify a
> fixed duration.
> > >
> I thought that since it can't be assumed that a device maintains any
> aspect of its Instruction when rebooted or power-cycled, that the best
> practice procedure would be to re-send suppression to a rebooted
> device. Of course, it's probably even less desirable to have the
> Controller try to figure out how much of a duration is left in this
> case. It's easier for the Controller to just have a static end time.
> Also, since it's unlikely that the Controller actually suppresses all
> MAs at the same time, it's unlikely that all MAs would start
> suppressing at the same time. Duration would cause different ends to
> suppression based on when the MA actually got the message. Unless the
> Controller is calculating different duration for each device.
> 
> As it relates to ntp, most devices do lose their time configuration
> during power cycling, and use a "relative to start-up" time until they
> manage to get in touch with their favorite ntp server. Continued
> inability to communicate with an ntp server isn't supposed to prevent
> proper operation. It just messes with timestamps on logs. But
> generally, if there's Internet connectivity that allows communication
> with a Controller, then there's communication with an ntp server. And
> we've said the MA isn't to do any Measurement Tasks until it registers
> with its Controller (so if it's rebooting it has to register before it
> does Measurement Tasks).
> 
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Sep 2014 13:08:20 +0200

Hi,

as said before, all the calendar scheduling assumes that MAs have a
resonable notion of time. Hence, if we make this assumption in
general, why would we then have to do something extra for suppression?

/js

---

From: KEN KO <[email-masked]>
Date: Thu, 25 Sep 2014 12:11:48 +0000

>related topic. If the MA is in suppression and re-boots, it would probably be nice 
>if it's still in suppression after re-boot. Think this is hard to solve with things we 
>define at the IETF - seems device /implementation dependent how to handle the 
>issue (after re-boot - maybe the "suppress state" can be in persistent memory, 
>maybe the device assumes its instruction is stale and doesn't do any measurements 
>until it's re-contacted the controller, etc.) I'd have thought the device /MA's behaviour 
>after re-boot will be consistent - it isn't something that the controller will want to 
>regularly alter - so don't think this needs to be part of the information model. 

Whether or not the MA retains state information through a reboot will be device dependent. If it does, it can continue as if nothing happened. If not, it needs to re-register. I don't see a need for any mention in the i-m.

---

From: Sharam Hakimi <[email-masked]>
Date: Thu, 25 Sep 2014 15:48:23 +0000

I tend to agree with phil,
We have a time to test which means do not test during other times. A time not to test is really not necessary in my opinion. There is also the issue of time zones and what MAs in what time zones are under the control of the controller.

A suppress should really mean to stop what was and is scheduled to test at the time it is issued. If an MA reboots, then by default it needs to get its schedule from the controller because it has nothing to do at that point.

Sharam 

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, September 25, 2014 6:29 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [lmap] Suppression for a defined duration

	

Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Sep 2014 19:52:41 +0200

On Thu, Sep 25, 2014 at 03:48:23PM +0000, Sharam Hakimi wrote:
> 
> If an MA reboots, then by default it needs to get its schedule from
> the controller because it has nothing to do at that point.
>

Really? Is it specified anywhere that all state is ephemeral?

/js

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 25 Sep 2014 18:42:57 +0000

> Really? Is it specified anywhere that all state is ephemeral?

Information-model says:
   While pre-configuration is persistent upon device reset or power
   cycle due to its very nature, the persistency of the additional
   configuration information may be control protocol dependent.  Some
   protocols may assume that reset devices will revert back to their
   pre-configuration state, while other protocols may assume that all
   configuration and instruction information is held in persistent
   storage.

Which to me means it may or may not be ephemeral; it is neither required to be ephemeral, nor is it required to be persistent.

I still think the safest way to handle this is for the MA to always call home as part of its start-up procedure and for the Controller to always resend suppression (if one is in effect) whenever the MA calls home. But if there is an end-to-suppression time that's known and is to be expressed in the suppress message, I think a specific time is the best way to do it, so the Controller isn't maintaining a "remaining duration" counter. I think "remaining duration" requires the Controller to have to know too much about that particular parameter. It would mean the Controller can't just blindly send the MA exactly what it was told to send the MA.
Barbara

---

From: Sharam Hakimi <[email-masked]>
Date: Thu, 25 Sep 2014 19:11:52 +0000

If an MA does not reconnect back to the controller after a reset/reboot, it could miss suppression commands or even updates to its scheduled tasks. This could cause major issues in the network if it does not have the latest update. 

Seems like we diverged to another topic. I changed the thread to keep them separate.

Sharam 

-----Original Message-----
From: STARK, BARBARA H [mailto:[email-masked]] 
Sent: Thursday, September 25, 2014 2:43 PM
To: Juergen Schoenwaelder; Sharam Hakimi
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [lmap] Suppression for a defined duration

Information-model says:

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 25 Sep 2014 21:04:38 +0000

> If an MA does not reconnect back to the controller after a reset/reboot, it
> could miss suppression commands or even updates to its scheduled tasks.
> This could cause major issues in the network if it does not have the latest
> update.
> 

Yes. But whether an MA does or doesn't is controlled by its Instruction. How often and when and whether at start-up/reboot it does its "connect to the Controller" task is all part of the configuration that is specific to the operator of the Controller.

It's very important that we provide the tools necessary to do things right. It's not necessary that we be a nanny-SDO or create a nanny-standard that keeps people from doing un-wise things.
Barbara> 

> Which to me means it may or may not be ephemeral; it is neither required to
> be ephemeral, nor is it required to be persistent.
> 
> I still think the safest way to handle this is for the MA to always call home as
> part of its start-up procedure and for the Controller to always resend
> suppression (if one is in effect) whenever the MA calls home. But if there is
> an end-to-suppression time that's known and is to be expressed in the
> suppress message, I think a specific time is the best way to do it, so the
> Controller isn't maintaining a "remaining duration" counter. I think "remaining
> duration" requires the Controller to have to know too much about that
> particular parameter. It would mean the Controller can't just blindly send the
> MA exactly what it was told to send the MA.
> Barbara

---

From: Sharam Hakimi <[email-masked]>
Date: Thu, 25 Sep 2014 21:26:43 +0000

Barbara,
I am not saying that we do not allow the wise/unwise user to control their destiny. I was suggesting that default state should have the MA check back with the controller after reboot/reset. I believe that We have to have a default state for this.

Sharam

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 26 Sep 2014 13:51:26 +0000

> Barbara,
> I am not saying that we do not allow the wise/unwise user to control their
> destiny. I was suggesting that default state should have the MA check back
> with the controller after reboot/reset. I believe that We have to have a
> default state for this.
> 
> Sharam

I disagree. 
1. The "default" schedule is determined by pre-configuration. Pre-configuration may be done as "factory default", via a management protocol, user interface, etc. (the nebulous bootstrap mechanism). I learned long ago that trying to define unnecessary globally-applicable defaults for higher layer stuff like this was a bad idea. Vendors and providers readily ignore such default recommendations whenever it suits their purposes, and there are rarely interoperability or other dire consequences when they do. Most are competent enough to figure out for themselves how to properly pre-configure their devices. The ones that aren't competent are eligible for Darwin awards.
2. The desired behavior is protocol-dependent.

I think the current text in information-model has the right level of detail:

   Where the MA pulls information from the Controller, the Pre-
   Configuration Information also needs to contain the timing of the
   communication with the Controller as well as the nature of the
   communication itself (such as the protocol and data to be
   transferred).  The timing is given as a Schedule that executes the
   Task(s) responsible for communication with the Controller.  It is
   this Task (or Tasks) that implement the Control protocol between the
   MA and the Controller.  The Task(s) may take additional parameters in
   which case a Task Configuration can also be included.

   Even where information is pushed to the MA from the Controller
   (rather than pulled by the MA), a Schedule still needs to be
   supplied.  In this case the Schedule will simply execute a Controller
   listener task when the MA is started.  A Channel is still required
   for the MA to establish secure communication with the Controller.

Barbara
 
> > If an MA does not reconnect back to the controller after a
> > reset/reboot, it could miss suppression commands or even updates to its
> scheduled tasks.
> > This could cause major issues in the network if it does not have the
> > latest update.
> >
> Yes. But whether an MA does or doesn't is controlled by its Instruction. How
> often and when and whether at start-up/reboot it does its "connect to the
> Controller" task is all part of the configuration that is specific to the operator
> of the Controller.
> 
> It's very important that we provide the tools necessary to do things right. It's
> not necessary that we be a nanny-SDO or create a nanny-standard that
> keeps people from doing un-wise things.
> Barbara>
> 
> > Cc: [email-masked]; [email-masked];
> [email-masked];
> > [email-masked]; [email-masked]
> > > > If an MA reboots, then by default it needs to get its schedule
> > > > from the controller because it has nothing to do at that point.
> > > >
> > >
> > Which to me means it may or may not be ephemeral; it is neither
> > required to be ephemeral, nor is it required to be persistent.
> >
> > I still think the safest way to handle this is for the MA to always
> > call home as part of its start-up procedure and for the Controller to
> > always resend suppression (if one is in effect) whenever the MA calls
> > home. But if there is an end-to-suppression time that's known and is
> > to be expressed in the suppress message, I think a specific time is
> > the best way to do it, so the Controller isn't maintaining a
> > "remaining duration" counter. I think "remaining duration" requires
> > the Controller to have to know too much about that particular
> > parameter. It would mean the Controller can't just blindly send the MA
> exactly what it was told to send the MA.
> > Barbara

---

From: Sharam Hakimi <[email-masked]>
Date: Fri, 26 Sep 2014 16:36:51 +0000

Barbara,
There are two issues here:

1- the default configuration
2- The default state of the variable that tells the MA what to do after reset/reboot.

I agree that a default configuration can be pre programmed by the user(ISP) and the state of the variable that tells the MA what it should do after reset/reboot would need to have changed to "use internal configuration"

The default state of the variable that tells the MA what to do after reset/reboot should default to "Check with the MC".

Having the MA to revert back to pre configured task configuration has the danger of not heeding to a suppress command that was issued before the reset/reboot, but that is for the user to determine.

Thanks,
Sharam

-----Original Message-----
From: STARK, BARBARA H [mailto:[email-masked]] 
Sent: Friday, September 26, 2014 9:51 AM
To: Sharam Hakimi; Juergen Schoenwaelder
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [lmap] MA state after reset/reboot

I disagree. 

Barbara