Subject: Re: An approach to modeling ForCES events

From: "Deleganes, Ellen M" <[email-masked]>
Date: Mon, 18 Apr 2005 21:42:47 -0700

Deferring events seems more difficult for the FE than just turning them
on and off because in order to defer sending events to the CE, the FE
would have to maintain state and possibly buffer the events. (I'm
assuming that if the CE doesn't want notifications that the FE doesn't
have to keep them around.) What happens if the FE runs out of space to
buffer events? Seems complex to deal with in the first place and the
error cases are even worse. I would hope events don't come in "huge
bursts" but are relatively rare and we don't need to build into the
model or the protocol the extra complexity to defer events.

If there is a case where one cause generates a burst of events, it may
be reasonable to provide a mechanism to allow the CE to request only the
first event in the burst. Do you happen to have a scenario where a large
burst of events would occur? The only realistic scenario I can think of
is when the CE is controlling a large number of FEs and they all want to
send events at once. But this isn't the scenario outlined.

Regards,
Ellen

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Monday, April 18, 2005 4:24 AM
To: [email-masked]
Subject: Re: An approach to modeling ForCES events

The edge/level triggering is not a reliability mechanism.
Rather it is a classical event optimization scheme to reduce/defer work.
Many papers have been written on the topic (including one coauthored by
yours truly).

Heres one example use: 
If the FE receives event triggers of some type at huge bursts, then it
may be useful (depending on available resources) for the CE to
just get one notification and no more per burst. Once the CE is done
working on the causes of the even a ok-to-send-more-events signal is
sent to the FE. 

Typically such a mechanism is part of the event mechanism if it is
available. However, if the consensus is not to have this built in, fine
with me. like you point out - i can find some way to do it in our
implementation. 

cheers,
jamal

On Fri, 2005-15-04 at 19:07 -0400, Joel M. Halpern wrote:
> My inclination is that all events should be edge triggered.  There is
no 
> reason for the FE to retransmit an event notification, since the
ForCES 
> protocol is reliable.  If we want to allow for notification of exiting
the 
> condition, that would  be a separate event, with a different trigger 
> condition on the same variable.  It might use the same level, or
hysteresis 
> can be obtained by using a lower level in the reverse direction.
> 
> Yours,
> Joel
> 
> PS: Does anyone else in the working group care?
> 
> At 05:27 PM 4/15/2005, you wrote:
> >Subject: Re: An approach to modeling ForCES events
> >To: [email-masked]
> >
> >If it is going to be too complex to change at runtime, then perhaps
> >we should stick with the knowledge that the CE needs to know at
> >registration time the details of verbosity needed.
> >
> >Another thought that popped into my head when i was reading Ellens
> >email; in addition to events that happen more frequently requiring
more
> >less verbosity - theres the case of what the event type is:
> >Edge Triggered vs Level Triggered.
> >As an example, I may want a situation where FE generates an empty
event
> >with specific event ID (say ID X). From that moment on, the FE doesnt
> >generate any new ID X events until the CE either acknowledges the
event
> >or reads/writes some attribute. In between CE being notified and the
CE
> >reactivating the event again on the FE, a substantial amount of work
may
> >need to be done and arrival of new events does not add any new
> >information or takes unnecessary resources.
> >
> >Thoughts?
> >
> >cheers,
> >jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 19 Apr 2005 06:53:16 -0400

On Mon, 2005-18-04 at 21:42 -0700, Deleganes, Ellen M wrote:
> have to keep them around.)

There are two scenarios:
 
1) nothing needs to be buffered because the state is part of the
attribute you are already maintaining at the FE. This applies to
<change> as the trigger.
Events just dont get generated at the FE anymore in the period those
events are turned off for the target. 
As an example for a simple implementation approach: if the event of
interest was attribute X of LFB Y changing, then every time attribute X
is changed localy within an FE, the FE will send an event to the CE if
the send-event-flag-for-attribute-X is true. If this flag is turned off
no such event is generated (but the local state of attribute X is still
updated). So in this case, the first event generated would alert the CE
and turn itself off until the CE sets back the boolean to process again.
Note turning off events for attribute X does not equate to turning off
all events at the FE.

2) Buffering needed.
The "units of work" need to be transported to the CE - without the "
unit of work" the CE cant process the event. As an example of such
things would be packets that need to be transported to the CE for
further resolution.  Another example would be queries built as a result
of packets arriving at the FE (eg a IPSEC security association acquire
message whose resolution happens at the CE). Overall such units of work
need to be buffered.
 
>  What happens if the FE runs out of space to buffer events? 

So you are talking about case #2. I would say simple FIFO schemes would
do. Overrun of the FIFO should be flagged.

> Seems complex to deal with in the first place and the

What do you mean by error cases? Lost messages? There are several ways
to deal with that issue.

To digress a little:
I think the threshold triggers we are trying to build in are equally as
complex as this issue and serve the same purpose. 
The only real value the thresholds provide is offloading the CE by
providing ability to deffer the CE work scheduling point (which is
exactly what the edge/level triggering does). 
In other words, the thresholds dont reduce the work that the FE has to
do. It still has to constantly poll to check the stats in place of the
CE doing that work. Note: i am not arguing against the threshold
triggering - just pointing out the similarities because you brought up
the point of complexity (I still think its a good necessary evil).

> send events at once. But this isn't the scenario outlined.

The general class of problems is: more events coming into the CE than
the CE can handle within reasonable time. Essentially, like the
threshold triggering, it is an optimization. More importantly, its a
classical event-processing scaling mechanism. Assuming in the worst case
your CE cant keep up with the rate at which events are generated from
the FEs, then the CE will end up thrashing. The ability to selectively
defer events processing helps the CE not to thrash.

I hadnt thought of the example you provided above - but its a reasonable
one.
The examples i can think of require processing of something in the
CE to update state at the FE[1]. These could be "stateful" classifiers
at the FE which require that the CE make the state update decision or
IDSes etc. The specific problem i am faced with at the moment is IPSEC
ACQuires being issued at the FE to the CE (assuming IKE runs at the
CE). 

cheers,
jamal

[1] We have spent many electrons in the past arguing about this very
issue. i.e whether the full processing of such things should happen at
the FE instead of being sent to the CE. I dont wanna go there with this
thread - Assume this is a legit way as well and let the benchmarks
decide which of the two approaches is better.