Subject: Re: Cisco SG16: Command Atomicity

From: Michael Brown <[email-masked]>
Date: Thu, 3 Feb 2000 14:10:06 -0500

I apologize for the delay in responding to this thread and thank Tom for the
gentle nudge to do so.

As he indicated, I continue to believe that the intent of command atomicity,
that is, the "ability of  the MG to rollback a failed command to result in a
well known state", is unrealizable. The primary reasons are the level of
intelligence which must be resident in the MG in order to do this and the
inability to make a simple definitive statement about what a "well known
state" is.

Regarding the level of intelligence, the MG essentially would have to have a
knowledge of call state and behavior in order to provide a rollback behavior.
I believe this is inappropriate for the MG. It is up to the MGC to understand
that, within the context of call state, what actions need to be taken given
the failure of a particular command. Bottom line is that I don't believe that
reacting to a command failure is as simple as undoing what had been done so
far.

For that reason, I don't believe that making transactions atomic really makes
this problem significantly different. As Brian suggested, it would be easier
than trying to rollback multiple commands in a transaction, but it doesn't
change the above reasons for not attempting to provide rollback.

I think that  to address the need for clarification, it would be better to
add a paragraph to section 8, p. 47, paragraph 3, to describe this behavior:

 "If the MG is not able to successfully execute the command, but was
  able  to accomplish some of the work indicated by the command, it should
not
  attempt to "roll-back" to the state before this command.  The MGC is
responsible
  for determining the action to be performed based on the command failure.
The MGC could,
  if necessary, audit the termination to determine the current state of the
MG.  E.g.,
  if the MG failed on a previous command that had an events descriptor,  the
events
  descriptor returned in a subsequent audit would only show the events for
which the MG is currently
  scanning"

Michael Brown

"Rosen, Brian" wrote:

> At some point, we have to stop holding up release of the document for
> changes such as this where a request is made to clarify behavior as
> opposed to changing behavior.  I believe that point has already occurred,
> but that is for the group to decide.
>
> Brian
>
> > -----Original Message-----
> > From: Sachin Mittal [mailto:[email-masked]]
> > Sent: Monday, January 31, 2000 3:18 AM
> > To: [email-masked]
> > Subject: Re: Cisco SG16: Command Atomicity
> >
> >
> > I think that although MG is dumb and MGC has the full responsiblitiy
> > of command sequencing some kind of guidelines should be there for MGC.
> > A step in this direction is already taken by moving "Ordering
> > of commands"
> > to section 9.1 from "transport over IP".
> >
> > This can include cases like the race condition we discussed
> > in this thread
> > and may be the following (taken from other thread):
> >
> > Quote starts................
> > > The MGC is responsible for making the state consistent, and this
> > > means getting the Subtract through.
> > >
> > > A termination could be out of service, but still in a context,
> > > and would be under failure conditions.  The MGC must run the
> > > Subtract command to get the state reasonable.
> > >
> > > If a command other than Subtract (or ServiceChange) was
> > received on a
> > > termination that is out of service, an error should be returned.
> > End quoted text...........................
> >
> > One important thing about the above quoted text is that MG is also
> > co-operating with MGC for bringing the termination to a
> > reasonable state
> >
> >
> >
> >
> >
> >
> > "Rosen, Brian" <[email-masked]> on 01/29/2000 01:10:03 AM
> >
> > Please respond to "Rosen, Brian" <[email-masked]>
> >
> > To:   [email-masked]
> > cc:    (bcc: Sachin Mittal/HSS)
> >
> > Subject:  Re: Cisco SG16: Command Atomicity
> >
> >
> >
> >
> > I have advocated since day one that commands should be atomic.
> > Indeed, I believe transactions should be atomic.  I was
> > in a minority who believed that backing out of
> > a failed transaction a couple of commands in was too hard.
> >
> > Now we notice that same applies to a command, a couple of
> > descriptors in.  If a command is atomic, and it fails, then
> > you have to back out of whatever you started, and leave the
> > state of the MG the same as it was before you started
> > executing the command.
> >
> > Count me as in favor of atomic commands.
> > Of course, count me as in favor of atomic transactions, although
> > it's probably easier to back out of a command than a transaction;
> > not much easier, but easier.
> >
> > Note that the text now recommends additional information be
> > appended to an error descriptor.  I think codifying such behavior
> > is better left for another day; we need more experience before
> > we try to write down what ought to be included.
> >
> > Your specific issue with MOVE's interaction with NOTIFY is
> > a little puzzling.  I'm guessing you are worried that
> > there is an active EventsDescriptor on a termination, and then
> > you MOVE that termination to another context.  The question
> > arises, what should occur if the event happens during the processing
> > of the MOVE.
> >
> > This is a kind of race condition.  If the MGC has left itself open
> > for such a problem, then it had better not matter to it that it
> > could see a Notify from an earlier EventsDescriptor after it sends
> > a Move.  If the Move arrived after the Notify was issued, the problem
> > is the same as if the Notify were issued in the middle of, or even
> > after the Move.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Sachin Mittal [mailto:[email-masked]]
> > > Sent: Thursday, January 27, 2000 11:54 PM
> > > To: [email-masked]
> > > Subject: Re: Cisco SG16: Command Atomicity
> > >
> > >
> > > This issue has another consequence. For example while
> > > processing MOVE command
> > > if any event need to be NOTIFIED to MGC, then this notify
> > > message need to be
> > > delayed
> > > till the time response of move is sent. This introduces
> > > latency in sending the
> > > notify message
> > > which by its purpose should not be delayed (MOVE has to tear
> > > down old star
> > > connection
> > > and create a new one in the destination context which may
> > take time).
> > >
> > > Any comments >>>
> > >
> > >
> > >
> > >
> > >
> > >
> > > Chip Sharp <[email-masked]> on 01/26/2000 05:35:49 AM
> > >
> > > Please respond to Chip Sharp <[email-masked]>
> > >
> > > To:   [email-masked]
> > > cc:    (bcc: Sachin Mittal/HSS)
> > >
> > > Subject:  Cisco SG16:  Command Atomicity
> > >
> > >
> > >
> > >
> > > Section:        8
> > > Category:       Technical, Editorial
> > > Issue:          It is unclear if commands are atomic or not.
> > > More specifically,
> > > if
> > > a command contains signals, events or digit map
> > descriptors, will they
> > > still be applied if the command fails ? If not, should the
> > > state of the
> > > termination be reset (i.e. clear the signals, events, digit
> > > map named in
> > > the command that has failed, as in MGCP 0.1) or maintained
> > > (i.e. as if the
> > > command is not received, as in MGCP 1.0) ?
> > > Proposal:       It is recommended that commands are atomic so
> > > that failed
> > > commands leave the gateway in a well known state. It is furthermore
> > > proposed, that a response descriptor should be added to the
> > > responses so
> > > that if a command fails, the gateway can provide more
> > > information to the
> > > MGC, rather than just an error code, e.g. for redirection.
> > >
> > > v13 Status:     OPEN. No relevant text changed.
> > >
> > >
> > > Support NetAid!  http://www.netaid.org
> > > --------------------------------------------------
> > > Chip Sharp                 Consulting Engineering
> > > Cisco Systems              Telco Bio-region
> > > Reality - Love it or Leave it.
> > > --------------------------------------------------
> > >
> >