Subject: Re: Event handling questions

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 7 Mar 2000 22:36:24 -0500

It seems to me that a particular MGC will either keep EventBufferControl on
or off.
There has to be a way to clear the buffer.  Turning it from on to off seems
to be
an appropriate way to do that.

Brian

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Tuesday, March 07, 2000 11:04 AM
> To: [email-masked]
> Subject: Re: Event handling questions
>
>
> Tom-PT Taylor wrote:
>
> >
> >
> > Replies below.
> >
> >      -----Original Message-----
> >      From:   Flemming Andreasen [SMTP:[email-masked]]
> >      Sent:   Tuesday, March 07, 2000 10:03 AM
> >      To:     [email-masked]
> >      Subject:        Event handling questions
> >
> >      A couple of questions on the event handling (7.1.9):
> >
> >      1. It is specified that "When the MG receives a command with a
> >      new
> >      EventsDescriptor, one or more events may have been buffered in
> >      the
> >      EventBuffer in the MG. The value of EventBufferControl then
> >      determines
> >      how the MG treats such buffered events."
> >
> >      I assume that the "the value of EventBufferControl"
> refers to the
> >      value
> >      in the new command (if supplied), not the old, correct ?
> >      [[TomT]]
> >      That is correct.
> >
> >      2. It is specified that "If the MG receives a command
> instructing
> >      it to
> >      set the value of EventBufferControl to Off, all events in the
> >      EventBuffer SHALL be discarded."
> >
> >      This seems rather strange to me as you will be dropping events
> >      for no
> >      apparent reason. Can somebody please explain the
> rationale behind
> >      this ?
> >
> >      [[TomT]]  If the MGC turns EventBufferControl off, it
> must have a
> >      reason for doing so.  The same reason presumably extends to the
> >      treatment of events already in the buffer.
> >
> I don't follow. How does that justify throwing away the
> events that were
> already buffered ? The only thing you are changing is the way
> you report
> events. For example consider the case where the set of events to be
> detected in the two commands are exactly the same but the
> EventBufferControl differs.
>
>
>
> >
> >      Thanks
> >
> >              Flemming
> >
> >      --
> >      Flemming Andreasen
> >      Cisco Systems
> >
> --
> Flemming Andreasen
> Cisco Systems
>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 8 Mar 2000 10:37:10 -0500

> an appropriate way to do that.

You can argue either way, which is why I've always argued this should have been
two instead of one parameter. In the absence of that the question then becomes
whether you should always drop the events or not. The safe approach which
satisfies all scenarios is not to drop them which actually has the effect of
clearing the buffer as well since the MG is fully allowed to empty the
eventbuffer in a single Notify message when EventBufferControl is off.
Consequently I say they should not be dropped.

--
Flemming Andreasen
Cisco Systems

---

From: John Segers <[email-masked]>
Date: Thu, 9 Mar 2000 11:27:51 +0100

Flemming,

You're right in saying that it is not forbidden to have all events in
the buffer notified in one go (although there is no text that says when
one would include multiple events in one Notify).  Also, it is allowed
for the MGC to send one message that audits the observed events
descriptor (so it gets all events currently in the buffer), and clear
the buffer by setting eventbuffercontrol to Off.  So it seems to me that
you can do what you want without changing the protocol.

And you have a means for the MGC to reduce the traffic if it really
thinks that it doesn't need to see the buffered events.

Cheers,

John

--
John Segers                                  email: [email-masked]
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

---

From: John Segers <[email-masked]>
Date: Thu, 9 Mar 2000 14:34:14 +0100

Flemming,

Please see below.

John

Flemming Andreasen wrote:
> John Segers wrote:
> > one would include multiple events in one Notify).
>
> So add such a sentence or put it in an implementors guide.
>
> > Also, it is allowed
> That's not clear. Section 7.2.9 on auditing context attributes specifies that the
> values of the audited attributes returned are the values that result *after* the
> manipulation request(s) have been processed. I would have thought the same applies to
> auditing in a command. If not, I would say it needs to be spelled out.
>
> Besides, your proposal suffers from an event ordering problem. It is entirely
> possible that the reply will arrive at the MGC after a new Notify issued does.

Section 7.2.9 is indeed on _context_ attributes (note that the phrase
"command" is not used in 7.2.9).  Section 8 explains that _commands_ in
a transaction are executed in the order they occur.  AuditValue being a
command, it is treated according to this ordered execution.

I don't understand the ordering problem you refer to.  When in LockStep
mode, the MGC determines whether the MG can send a Notify.  If it is
expecting one, it would hold off on auditing the
ObservedEventsDescriptor.  Where does the ordering go wrong?

> > thinks that it doesn't need to see the buffered events.

[snip]

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 9 Mar 2000 08:25:53 -0500

> John

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 9 Mar 2000 09:05:43 -0500

> command, it is treated according to this ordered execution.

If you try to use two commands, one to audit, and another to change EventBufferControl,
then there's clearly a window between the two that will allow one or more additional events
to occur, which will then be lost. You need some kind of exclusive access here, and the
closest you will get is to use a single command the way the protocol is defined.
Consequently, for your solution, it becomes important to know precisely how a command is
actually executed.

> ObservedEventsDescriptor.  Where does the ordering go wrong?

Trouble is that detecting and reporting events are two different things. Regardless of
whether you are in LockStep mode or not, events can continuously be added to the
eventbuffer. Thus separate actions, commands or transaction will not work. If we go back to
a single command that then tries to achieve what we are looking for by auditing observed
events and changing the events descriptor at the same time we observe that the is no
ordering requirement between
1. A transaction reply
2. A Notify command
Consequently 2 may arrive at the MGC before 1 and you have out of order event reporting
(irrespective of what one might think about using audits to do event "reporting")

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: John Segers <[email-masked]>
Date: Thu, 9 Mar 2000 16:06:05 +0100

[snip]

> Consequently, for your solution, it becomes important to know precisely how a command is

Actually, in my solution you can do it in one command.  You can include
an AuditDescriptor in the Modify that changes the value of
EventBufferControl.

> (irrespective of what one might think about using audits to do event "reporting")

I think that it is important whether you are in LockStep mode or not.
When in LockStep, the MGC determines when the MG will send a
NotifyRequest.  So, the MGC should take care not to allow the ordering
problem to occur.  If it doesn't do so, then the time stamps on events
allow the MGC to determine the order in which events occurred if a
NotifyRequest and ModifyReply (or AuditReply) containing observed events
occur independently.

[snip]

John

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 9 Mar 2000 15:10:54 -0500

John Segers wrote:

> problem to occur.

You are missing the point. The MGC has no way of preventing it from occurring. It is an inherent
"feature"

> If it doesn't do so, then the time stamps on events

Well that now assumes that auditing is done prior to the command being executed as opposed to
after which hasn't been clarified/resolved yet. Even so, this "reporting" via auditing seems a
rather strange design to me.

In any case, I've provided my comment and made my point. Doesn't seem like much will be achieved
by continuing this discussion.

-- Flemming

--
Flemming Andreasen
Cisco Systems