Subject: Re: Cisco SG16: Keep Active

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 8 Feb 2000 09:08:15 -0500

Thank you for taking the time to go through your issues.
I only wish you had done so two months ago!  Before dealing with
specifics, there is one aspect of the current mechanism you seem
to have misinterpreted.  When EventBuffering is ON, events detected
are compared against the EventBuffer Descriptor, not the Events Descriptor.

...snip...
> The current event handling mechanism in Megaco/H248 v14 can
> be viewed as
> three processes that all interact. Events can be viewed as
> always being
> added to an event buffer (a FIFO queue) by an Event Detection process.

> Another Event Processing process then removes these events
> from the FIFO
> queue. When a notification is sent, this process may block,
> waiting for a
> new Events Descriptor to be received. Events detected
> meanwhile will simply
> be added to the FIFO queue. Finally, whenever a new
> Events Descriptor is
> received the third process runs. This process determines the
> fate of events
> of events sitting in the FIFO queue, and installs a new
> Events Descriptor.
>
> The processes are illustrated in pseudo-code below
>
> Process 1: Event Detection
> ===================
> do {
> <wait for new event>
> if < event in current Events Descriptor> then   /* current
> Events Descriptor
> */
>   <add event to event buffer>
>  else
>   <discard>
> } forever
The buffering process does not always buffer events.  In most
cases, it immediately Notifies.  The decision process is:
        If EventBuffering is On,
                If no events have been detected
                        ; the first event is immediately processed
                        If it is in Events Descriptor
                                Notify immediately
                        Else
                                discard
                Else
                        If it is in EventBuffer Descriptor
                                place in the buffer
                        Else
                                discard
        Else
                If the event is in Events Descriptor
                        Notify immediately
                Else
                        discard

To be really precise, it's possible that an event will occur
while another event is being processed when EventBuffering is Off,
and you could consider the second event in some kind of buffer.
I personally wouldn't - if it made it before I finished the Notify,
I'd add it to the Notify in process.  If it was after, I'd just hold
off processing it until I was done.

>
> Process 2: Event Processing
> ===================
> do {
>  < wait for event in event buffer>
>  < remove first event from event buffer>
>  if <event in current Events Descriptor> then {
>   Notify(event)
>   if  (Eventbuffer = "on") then  /* current Events Descriptor */
>    <wait for new Events Descriptor>
>  }
> } forever
I'd say this process doesn't exist

> Process 3: New Event Descriptor
> =======================
> if <Eventbuffer = "off">   /* new EventsDescritpr */
>  <clear event buffer>
> <activate new Events Descriptor>
This is incorrect.  The first part is correct (clear eventBuffer if
EventBuffering is off).  The second part is:
  Else
        While EventBuffer has any events
                If Event is in new Events Descriptor
                        Notify this event
                        Exit loop
                Else
                        discard
        End Loop

>
> Unfortunately, this mechanism suffers from some drawbacks,
> especially when
> compared to the mechanism that was specified in TD-58 after
> the Red Bank
> meeting:
>
> 1. Events to be detected in process 1 are always determined
> by the current
> Events Descriptor. This is an unfortunate restriction which may prevent
> detection of events that arrive more rapidly than the round-trip +
> processing time. For example, an application may initially
> wish to detect
> seizure, and subsequently detect a wink or unseizure. Unless
> all events are
> requested at the same time (which would effectively prevent
> glare detection)
> detection of all these events could not be guaranteed.
This is incorrect, there are two masks -- Events Descriptor and
BufferedEvents Descriptor.  The former determines what is notified,
the latter determines what is buffered.

Seizure would be Events Descriptor, Unseizure and wink would be
in BufferedEvents Descriptor.  Alternatively, you could use an
embedded Events Descriptor.

> What is needed, is an extra parameter to specify what events
> to detect (as
> opposed to process) during event buffering. Preferably, this
> set of events
> would be determined based on the union of this parameter and
> the current
> Events Descriptor.
As specified, we "detect" (I would say buffer) events in
BufferedEvents, and we "process" (I would say Notify) events in
Events Descriptor.  We could specify that detect is based on the
union of BufferedEvents and Events, but it's a little late for
optimizations (if it really is what we want, I would think not).

>
> 2. Hardcoding Notify in process 2 limits throughput, as there
> shall normally
> only be one outstanding Notify per termination. A queue of
> Notify to be sent
> may consequently build up at the sender side thereby
> - Incurring event delivery delay when the event arrival rate
> exceeds the
> MG-MGC roundtrip time.
> - Limiting the average event arrival rate to the MG-MGC
> roundtrip time (best
> case).
This may be true if EventBuffering is On, but is not true if
EventBuffering is off.  In the latter case, events are Notified as
they are detected, and no response from the MGC is required.

In the former case, this is precisely what is required.  The point of
buffering events is that once an event is detected, the MG doesn't
know what the MGC wants next; it has to wait to be told.  Meanwhile,
it buffers events the MGC told it it MIGHT want to see.  When it gets
a new event descriptor, it can send ONE event, but then it is back in
the same state - what does the MGC want to do next?

Note that this condition should be very rare - events happen at human
speed in most cases, and computers are fast.  Even in large trunk
gateways, the MGC better be able to keep up with the event stream by
a whole lot more than a round trip time!

> TD-58 from Red Bank did not have this limitation. First of
> all, the MGC had
> the various "accumulate" actions that were designed to
> prevent this problem
> and limit bandwidth and CPU overhead.
It had a per event decision of Notify, Accumulate or process by
digitmap.  We have all of those.

>Secondly, (assuming
> MGCP semantics) it
> would be possible for the MG to try and empty the EventBuffer
> in a single
> message based on the current Events Descriptor (arguably, a
> parameter to
> explicitly allow/disallow this behavior would be beneficial).
No one has ever described a scenario where it was once unacceptable to send
all events, but something occurs which makes it possible to send all events
in the buffer.  This seems unlikely
        Either the MGC is able to run it's own state machine and
                it can handle events whenever they are detected
        OR
        The MGC has a simplistic view, and can only deal with the MG
                and itself being in lockstep

>
> 3. There is a dual use of the Eventbuffer parameter which is
> unfortunate.
> Following a Notify where the Eventbuffer was "on", there is
> no way for the
> MGC to subsequently request that
> a) All the currently buffered events should be processed
> b) Future events should not be buffered events but simply
> sent immediately
This is the same as above.  Somehow, the MGC couldn't handle all
events, and now it can.  How can this be?
I would be willing, I suppose, to allow this (that is, have some way
to empty the Event Buffer by Notify rather than just clearing it),
but no one has been able to come up with a really interesting
case where the MG flips EventBuffering on and off.  I expect it will
set it one way and leave it.

Please cite an interesting case where some events should be buffered,
but there comes an event where the buffer should be sent all at
once (and where it is unacceptable to send the events as they
are detected).

> A simple solution to this problem would be to separate the
> parameter into
> two, which is precisely what the BufferedEventProcessingMode
> in TD-58 did.
Covered above, although no one could ever precisely explain to those of us
who sat through countless hours of discussion and email what the 4 states of
two variables were used for.

>
>
> Finally, from a design perspective, the above solution contains some
> fundamentally undesirable properties. Most problematic is the
> hard-coded
> Notify of events which effectively provides a stimulus based
> approach to
> event handling with none or little future support for scripting. It
> effectively prevents us from taking advantage of more powerful and
> sophisticated MGs that are able to do some amount of local processing
> thereby
> - reducing bandwidth requirements
> - reducing MGC processing requirements (and complexity)
> - improves responsiveness as the network round-trip does not become a
> bottleneck
> Opponents to this point of view may claim, that packages with
> new events,
> signals, and properties can be defined that effectively
> achieve the above,
> as e.g. was done for digitmaps/DTMF detection. While that is
> indeed the case
> (and there are valid use cases for such), the point that
> needs to be made,
> is that the mechanisms are basic and of such high value that
> they should be
> supported natively rather than only by higher level
> mechanisms which may or
> may not be able to interact with each other. Consider for example the
> current DTMF detection scheme. As a consequence of the higher
> layer approach
> taken, it is not able to report incoming DTMF digits and
> other inter-twined
> events in the correct order, since the DTMF detection
> mechanism must itself
> be exactly one event (digit map completion). Another example is the
> interaction with signal interruption, e.g. dial-tone. Again, special
> consideration (define it to take place on the first digit) is
> needed to
> achieve the desired behavior although the event really has
> not occurred yet.
Scripting is, as you know, a version 2 problem.  Presumably, scripting need
not limit itself to the same view of events, or more precisely, it would
probably handle event detection as they occurred, and generate Notifies (if
appropriate), whenever the script decided to.  I would allow scripts to run
on detection, allow them to put events in the buffer, and allow them to run
on Notify (which would include allowing the Notify script to paw through the
buffer).

> Such requirements for special treatment and consideration are simply
> evidence of lack of generality that should not show up at
> this stage. The
> solution specified in TD-58 from Red Bank did not suffer from these
> drawbacks.
Disagree as per above
>
> Some additional comments below
>
>
> "Rosen, Brian" wrote:
>
> > Coming out of Red Bank there was NO consensus on Events,
> > there was in fact wide disagreement on events.  Coming out of
> > Washington, there was NO consensus on events, there was in fact
> > wide disagreement on events.  The proposal we have in V13 was
> > an attempt to fix what people saw as problems in the event
> > mechanism.
> >
> > In Red Bank, no one could explain how the MGCP mechanism works.
> > In Washington, several people attempted to explain how it works
> > (Christian Huitema was not there for that session).  Today in
> > fact, I'll bet you if you ask 10 people who claim they understand
> > how the MGCP mechanism works, you would get several answers,
> > although I would grant you that there is not a lot of variation
> > in the implementations.  The V13 mechanism was not comprehensible
> > to anyone in the design meetings in Washington or Red Bank.
>
> If understanding the MGCP mechanism is the real problem, then
> I'm sure we
> can get the right people to clarify. Having spent a lot of
> time on this
> (admittedly confusing) aspect myself, I can certainly offer my help if
> needed. As for a general lack of understanding of the
> mechanism I think you
> are exagerating. There may be small details here and there that people
> interpret differently, but I bet you any mechanism you
> specify will suffer
> from this, including yours.

Flemming, there are a core of about 5 people who sat and argued and
questioned and puzzled about the MGCP mechanism over two IETF meetings, the
Red Bank meeting and the email list.  Check the archives - there are lots of
messages that attempt to explain how the MGCP mechanism works.  No two
people agreed.  I asked 4 people who said they were part of implementation
teams.  They all explained it differently, although it seems that they
implemented it close to the same thing.  I believe the MGCP text is poorly
written, poorly understood.  AND, even when people more or less explained
how it worked, they were totally unable to explain how you would use it.

>
>
> >
> >
> > I still have never been given any semblance of a reason why
> > the variables in the MGCP exist, and what you do with them.
> > I can, and have, provided same for the current mechanism.  So far
> > we have not, save the confusion over the digitmap/keep active
> > confusion, found a problem.
>
> If you can be more specific I will do my best to try and explain.
>
> >
> >
> > So far, I have found people who want the MGC to sort out events,
> > and they want them as fast as the MG finds them.  I also found
> > people who want a simple state machine, with the MG and MGC in
> > lock step over what should happen.  We cater to both of those.
> > You seem to want something in between, something where the MG
> > has more knowledge about what the MGC wants, and when it wants it
> > than I can figure out.  I can't understand how anything in between
> > gimme all of them, and gimme the next one can work; please
> > enlighten me.
>
> Scripting! It comes in many shapes and forms (although not as
> many and not
> as powerful as you might want right now). You have already defined one
> yourself; digit maps. What accumulate, etc. gives you is essential the
> foundation to build on here. It can even be used natively in
> some cases,
> e.g. for MF trunking if you so desire.
>
> >
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Flemming Andreasen [mailto:[email-masked]]
> > > Sent: Friday, February 04, 2000 2:11 PM
> > > To: Rosen, Brian
> > > Cc: [email-masked]
> > > Subject: Re: Cisco SG16: Keep Active
> > >
> > >
> > > Hi Brian
> > >
> > > Some comments below
> > >
> > > Regards
> > >
> > >             Flemming
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > > We have just had a discussion on this issue, and I believe it
> > > > addresses it: digitmaps on dtmf optimizes reporting
> > > > of dtmf detection, but is otherwise the same as individual dtmf
> > > > events being enabled.  By that definition, KeepActive works the
> > > > way you wanted it; without it, signals stop with first detected
> > > > digit.  With it, signals continue while digits are detected.
> > > > So your IVR app would specify KeepActive on the
> digitmap completion
> > > > event, and use an embedded signal to turn it off if you
> wanted to.
> > > > The old mechanism doesn't work any differently; if you
> had specified
> > > > keepactive on the digits, whether or not they were accumulate by
> > > > digitmap actions, you still would not be able to treat
> the initial
> > > > digit differently from the terminating digit.  The only way you
> > > > could make this better would be to have the digitmap completion
> > > > event entirely separate from the dtmf detection events, so you
> > > > could have KeepActive separately on the digits from the
> completion.
> > > > I think embedded signals is a better answer, but I'm on
> record as
> > > > thinking that digitmaps should be a package and not a basic
> > > > protocol.
> > > >
> > > > I'll deal with any problems we still have with the current text,
> > > > but a "everything changed" complaint without a problem
> is a no-op.
> > >
> > > I beg to differ. A change without a problem is
> > > counterproductive and what
> > > gets into these situations. We had something perfectly fine
> > > after the Red
> > > Bank meeting which for some reason was changed. Exactly
> *what* was the
> > > problem that prompted this massive change (I'll spare you
> the ITU-T
> > > procedural arguments here). If there were no compelling
> > > reasons, then I
> > > suggest that the text is simply brought back in line with the
> > > agreement from
> > > Red Bank, and then we can close this (big) one and move along.
> > >
> > > If you really want to, we can start a debate about the
> > > relative merits,
> > > trade-offs, and shortcomings of one scheme versus the other.
> > > A couple of
> > > topics off the top of my head
> > > - Reduced number of messages and resultant reduced load
> on network and
> > > entities
> > > - Effective event arrival rate not limited by MGC-MG
> round-trip time
> > > - Support for scripting
> > >
> > >
> > >
> > > >
> > > >
> > > > brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Chip Sharp [mailto:[email-masked]]
> > > > > Sent: Friday, February 04, 2000 12:12 AM
> > > > > To: [email-masked]
> > > > > Subject: Re: Cisco SG16: Keep Active
> > > > >
> > > > >
> > > > > At 03:22 PM 2/3/00 -0500, Tom-PT Taylor wrote:
> > > > > >
> > > > > >
> > > > > >I think the primary need here is for clarifying text in
> > > > > section 7.1.14
> > > > > >indicating that events mapped into a digit map do
> not generate
> > > > > >notifications, but do terminate ongoing signals unless the
> > > > > KeepActive flag
> > > > > >is set.
> > > > > Not really. The fundamental problem is the complete rework of
> > > > > the agreed
> > > > > upon event handling mechanism that for some reason was done
> > > > > after the Red
> > > > > Bank meeting.
> > > > >
> > > > > >
> > > > > >-----Original Message-----  From:  Chip Sharp
> > > > > >[SMTP:[email-masked]]  Sent:  Tuesday, January
> 25, 2000 7:43
> > > > > >PM  To:    [email-masked]  Subject:
> > > > >   Cisco SG16:
> > > > > >Keep Active
> > > > > >
> > > > > >Section:        7.1.9, "Event Actions"
> > > > > >table  Category:       Technical  Issue:          The draft
> > > > > text specifies
> > > > > >that "KeepActive:      As Notify, but  production of signals
> > > > > continues (if
> > > > > >any signals were active)".The above  definition is overly
> > > > > restrictive in
> > > > > >that it prevents events from being  accumulated (either with
> > > > > or without
> > > > > >digit map) and at the same time keeping  a signal active.
> > > > > For example an
> > > > > >IVR application accumulating a string of  user input and
> > > playing an
> > > > > >announcement until the entire string is  accumulated cannot
> > > > > be supported
> > > > > >with the above behaviour.  Proposal:       It is
> > > recommended, that
> > > > > >"KeepActive" does not generate a "Notify"  and that it
> > > > > becomes possible to
> > > > > >specify multiple actions such that  "KeepActive" can be
> > > > > combined with,
> > > > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
> > > the particular
> > > > > >application.
> > > > > >
> > > > > >v13 Status:     OPEN. Event actions table has been
> removed and
> > > > > >extensive  modification of entire event processing
> taken place.
> > > > > >
> > > > > >Section:        7.1.9  Category:       Technical  Issue:
> > >          The
> > > > > >draft text specifies that "When KeepActive is specified
> > > as the  event
> > > > > >action, the media gateway shall send a Notify message to the
> > > > >  controller
> > > > > >upon detection of the event. Furthermore, the controller
> > > shall  not
> > > > > >interrupt any signals active on the Termination on which
> > > the event
> > > > > >is  detected" The above definition is overly restrictive
> > > in that it
> > > > > >prevents  events from being accumulated (either with or
> > > > > without digit map)
> > > > > >and at the  same time keeping a signal active. For
> example an IVR
> > > > > >application  accumulating a string of user input and
> playing an
> > > > > >announcement until the  entire string is accumulated cannot
> > > > > be supported
> > > > > >with the above behaviour.  Proposal:       It is
> > > recommended, that
> > > > > >"KeepActive" does not generate a "Notify"  and that it
> > > > > becomes possible to
> > > > > >specify multiple actions such that  "KeepActive" can be
> > > > > combined with,
> > > > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
> > > the particular
> > > > > >application.
> > > > > >
> > > > > >v13 Status:     OPEN. Extensive modifications of event
> > > handling has
> > > > > >taken  place. Events now always reported immediately on
> > > detection.
> > > > >
> > > > > Support NetAid!  http://www.netaid.org
> > > > > --------------------------------------------------
> > > > > Chip Sharp                 Consulting Engineering
> > > > > Cisco Systems              Telco Bio-region
> > > > > Reality - Love it or Leave it.
> > > > > --------------------------------------------------
> > > > >
> > >
> > > --
> > > ---------------------------------------
> > > Flemming Andreasen
> > > Cisco Systems
> > > ---------------------------------------
> > >
> > >
>
> Regards
>
>         Flemming
>
> --
> ---------------------------------------
> Flemming Andreasen
> Cisco Systems
> ---------------------------------------
>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 8 Feb 2000 10:26:58 -0500

Brian

Thanks for your detailed response - a detailed answer follows below. To
summarize for those that do not feel like going through all the details here:
1. I still see significant drawbacks with the v14 scheme
2. I do not see those drawbacks with the TD-58 scheme
3. I have seen no advantages being offered with the v14 scheme compared to the
TD-58 scheme

and consequently I must ask for the TD-58 scheme to be reinstated.

> are compared against the EventBuffer Descriptor, not the Events Descriptor.

You are right. While that addresses one specific comment below, it does not
solve the fundamental problems though.

> The buffering process does not always buffer events.  In most

Like I said, one way of viewing the procedure is the way I describe it. This is
classic producer-consumer problem we are looking at here.

> off processing it until I was done.

That's not what the current text specifies, so if this is the behavior you want
the text should be changed accordingly.

> I'd say this process doesn't exist

Depends on how you look at it. Like I said, this is one way of looking at it. It
achieves precisely the same as your algorithm above

>                 If Event is in new Events Descriptor

No. Take another look at process 2, which is my consumer process. The effect is
precisly what you have specified, however all of these are really besides the
point.

> the latter determines what is buffered.

You're right. I believe it would be preferable to determine events to be
detected based on the union of Events Descriptor and BufferedEvents Descriptor
though.

> embedded Events Descriptor.

For this specific case - maybe. It is not a general solution to the problem
though (BufferedEvents Descriptor on the other hand is).

> they are detected, and no response from the MGC is required.

That is completely inconsistent with the current text. Section 9.1 specifies
that:

    "On a given Termination, there should normally be at most one outstanding
Notify command at any time.  The RequestId parameter should be used to correlate
Notify commands with the triggering notification request."

What you are suggesting is that we just send the Notify's as fast as we can. The
problem with this is that you cannot guarantee in-order (delivery of these
messages) which means we no longer have event ordering in the system.

> the same state - what does the MGC want to do next?

We are in absolute agreement here. One underlying "problem" however is that the
MGC will only be able to request a single event. With the TD-58 solution you
could have requested a whole sequence of events potentially.

> a whole lot more than a round trip time!

That is a very dangerous assumption which even now doesn't hold. Think about
auto-dialers, MF trunking, etc. Events happen a lot faster than human speed
(which is why you added digit maps). Do you feel confident in assuming that this
is the only case where this is needed ?

As for your second point about MGC being able to keep up with event arrival
rates significantly below network round trip time we are in complete agreement,
and that is precisely my point. Your mechanism has an inherent rate limitation
built into it, and that rate limiation is based on the network round-trip time
for every thing where you don't apply some special mechanism (like digit maps).
This mechanism is basic and belongs in the base protocol!

> digitmap.  We have all of those.

Then I've misunderstood something. Where do you have accumulate now ?

>                 and itself being in lockstep

You are making dangerous assumptions again. Experience has taught me that proper
design rather than current perception and imagination is by far the better
approach.

> set it one way and leave it.

Same comment as above. I would much prefer proper design instead assumptions
which may or may not hold down the road.

> once (and where it is unacceptable to send the events as they

Same comment as above.

> two variables were used for.

I disagree. Experience will tell us who is right. With my approch we can't
loose, with yours we certainly can.

> on Notify (which would include allowing the Notify script to paw through the

Yes I know. What you are telling me know, is that yes, the current event
handling mechanism is probably not adequate for scripting and you would do
something special, e.g. not perform the hard-coded Notify we saw above. What
about interaction between different schemes, consistency, ease of understanding,
etc. This looks very flaky to me and that is precisely my point.

> > solution specified in TD-58 from Red Bank did not suffer from these

You are going to have to explain the drawbacks of TD-58 to me. I have now
offered you drawbacks with the v14 scheme. Considering that I have not seen you
(or anyone else for that matter) explain any kind of drawbacks with the TD-58
scheme and that I have shown several drawbacks with the v14 scheme, I think it
is your turn to explain the problems with TD-58 now. You have been very adament
about not making changes without any good reason, so I would like to see that
same rule applied to TD-58.

> how it worked, they were totally unable to explain how you would use it.

I'm not talking about MGCP, I'm talking about TD-58. You are the editor and have
done an outstanding job under some very different circumstances. If there is
text that needs clarification, well then clarify it, don't scratch the mechanism
and rewrite it from scratch.

What if I ask you to explain how multimedia and streams work and whether they
are indeed adequate for what we want to do. I bet you will have a very tough
time (I know since you've stated your concerns on this issue several times)
doing that, but that doesn't meen you just rewrite it, right ?

In any case, we are drifting away from the technical points, which is what I
want to focus on. Bottom line is, that I strongly believe the TD-58 scheme was
better than what we now have in v14. Based on all of the above and in the
absence of you explaining any problems with the TD-58 mechanism and
demonstrating advantages with the v14 mechanism, I must again ask for the text
to be brough back in accordance with the outcome of the Red Bank meeting. If
not, we have a significant change, and no consensus....

Regards

        Flemming
-