Subject: Cisco SG16: Command Atomicity

From: Chip Sharp <[email-masked]>
Date: Tue, 25 Jan 2000 19:05:49 -0500

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.
--------------------------------------------------

---

From: Sachin Mittal <[email-masked]>
Date: Fri, 28 Jan 2000 10:23:49 +0530

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
Issue:          It is unclear if commands are atomic or not. More specifically,
if

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 28 Jan 2000 14:40:03 -0500

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
>
>

---

From: Sachin Mittal <[email-masked]>
Date: Mon, 31 Jan 2000 13:48:25 +0530

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]>

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 31 Jan 2000 09:15:04 -0500

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

> Sent: Monday, January 31, 2000 3:18 AM