Subject: Re: An approach to modeling ForCES events

From: "Deleganes, Ellen M" <[email-masked]>
Date: Fri, 15 Apr 2005 13:32:36 -0700

I think it is valuable to have two levels of verbosity in reporting,
where some mechanism exists to be able to select on a per event type
basis. I think it depends on what the event is on whether you want more
report information or not. For events that happen more frequently, maybe
all you want are the notifications. In the case where you are generating
events due to a counter exceeding (perhaps indicating some kind of bad
behavior) then you probably do want more detailed information.

Regards,
Ellen

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Friday, April 15, 2005 12:42 PM
To: [email-masked]
Subject: Re: An approach to modeling ForCES events

I don't know if this is useful, but is easy to represent.  Instead of a 
boolean registration variable, we use a uint8, where 0 means "do not 
notify", 1 means "just notify with no body", and 2 means "notify with
body 
according to the declared report information from the LFB class
definition."

I assume that event notifications will be relatively rare.  If so, is
the 
savings in the report worth it?

Yours,
Joel M. Halpern

At 02:52 PM 4/15/2005, Jamal Hadi Salim wrote:
>3) Event report formatting.
>The <report> looks good. The main issue i had is the verbosity level
>of reporting. I know you (Joel) have had issues with the levels of
>reporting in other discussions regarding the protocol. I think it's an
>important addition.
>Example of verbosity would be something along the lines of:
>
>*level0) "just tell me when the event happens - dont want any details"
>*level1) "tell what the value of foo.$1.bar when this event happens"

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 15 Apr 2005 16:43:45 -0400

For each event, the event definition includes the indication as to what 
information is to be reported.
The question is whether, for a given event, in some situations that the CE 
can determine when it registers, it will want the full information and in 
some circumstances (that it can determine at registration time) it will 
want only the indication of the event occurring.
if the CE at registration can meaningfully make that distinction, then 
having different registration levels is useful.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 15 Apr 2005 17:27:44 -0400

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: "Joel M. Halpern" <[email-masked]>
Date: Fri, 15 Apr 2005 19:07:10 -0400

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?

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 18 Apr 2005 07:23:37 -0400

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