Re: Proposed wordsmithing to notification throttling guideline

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "C. M. Heard" <heard@pobox.com>
> To: "Mreview (E-mail)" <mreview@ops.ietf.org>
> Sent: Tuesday, August 12, 2003 3:37 PM
> Subject: Proposed wordsmithing to notification throttling guideline
...
>    In many cases notifications will be triggered by external events, and
>    sometimes it will be possible for those external events to occur at a
>    sufficiently rapid rate that sending a notification for each
>    occurrence would overwhelm the network.  In such cases a mechanism
>    MUST be provided for limiting the rate at which the notification can
>    be generated.  A common technique is to require that the notification
>    generator use throttling -- that is, to require that it generate no
>    more than one notification for each event source in any given time
>    interval of duration T.  The throttling period T MAY be configurable,
>    in which case it is specified in a MIB object, or it MAY be fixed, in
>    which case it is specified in the notification definition.  Examples
>    of the fixed time interval technique can be found in the SNMP-
>    REPEATER-MIB [RFC2108] and in the ENTITY-MIB [RFC2737].
>
> Does anyone object to this proposed change?
...

The change is ok with me, but there are several other problems
with the text.  To a large extent they've become clear only as our
understanding of SNMP's notification handling architecture has become
clear, so "fixing" these may be beyond the scope of this document.
I'm not sure where these comments belong, but I think they'll make it
clear why this current paragraph leaves me a little unueasy.

    1) external events aren't the only things that trigger notifications
       disman and other groups have defined notifications triggered
       by events that may be entirely internal to a system
    2) generating a notification at (for example) the AgentX interface
       within a system does not mean that anything will show up on
       the wire; that's up to the configuration of the MIBs in RFC 3413
    3) the normal operation of RFC 3413 means that the load on a network
       may be multiplied dramatically if there are multiple subscribers for
       a given notification
    4) the network is not the only concern: log capacity (RFC 3014)
       may also be an issue, as is the ability of management systems
       to keep up with the load
    5) the phrase "each event source" is ambiguous.  Does it mean:
          a) the stimulus source, e.g., purported cause
          b) the associated resource, e.g., per affected interface
          c) implementation unit that is able to track its own generation rate,
              e.g., per subagent
          d) per agent
          e) per network interface used to sent the notification
          f) per destination address
       I think something in the range a-d is what's intended, but the rationale
       would suggest that e-f might make more sense.
     6) even if throttling per notification type is in place, the total load
       placed on the network or a management system as a consequence
       of different contemporaneous events observed by a managed system
       may still be excessive.

This has all come up before, and I'm not proposing some grand solution
(which might take the form of an extension to RFC 3413).
I'm just reminding the group that even though this paragraph has a well-
motivated goal and reasonable-sounding recommendation, things
aren't as simple as we'd like, and following the advice, while better than
ignoring the issues, still won't completely solve the problem.

Randy