Subject: Detecting cleared alarms

From: "Dave Shield" <[email-masked]>
Date: Wed, 8 Aug 2001 13:56:47 +0100 (BST)

At the DisMan working group on Monday, one of the concerns raised was over
how to efficiently detect known alarms that have subsequently been cleared.
In the absence of an 'alarmRetiredTable'  (analagous with condRetiredTable),
this can only be detected by the relevant rows disappearing from the
alarmActiveTable.  It was suggested that some form of alarmRetiredTable
would save having to walk the whole of the active table.  I remain
unconvinced that such a table would make any significant difference to
addressing this problem.
  (Which is not to say that such a table isn't valuable in its own right
Simply that this particular problem isn't the justification for it).

In the first place, it's only necessary to walk one column of a table in
order to tell whether the row is still present.  Retrieving the whole of
the row is only needed when the alarm is first detected - not to tell
whether it is still active.

Secondly, using an alarmRetiredTable-type rarely, if ever, provides
consistently better performance compared to using the same approach on
the existing alarmActiveTable.  Indeed, it's frequently worse.

Let me illustrate this:  consider an alarmActiveTable with 200 (known)
alarms, indexed 1-200 (ignoring the other indices for simplicity).  Some
time later, the manager wishes to find out which of these are still active,
and which have been cleared.  I'll use the alarmActiveModelPointer object
(and a corresponding alarmRetiredModelPointer) for these examples - but any
other column would work just as well.

    1)  GETNEXT
In the Best Case,
	"GETNEXT alarm{Active,Retired}ModelPointer"
would return an instance after the list of known alarms - indicating that
all the alarms had been cleared, or are still active, respectively.
					Cost: 2 PDUs, 2 varbinds
  In the Worst Case, all the alarm entries will still be present in the
relevant table, so the manager would need to walk through this column in
either case.
					Cost: 400 PDUs, 400 varbinds

  Two further factors probably count against the Retired table in this
situation.  Firstly, since the full details of the active tables are
known, the manager could actually list them all (shifted back a place)
in a single GETNEXT request.
[This is functionally equivalent to my idea of using an exact GET].
					Cost: 2 PDUs, 400 varbinds

  For the Retired table, assuming the indexes include some form of timestamp,
this is not possible.  The manager would not know when the alarms would
have been cleared, so could not generate the necessary list of predecessors.

  Secondly, it is quite possible that some alarms may have been raised and
cleared in the intervening period.  These will be retrieved when walking
the Retired table, despite notbeing relevant to the current requirements.

  So for a GETNEXT-based approach, checking an alarmRetiredTable is
likely to be less efficient than checking the existing alarmActiveTable.

   2)  GETBULK
Again, the Best Case is that
	"GETBULK 0,200 alarm{Active,Retired}ModelPointer"
would show that all alarms were still active, or had been cleared,
respectively. 				 Cost: 2 PDUs, 201 varbinds

The Worst Case is that the same request would fail to include any of the
entries of interest - indicating that they had all been cleared, or were
all still active.
  In this situation, the active walk might indicate the presence of new
active alarms (which should perhaps be investigated), whereas the retired
overshoot simply indicates that some other alarms had been raised and
cleared (which is probably less generally useful).

  In the Worst Worst Case, the bulk retrieval of the retired table might
return 200 "short-lived" new alarm entries - leaving the manager with no
idea whether the original entries were still active or not!

  Thus querying the active table tends to achieve equal or better results
overall, as before.

  3)  GETCOLS, etc
An analysis of the potential new EOS-style requests is similar to the
previous cases. 			 Cost: 2 PDUs, <=201 varbinds

  The manager is less likely to get completely irrelevant information
(walking off the end of the column), but the two tables will always show
equivalent behaviour, given equally suitable (or unsuitable) scenarios.
And fundamentally, querying the Retired table may potentially return
information about "short lived" alarms, which is not relevant to this
particular problem, and just add to the cost.

  I fail to see how adding such an alarmRetiredTable is of any significant
benefit in addressing how to delect the clearing of known alarms.
  I look forward to being better informed over this.

Dave

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 9 Aug 2001 01:00:19 -0700 (PDT)

Hi -

> Message-Id: <[email-masked]>
> Subject: Re: Detecting cleared alarms
> To: [email-masked] (Randy Presuhn)
> Date: Thu, 9 Aug 2001 08:23:03 +0100 (BST)
> From: "Dave  Shield" <[email-masked]>
> Cc: [email-masked]
> In-Reply-To: <no.id> from "Randy Presuhn" at Aug 08, 2001 06:14:43 AM
...
> For the *first* one, sure - but how can it check all 200 in a single
> GETNEXT request?   It doesn't know when the first alarm was cleared,
> so it can't try to GETNEXT-retrieve the second alarm in the same PDU.

GetBulk.

> It inherently has to walk the column one entry at a time.  Thus
> 200 requests, and 200 replies - minimum (assuming all alarms have
> actually been cleared).

The difference is that with a separate table of retired alarms,
the retrieval cost is proportional to the number actually
cleared since the table was last checked.  With the existing
approach, the cost is proportional to the total number of
active alarms at the time of the previous check of the active
alarm table.

Consider the case where this is implemented not just in end
systems, but also in mid-level managers, where the active
alarm table would potentially be quite large.

> The same approach can be used for the active table - walking it one
> entry at a time - so you've potentially got the same 200+200 PDUs.
> But the full details of the known alarms are already known (by
> definition) - including the timestamps which are in fact part of
> the indexing.
>   So the manager can put all 200 varbinds into a single GETNEXT
> request, and check them all in one go.  There's the same 400 varbinds
> involved - but only 2 PDUs.  That's a saving (both in PDU cruft, and
> latency) that simply isn't available when walking the Retired table.
> 
> 
> Or am I missing something obvious?
...

The maximum number of varbinds that most implementations will
accept over a UDP transport is usually much less than 200.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 9 Aug 2001 06:35:50 -0700 (PDT)

Hi -

> From [email-masked] Thu Aug  9 05:55:47 PDT 2001
> Date: Thu, 9 Aug 2001 13:56:51 +0100 (BST)
> In-Reply-To: <no.id> from "Randy Presuhn" at Aug 09, 2001 01:00:19 AM
...
> >                                            With the existing
> No.
> The cost is proportional to the total number of those earlier
> active alarms that are still current.
>               ^^^^^^^^^^^^^^^^^^^^^^

Good point.  I'll accept that the cost of the current draft's
approach will be proportional the average number of alarms
that remain active from one poll cycle to the next.

The addition of a cleared alarms table makes it proportional
to the average number of alarms cleared from one cycle to
the next.

If the typical lifetime of an alarm is shorter than the
poll cycle, we're better off without a cleared alarms table.
If the typical alarm stays active longer than the poll cycle,
the cleared alarms table wins out.

> The active table is still ordered by time, is it not?
> So as soon as the manager retrieves the first entry that is
> later than the last one it knows about, it can stop.  That
> could easily be the first request it sends, if all the alarms
> have since been cleared.

Yep.  I had missed this.  However, see above regarding
active alarm longevity vs. poll interval.

>   (Chunking might mean that it actually requests more than
> it needs - but only within that final PDU. It wouldn't need
> to send any more separate requests).

GetBulk gets the same behaviour.  I think it's pretty implausible
that one would bother implementing this in an insecure v1-only
environment.

>   The Best Case and Worst Case costs are the same in both cases,
> though the Best and Worst Case scenarios are mirrors of each other.

However, where the typical cost will tend is strongly
affected by the typical active alarm lifetime.  My
intuition is that very short-lived alarms are not
particularly interesting.

> If the manager knows from the first request that all known alarms
> have been cleared - whether this is one alarm or one million - how
> is this O(N) ?
...

The context of the discussion is synchronizing the
management system's notion of the current set with
the MIB's.  Average behaviour to achieve synchronization
for cleared alarms in both cases is O(N).
The difference is whether "N" is the average number of
alarms that remain active across a poll cycle, or "N"
is the average number of alarms cleared per poll cycle.

Perhaps someone has some data one what typical active
alarm lifetimes are?  It's also interesting to think
about the alarm lifetime distribution is; those alarms
which live out their entire lifecycle in a single poll
cycle show up in one "N" but not the other.