Subject: comments on schedule MIB

From: Tammy Ferris <[email-masked]>
Date: Wed, 21 Mar 2001 10:16:46 -0600

All,
Randy and Juergen have asked me to bring some observations I
had regarding the scheduling MIB to the working group for
discussion.

I realize this is late in the process.  I just looked at
this MIB as a part of the IETF meeting and have not
participated in this work prior to that.

The points I am providing in this mail are the result of
casual observation and not thorough analysis and are being
provided as feedback to be used or not used as the group
feels is necessary.

My comments are related to the following text:
   First, time may be set backwards, in which case
particular times will
   appear to occur twice within the same day.  These are
called
   'ambiguous times'.  Second, time may be set forwards, in
which case
   particular times will appear to not occur within a day.
This are
   called 'nonexistent times'.

   When an action is configured in the Schedule MIB to occur
at an
   ambiguous time during a time transition, the action SHALL
only be
   invoked at the first occurence of the ambiguous time.
For example,
   if an action is scheduled to occur at 2:00 am, and a time
transition
   occurs at 3:00 am which sets the clock back to 2:00 am,
the action
   SHALL only be invoked at the first occurence of 2:00 am.

   When an action is configured in the Schedule MIB to occur
at a
   nonexistent time, the action SHOULD be invoked
immediately upon a
   time transition. If multiple actions are invoked in this
way, they
   SHALL be invoked in the order in which they normally
would be invoked
   had the time transition not occured. For example, if an
action (a) is
   scheduled at 2:05 am and another action (b) at 2:10 am,
then both
   actions SHOULD be invoked at 3:00 am in the order (a),(b)
if the time
   jumps forward from 2:00 am to 3:00 am.

While I like to see specific behaviors defined in object
models and I spend a lot of my time promoting that, I think
that the specified behavior is possibly too restrictive for
a general purpose scheduler and in some cases still not yet
well defined and may be difficult to implement.

First, I would like to make some comments regarding the time
of day clock in network devices.
1) Setting the time of day is often not limited to setting
time.  It often includes setting day, month, and year.  This
behavior definition addresses the most common time change
when using local time but does not address behavior for
other changes.
2) More and more network devices and network operations
environments are moving away from the use of local time and
using Universal or GMT time (in part to get away from such
behavior side effects as described in the Schedule MIB).  Of
course there are still also many applications that use local
time and daylight saving time adjustments for time need to
be considered.

Devices that I have experience with that have used
schedulers have tended to define a different and simpler
behavior than has been chosen for this MIB in the event of a
time change.  In these devices, for example, it is
desireable to have a report sent roughly every hour.  Let's
say a report is sent at 3:00pm and at 3:10 the clock is
changed to 2:10.  In this case it is desireable to send
another report at the next occurance of 3:00pm.  This is
again roughly an hour later even though it is again 3:00.
In such devices, when the clock is set forward, if a report
is sent at 3:00pm and at 3:10 the clock is set to 4:10 it is
desireable to send the next report at 5:00 which is roughly
one hour later.

Taking into account that day, month, and year can also be
changed it appears to me very difficult to gaurantee the
behavior that the scheduled item will be prohibited from
re-occuring at the scheduled time when the time re-occurs.
Of course, in general, day, month, and year are not adjusted
backward very often or at all in most cases.  But even
constraining the setting of time of day to only the setting
of the hour, it seems an unnecessary burden to track and
prevent reoccurance and even undesireable for some
scheduling applications.

In the case of nonexistent time, there is not the issued of
a more difficult implementation but only possible
problematic side affects.  For example, if I schedule
certain events to occur during non-busy hours or time slots
and the clock is set forward such that the new time occurs
during a busy hour or time slot then the occurance of that
scheduled event at that time could be very problematic
indeed.  In such a scenario, it would be more desireable to
skip it until the next scheduled occurance.  And what about
the case of missing multiple scheduled events in a forward
change?  Will the scheduled item be invoked n times for each
n events that would have occured if the time had not
changed?

Tammy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 22 Mar 2001 07:35:18 +0100

>>>>> Tammy Ferris writes:

Tammy> All, Randy and Juergen have asked me to bring some observations
Tammy> I had regarding the scheduling MIB to the working group for
Tammy> discussion.

Thanks for writing this down and getting your comments on the list.

[...]

Tammy> Devices that I have experience with that have used schedulers
Tammy> have tended to define a different and simpler behavior than has
Tammy> been chosen for this MIB in the event of a time change.  

We have gone back and forth over the semantics during time changes. My
personal conclusion is that you can always construct cases where a
certain behaviour is either desirable or undesirable. To make that
clear, I will just change your example to produce undesirable results:

Tammy> In these devices, for example, it is desireable to have a
Tammy> report sent roughly every hour.  Let's say a report is sent at
Tammy> 3:00pm and at 3:10 the clock is changed to 2:10.  In this case
Tammy> it is desireable to send another report at the next occurance
Tammy> of 3:00pm.  This is again roughly an hour later even though it
Tammy> is again 3:00.

Lets assume it the report was sent at 3:00pm and it is 3:01. Now the
clock jumps back to 2:59. Is it still desirable to send another
report?

Tammy> In such devices, when the clock is set forward, if a report is
Tammy> sent at 3:00pm and at 3:10 the clock is set to 4:10 it is
Tammy> desireable to send the next report at 5:00 which is roughly one
Tammy> hour later.

Again, if the clock (at 3:10) is set forward to 3:59, you probably
produce an undesirable result.

Tammy> Taking into account that day, month, and year can also be
Tammy> changed it appears to me very difficult to gaurantee the
Tammy> behavior that the scheduled item will be prohibited from
Tammy> re-occuring at the scheduled time when the time re-occurs.

This is a good argument which I think has not been raised before. I am
not yet sure it is impossible - but it is definitely hard.

Tammy> In the case of nonexistent time, there is not the issued of a
Tammy> more difficult implementation but only possible problematic
Tammy> side affects.  For example, if I schedule certain events to
Tammy> occur during non-busy hours or time slots and the clock is set
Tammy> forward such that the new time occurs during a busy hour or
Tammy> time slot then the occurance of that scheduled event at that
Tammy> time could be very problematic indeed.  In such a scenario, it
Tammy> would be more desireable to skip it until the next scheduled
Tammy> occurance.

What is desirable here again depends on what you are scheduling. If
you are triggering an transaction where you could loose data or even
money if the transaction does not take place, then you probably prefer
that this event is not getting lost due to a time transition.

Tammy> And what about the case of missing multiple scheduled events in
Tammy> a forward change?  Will the scheduled item be invoked n times
Tammy> for each n events that would have occured if the time had not
Tammy> changed?

I think the idea was to invoke the scheduled event only once per entry
in the schedTable. But there does not seem to be text which says that.

Am I understanding correctly that your propose the following:

(a) Events in non-existant times just do not happen.
(b) Events in ambiguous times may invoke actions multiple times.

These rules seem to be simpler to implement. Whether the behaviour is
more desirable depends on what you are scheduling. I personally do not
have a strong opinion on this issue (except that making the behaviour
configurable seems like real overkill to me).

Any other opinions on this, please?

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

---

From: Frank Strauss <[email-masked]>
Date: 22 Mar 2001 19:47:05 -0600

Hi!

Juergen> I think the idea was to invoke the scheduled event only once
Juergen> per entry in the schedTable. But there does not seem to be
Juergen> text which says that.

I remember we had this (offline) discussion but I do not remember all
the details. However, I found that draft-ietf-disman-schedule-mib-v2-03.txt,
Section 3.4 now says:

   This rule applies to all events scheduled for nonexistent time,
   regardless whether the scheduled events originate from one or
   multiple rows in the schedTable.

 -frank