RE: Proposed wordsmithing to notification throttling guideline

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

I agree with all that. 
And the best thing would be to find a serious and generic solution
(as you also suggest youerself). Are there any people who
want to work on such a solution.... ? Again... it would be
outside the scope of this doc.

Thanks,
Bert 

> -----Original Message-----
> From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]
> Sent: woensdag 13 augustus 2003 19:13
> To: Mreview (E-mail)
> Subject: Re: Proposed wordsmithing to notification throttling 
> guideline
> 
> 
> 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
> 
> 
>