Subject: Re: T13) Transactions - allowing optional commands

From: Fernando Cuervo <[email-masked]>
Date: Fri, 13 Aug 1999 10:19:53 -0400

removing transactions..hummm
Since an action refers to a context it seems to me that transactions are
quite useful for services such as call transfers and call waiting..I think
is worth keeping them.

Fernando

> ----------
> From:         Brian Rosen[SMTP:[email-masked]]
> Sent:         August 12, 1999 7:54 PM
> To:   [email-masked]
> Subject:      Re: T13) Transactions - allowing optional commands
>
> Could we have a wider discussion of why transaction syntax
> is too hard to do?  I think this is not true; while not
> trivial, I believe it is straightforward to undo any command in a
> transaction, or do enough pre processing to know that the
> transaction will complete prior to actual execution.
>
> I, for one, would like to undo this change made in Berlin.
>
> Optional commands are not required IMO.  Just make them separate
> transactions.  Actually, it's not clear to me that if we
> get rid of transaction syntax, that the whole transaction mechanism
> should just be eliminated entirely.
>
> Brian
>
> > -----Original Message-----
> > From: Nancy-M Greene [mailto:[email-masked]]
> > Sent: Thursday, August 12, 1999 2:59 PM
> > To: [email-masked]
> > Subject: T13) Transactions - allowing optional commands
> >
> >
> > > T13) Section 6.4.1, 6.4.3.1,6.4.3.2, 6.4.3.3: Simplify transaction
> > > semantics
> > > - changes to text and to ABNF (Annex B) made: removed the concept of
> > > rollback on transactions - the document did not define how
> > you could roll
> > > back commands that actually cause physical changes on the MG, e.g.,
> > > sending
> > > of a signal, subtracting a termination from a context.
> > >
> > > It was decided that in fact, all a transaction does, is ensure that
> > > commands
> > > occur in a particular order, and that no commands after a
> > command that
> > > fails, gets executed. In a TransactionAccept, need to say
> > what a response
> > > is
> > > - added sentence on this. In a TransactionReject, the
> > command that failed
> > > has error code, all the rest of the commands are not executed.
> > >
> > >
> > In Berlin, Christian Groves brought in a contribution asking
> > for transaction
> > to allow optional commands. I think this is something we need
> > to add: We
> > need to allow the failure of a command in an action to not
> > stop execution of
> > further commands in that action. Same thing for action: allow
> > the failure of
> > an action to not stop execution of further actions in the transaction.
> > Christian Groves' example was that you might have 20 adds to
> > do, and if one
> > fails you still want the other 19 to go ahead.
> >
> > Here is another example:
> > Transaction = 1 { Context = 2 { Add = $ {addparams}, Subtract
> > = a5, Add = $
> > {addparams} } }
> > If the Subtract fails, you still want the second Add to occur.
> >
> > We propose adding an optional tag to each command, and to
> > each context, for
> > example:
> > Transaction = 1 { o-Context = 2 { Add = $ {addparams},
> > o-Subtract = a5, Add
> > = $ {addparams} } }
> >
> > The o- on the Context says that if there were other actions in the
> > transaction, they would be executed even if the action on this context
> > failed. The o- on the Subtract means that commands after the
> > Subtract are
> > executed even if the Subtract fails.
> >
> > proposed ABNF:
> >
> > > ; This PR must contain at least one actionReject.
> > > transactionReject =  RejectToken EQUAL TransactionID
> > >                      LBRKT (actionReject|actionAccept) *(COMMA
> > > (actionReject | actionAccept))
> > > RBRKT
> > >
> > > ;This PR must contain at least one commandReject
> > > actionReject =       CtxToken EQUAL ContextID
> > >                      LBRKT (commandReject|commandAccept) *(COMMA
> > > (commandReject | commandAccept
> > > )) RBRKT
> > >
> > >
> >         A further simplificaton would be that transaction
> > just has one type
> > of reply, called transactionReply - you really don't need
> > transactionReject
> > and transactionAccept - with this new sytnax they can be identical.
> >
> >         Same thing for action - instead of actionReject and
> > actionAccept, we
> > just need actionReply.
> > >
> > --------------------------------------------------------------
> > ------------
> > > Nancy M. Greene
> > > Internet & Service Provider Networks, Nortel Networks
> > > T:514-271-7221 (internal:ESN853-1077) E:[email-masked]
> >
>

---

From: Richard Bach <[email-masked]>
Date: Fri, 20 Aug 1999 17:24:02 -0500

Greetings Everyone,

I've been following the tread on transactions and have also reviewed the
transaction material in the Megaco/H.248 draft resulting from the Berlin
meeting.  There are few areas of inconsistency that I hope some of you on
the list might clarify for me.

1. Transactions are defined in the as part of the application layer in
section 6.4.  Transactions are also discussed in section 6.6 - the transport
layer.  It is not quite clear if these two sections are referring to the
same transactions.  I think they are.  If they are, either the transport or
application layer should be responsible for maintaining the integrity of the
transactions, but not both.  So transactions should be discussed in one
section, but not both.  It would be alright for one section to reference the
other.

2.The first sentence of section 6.6.1 says:

   "The transport mechanism for H.248 should allow for
    the reliable transport of H.248 transactions between
    MC and MG."

The application layer clearly show transactions enveloped within a message.
Shouldn't the transport mechanism allow for the reliable transport of
"messages" since this is the outer envelope for the application layer?  Or
is the transport layer allowed to reach inside the application layer?

3. Perhaps this question is a bit naive, but since it seems that everyone
tends to agrees that individual commands are atomic operations isn't the
transaction mechanism redundant?

4. Section 6.4 only seems to imply that transactions are used to bundle
action/context which bundle commands in a set order.  With actions being
atomic, is the 'message->transaction->action/context' enveloping overkill?

One thing that may help in the transaction discussion are some concrete
examples where all the enveloping is required because the relationships
between commands demands it.  Most examples in the current draft show only
one command being enveloped.  There are a few examples of two commands.
There are no examples of multiple transactions or multiple actions in a
message.

Here my diagram of a Megaco message.  Did I get it right?

        Message (mId) {
           Transaction_1 (tId) {
              Action_1(contextId) {
                  Command_1(parameters)
                  Command_2(parameters)
                  ...
                  Command_N
               }
               Action_2(contextId) {
                  Command_1(parameters)
                  Command_2(parameters)
                  ...
                  Command_N(parameters)
               }
               ...
               Action_N(contextId) {
                  ...
               }
            }
            Transaction_2(tId) {
               Action_1(contextId) {
                  Command_1(parameters)
                  Command_2(parameters)
                  ...
               }
               Action_2(contextId) {
                  Command_1(parameters)
                  Command_2(parameters)
                  ...
                  Command_N(parameters)
               }
               ...
               Action_N(contextId){
                  ...
               }
            }
            TransAction_3(tId) {
               ...
            }
            ...
            TransAction_N(tId){
               ...
            }
        }
        End-of-Message

-- Richard

> From: Rex Coldren [SMTP:[email-masked]]
> Sent: Thursday, August 19, 1999 8:02 PM
> Tom,
>    Individual commands are atomic, with the wildcarded exception you have
> noted.  I think of the wildcard command as a pile of individual commands,
> each of which is atomic in nature.  Failures can happen on any and all of
> the
> individual commands that derive their existence from the wildcard.  This
> makes
> sense.  Others have pointed out that the MG may not be able to unwind the
> actions of those commands that have succeeded and, in fact, the MGC may
> not want this to happen.  Leave it to the MGC to deal with the individual
> failures.  An MGC that can't implement this successfully will eschew the
> wildcard capability.
>
> Rex
>
> Tom-PT Taylor wrote:
>
> > Can everyone agree on my first point, that individual commands are
> atomic
> > and the MG is responsible for resetting itself to the state it held
> before
> > it attempted to execute the command?  This would simplify the MGC
> recovery
> > process, not to mention reduce the incidence of inconsistencies at the
> MG.
> >
>
<snip>

---

From: Michael Thomas <[email-masked]>
Date: Sun, 22 Aug 1999 12:33:08 -0700

Christian Groves writes:
 > One is the rolling back of commands or as Brian puts it below 'undo any
 > command in a transaction'.In theory it is certainly possible to do this
 > in practise it doesn't always work. Think of tone generation once you've
 > sent a tone how do you undo this???? That's why I think rollback isn't
 > practical.
 >
 > Secondly, optionality - As Nancy mentioned below I put in a contribution
 > in Berlin on having optionality of commands. This was brought in to
 > start general discussion in the area of command handling. I think that
 > you have to treat each command sequentially and atomically otherwise
 > interoperability between different vendors may be 'interesting' if they
 > parse commands differently.

   I'm not sure if this horse is well beaten by
now, but I'd like to point out that this entire
issue with transactions is really scripts in
disguise: a script can be defined as a sequence of
commands which can have conditional branching on,
including error conditions. Transactions of the
kind that Christian is proposing here are of the
"on error branch to" variety. Transaction in the
current draft are of the "execute all of these and
roll back if you encouter an error".
   As the discussion at Berlin and the messages
here show, there is quite a bit of dispute about
the semantics of any sort of scripting ability,
including rollback. At Berlin, it was decided to
make scripting "for future study". I propose that
we honor that decision and that we remove the
Transaction language as Nancy proposes and define
a new keyword/semantics which says that a message
can contain multiple commands, but there is no
implied relationship between the commands. If an
MGC wants finer control of intra-command errors,
it MUST NOT group them into a single message.
   Scripting, IMO, is not something that should be
half baked; it significantly adds to the number of
unforseen edge conditions and missing semantic
rules of the protocol which directly translates to
interoperability problems. Creating a first
version of the protocol without it will give the
opportunity via real call flows, error conditions,
deployment, etc to see what parts of the protocol
would benefit from scripting.

                Mike

---

From: Natarajan Kalpathy <[email-masked]>
Date: Mon, 23 Aug 1999 11:19:25 -0500

Hello   Megacoans

Can  you  please  explain the  following to me

  Regarding  2 )  The  Call  waiting  scenario  your  talking  about  . Wont  we
be  using the  move  command  staight  away  in  that  case ??.

Regarding 3)   Also i  cannot imagine  why  two  commands   which  belong  to
two  different  calls  need  to  share  fate  in  an  transaction . In other
words  there  shouldn't  be  two   different  action  belonging  to  the  same
transaction .

Natarajan

Tom-PT Taylor <[email-masked]> on 08/23/99 08:47:11 AM

Please respond to Tom-PT Taylor <[email-masked]>

Sent by:  Tom-PT Taylor <[email-masked]>

To:   [email-masked]
cc:    (Natarajan Kalpathy/MW/US/3Com)
Subject:  Re: T13) Transactions - allowing optional commands

No, this hasn't quite been beaten to its knees.  In our original intent,
transactions had three roles:

(1) as an atomic element of execution.  That is the aspect that seems to be
discredited.
(2) as a semantic unit defining the order of execution of the commands
contained therein.  We still need to discuss this one.
(3) as the unit of application-level acknowledgement.  This also needs to be
discussed.

Regarding (2): there are two points to think about.  One is that there may
be dependencies between individual commands.  The second is that we also
have another unit of grouping: by action or context.  There could be
dependencies between actions.  I'm mulling over the call waiting case in my
mind, to see if it provides an illustration of this, but I haven't come up
with anything yet.

Regarding (3): we have a choice between the command, the action, or the
message as the unit of acknowledgement.  Whichever we use has to be uniquely
identifiable in the response.  This doesn't introduce anything new in
principle.  We also have to bear in mind the different lengths of time that
different commands may take to execute.  The unit of acknowledgement affects
message volumes and what records the issuer of a command has to maintain.
There's a tradeoff here: smaller acknowledgement units may mean increased
acknowledgement message volume, but the command issuer can release records
sooner.

> From: Michael Thomas [SMTP:[email-masked]]
> Sent: Sunday, August 22, 1999 3:33 PM
        [[TomT]]  ...
> including error conditions.
        [[TomT]]  ...
>   I propose that
        [[TomT]]  ...

---

From: Richard Bach <[email-masked]>
Date: Fri, 27 Aug 1999 10:08:44 -0500

Dave,

I am shaking my head also.  With 'atomic' commands being wrapped in
contexts, transactions, and messages it hard to tell from which level
acknowledgements should come.  I've never seem a call control protocol that
uses transactions. Remote operation semantics are sufficient.

I think all that is needed are for commands to be bundled in a message.
ContextID could simply be a parameter of a command.  The move command is
particularly interesting.  As I see it, the move command is wrapped in is
the new context for the termination being moved.  When the move command is
executed, the termination is implicitly subtracted from it old context.
This implicit side affect is due to the current complexity of protocol.  If
a move command simply contained the IDs for the old and next context, things
would be simpler and more obvious.  With the current design of context being
external to commands there is no way to explicitly provide both the old and
new context.

--Richard

> From: David Oran [SMTP:[email-masked]]
> Sent: Friday, August 27, 1999 9:13 AM
> Is anybody besides me shaking their head about how complicated we're
> making
> this poor protocol? Are we going to wind up with 3 years of
> interoperabilty
> workshops before a customer can be confident about interoperability (you
> all
> know what protocol I'm refererring to here :-) ).
>
> I think we should at least think about Christian's suggstion that we just
> go
> back to individual atomic commands and pitch all the rest of the
> complexity,
> or, as Mike Thomas suggested, punt such complicated stuff to scripts.
>
> Dave.
>
>

---

From: Christian Huitema <[email-masked]>
Date: Fri, 27 Aug 1999 18:04:10 -0400

At 04:14 PM 8/27/99 -0500, Tom-PT Taylor wrote:
>Anyone else in favour of making context a command parameter?

The real question is, shall we get rid of the "transaction" construct and
place everything at the command level, where a command applies to a
termination+context pair.

Having atomic commands would definitely be simpler to implement than atomic
transactions. However, there is the little problem of adding two
transactions to the same unspecified context without incurring a
round-trip-time delay. You will need to define a special construct for
that, something like "use the same context as the one created in the ADD
command number XXX."

If you do that, then you can indeed remove the transaction layer without
much consequence. The move command becomes simpler, with symmetric
move-from and move-to parameters.
Christian Huitema

---

From: Nancy-M Greene <[email-masked]>
Date: Fri, 27 Aug 1999 21:38:48 -0400

> I do not agree that we should be throwing transactions out the window.
>
> Tom gave an example of when having a transaction is useful: you only want
> to apply a call-waiting signal to a line if there is a call waiting - thus
> it is logical to put the creation of the context for the waiting call in
> the same transaction as the one that applies the call waiting signal.
>
        Christian Huitema writes:

> transactions
you mean "commands" instead of "transactions", don't you?
> to the same unspecified context without incurring a
> round-trip-time delay.
> You will need to define a special construct for
Let's not fiddle with it! We can all sit down and re-invent the whole
protocol again, and we would be no further ahead. Let's stick with the
transaction concept. It is useful when you have certain commands that MUST
be executed together. If you don't need this you are left with a few extra
brackets, but that's it. You still need a transactionId, even if you only
put one command in a transaction.

> move-from and move-to parameters.
No need to fiddle with move. It moves a termination from the context it is
in, to the named context.

> Christian Huitema
Nancy
--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:[email-masked]