Subject: Transaction Pending

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 26 Mar 2001 13:27:30 -0500

Through some work that we are doing with regards to Transaction Pending,
it has come to light that there is potential for a stalemate, and
resultant hung resources.  The spec says the following:

Section 8, Transactions:

"Transactions are presented as TransactionRequests.  Corresponding
responses to a TransactionRequest are received in a single reply,
possibly preceded by a number of TransactionPending messages."

"TransactionPending is used to periodically notify the receiver that a
Transaction has not completed yet, but is actively being processed."

"Applications SHOULD implement an application level timer per
transaction.  Expiration of the timer should cause a retransmission of
the request.  Receipt of a Reply should cancel the timer.  Receipt of
Pending should restart the timer."

Section 8.2.3 TransactionPending:

"The receiver invokes the TransactionPending.  A TransactionPending
indicates that the Transaction is actively being processed, but has not
been completed.  It is used to prevent the sender from assuming the
TransactionRequest was lost where the Transaction will take some time to
complete."

"Senders may receive more than one TransactionPending for a command."

Given all of the above, it is conceivable that the MG could send an
infinite number of TransactionPendings to a given transaction, thereby
locking up resources associated with the transaction.  To avoid these
situations, the MGC should be able to escape from this "loop".  How many
TransactionPendings should be seen before we consider the possibility of
MG failure?  And once the MGC has detected this error case, what can the
MGC do to attempt to recover the terminations/resources that are
affected by the problem?

Kevin

---

From: Christian Groves <[email-masked]>
Date: Tue, 27 Mar 2001 15:37:59 +1000

G'Day Kevin,

We identified this problem also awhile ago. In a similar situation you
may want the MGC to be able to "cancel" a pending transaction in the
case some application level timers expire and you want to free up
resources. I had a quick chat to Tom and Mike B at the SG16 meeting on
this.

One way we thought to handle this would be in v2 to update the text to
say that if you sent a subtract from the MGC to MG on a pending
transaction that it would have the effect of subtracting the termination
and any pending transaction will be cancelled. 

Another way we thought would be to issue a new transaction with some
sort of "cancel" symantic. We discounted this as you may need to partly
"roll back" the command. This may leave the MG in an unknown state.

I hope to have a contribution on this to the next SG16 meeting.

Cheers, Christian

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 27 Mar 2001 10:24:39 -0500

Excellent.  I look forward to seeing your contribution.

In the short term, however, (i.e. v1) would it be possible/feasible to place a
limit on the number of TransactionPendings that can be sent?  The cap would be
completely arbitrary, but at least it would protect against the possibility of
this kind of problem.  For instance, the receiver can send up to 5
TransactionPendings, and then the 6th message must be a response (indicating
success), or an error (indicating failure... lack of resources, perhaps?).

What are your thoughts on this for an interim solution while v2 is under
development?

Kevin

---

From: Chuong Nguyen <[email-masked]>
Date: Tue, 27 Mar 2001 11:22:28 -0600

I have another question.

Said MG sends a transaction to MGC and MG Long Timer is 10 sec.
MGC takes longer than 10 sec to finish the execution.
So MGC sends out TransactionPending to MG periodically until the execution is
completed.
Does MG restart its Long Timer after every Transaction Pending?
Or after Long Timer has expired, MG treats this pending transaction as failed?

If Long Timer is not reset for each Transaction Pending,
when MGC finishes execution of this transaction and sends the Reply to MG.
What should MG do w/this Reply - ignores the Reply from MGC?

Thanks
Chuong

--
  Alcatel USA, Inc             Internet: [email-masked]
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

---

From: Christian Groves <[email-masked]>
Date: Wed, 28 Mar 2001 14:24:05 +1000

G'Day Kevin,

On further thinking to me is seems all or nothing. I can see the benefit
of adding a counter for transaction pendings but it raises the question
of "what do you do???" when its exceeded. You know something is wrong
but you can't do anything about it. The 6th message with an error may
help in some situations but you can't be sure what's been executed. So
you'd have to do a subtract straight away. Also what does the MG do if
the MGC sends pending responses, should it have a different counters?

I can see perhaps one way around this problem that would involve an
update to the Implementors' Guide and a new package possibly extended
root (ideally this should be part of route). I've quickly put down some
ideas as a start of a proposal, I've probably missed a couple of things
so please point it out but I think it meets the requirements what people
want to do.

I see the following impacts:
H.248v1 implementors' guide or v2
=============
8.2.3 TransactionPending
...
A pending transaction may be cancelled by the MGC issueing a subtract
command on the contexts and termination/s in the original transaction
request.

H.248 E.2 or a new package extending root
=========================================
Two properties could be introduced:
MGCOriginatedPendingLimit
PropertyId: tbd (0xtbd)
Indicates the number of transaction pendings that can be received from
the MGC before the MG can consider that a transaction is in error. Once
this limit is exceeded the MGC should issue a transaction reply with
error code "
Type: Integer
Possible Values: any integer
Defined in: TerminationState
Characteristics:

MGOringatedPendingLimit
PropertyId: tbd (0xtbd)
Indicates the number of transaction pendings that can be received from
the MG before the MGC can consider that a transaction is in error. Once
this limit is exceeded the MG should issue a transaction reply with
error code "
Type: Integer
Possible Values: any integer
Defined in: TerminationState
Characteristics: 

One Event:
Pendings Exceeded Useful Processing Time
EventID: tbd, 0xtbd
This event indicates to the MGC that the MG has received a number of
pending transactions however this time taken for these pendings has
exceeded the time necessary to complete an operation associated with the
original transaction request.
EventDescriptor parameters: NA
ObservedEventsDescriptor parameters: NA

Procedure: 
The MGC may cancel a pending transaction at any time by issueing a
subtract on the relevant termination from the relevant context contained
in the initial request.

H.248 Annex L
=============
New error code:
x.xx Error Code # : 5xx Name: Number of transaction pending exceeded
Definition: The MGC or MG has determined that the number of transactions
it has sent exceeds MGCOriginatedPendingLimit or
MGOriginatedPendingLimit. The transaction should be considered in error
and termination/s referenced in the transaction request should be
subtracted from the relevant contexts.
Package: -
Error Text in the error Descriptor: -
Comment: -

Cheers, Christian