Subject: RE: Transaction Pending

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 28 Mar 2001 08:36:39 -0500

The short-term workaround is the Subtract -- won't work too well on a
wild-carded audit that's taking too long to assemble.  The permanent fix is
probably a transaction cancel, but we'd better be sure of our requirements
before we go there.

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Tuesday, March 27, 2001 11:24 PM
> To: Boyle, Kevin [NCRTP:3Z70:EXCH]
> Cc: [email-masked]; Taylor, Tom-PT [NORSE:B881:EXCH]; Jos Marcelis
> Subject: Re: Transaction Pending
> 
> 
> 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
> 
> 
> Kevin Boyle wrote:
> > 
> > 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
> > 
> > Christian Groves wrote:
> > 
> > > 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
> > >
> > > Kevin Boyle wrote:
> > > >
> > > > 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: "Marcello Pantaleo (EED)" <[email-masked]>
Date: Thu, 29 Mar 2001 16:53:45 +0200

Hi Christian,
unfortunately I missed the quick chat to Tom and Michael
during the last SG16 meeting so probably I'm not taking 
into account some important considerations. 
I was just wondering if we could avoid the use of SUB 
command or TransactionCancel...simply using the counter 
MGOriginatedPendingLimit and the new error code as in 
your proposal.

Suppose the TransactionRequest (from MGC to MG) is:

TransactionRequest(TransactionID {
...,
Contexti{Command1,Command2,Command3},
...})

then the MG sends n PendingTransaction. When n equals 
MGOriginatedPendingLimit (and suppose it was processing
Command2 in Contexti), it will send a TransactionReplay:

TransactionReplay(TransactionID {
...,
Contexti{Response1,Response2},
...})

Where Response2 is an ErrorDescriptor containing the 
new error code. The MGC would know where the problem was 
and assume that everything before Response2 was processed 
correctly by the MG.  
In the opposite direction I'd use a MGC internal counter
(MGOriginatedPendingLimit) but i don't see why it should be
a Property on Root.

Cheers,
Marcello  

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, March 29, 2001 4:11 AM
To: Jos Marcelis (EED)
Cc: 'Tom-PT Taylor'; Kevin Boyle; [email-masked]
Subject: Re: Transaction Pending

G'Day all,

Well I think there's a bit to think about on this one so i'll wait to
get a properly documented contribution out.

Regards, Christian

"Jos Marcelis (EED)" wrote:
> 
> Hi,
> 
> I was thinking along the same lines as Tom.
> 
> Basically I see two main show stoppers with Christian's quick
> proposal:
>    1. MGC cannot always send Subtract, namely in the (quite common)
> case where and Add Command was sent with both CHOOSE wildcarded
> ContextID and CHOOSE wildcarded TerminationID.  Even if the MGC
> received the newly proposed error code, it wouldn't know what
> TerminationID to subtract.
>    2. I think the proposal is breaking the "rule" that an Error
> response to a TransactionRequest implies that the MG has not executed
> anything at all.  In other words, the state of the MG is exactly the
> same as before reception of the TransactionRequest.  Maybe this rule
> is not cast in stone in H.248, but it is the way I have always
> interpreted an error response to a Command.
> 
> These two points indicate that MG cannot simply return the new error
> code and then wait to receive a Subtract.  It will have to roll back
> on its own account.
> 
> Best regards, Jos
> 
> 
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Wednesday, March 28, 2001 3:37 PM
> To: 'Christian Groves'; Kevin Boyle
> Cc: [email-masked]; Jos Marcelis
> Subject: RE: Transaction Pending
> 
> wild-carded audit that's taking too long to assemble.  The permanent
> fix is probably a transaction cancel, but we'd better be sure of our
> requirements before we go there.
>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 29 Mar 2001 23:00:06 -0500

I like the principle that the executing party should keep track of the
elapsed time since a transaction request has been received and return an
error (500? 510?) if it hasn't been completed after a reasonable period.
I'm not sure if that period has to be represented by a property, though
otherwise I suppose the peer has to place a lot of trust in the
implementation.

> From: Marcello Pantaleo (EED) 
> [mailto:[email-masked]]
> Sent: Thursday, March 29, 2001 9:54 AM
> To: 'Christian Groves'
> Cc: Taylor, Tom-PT [NORSE:B881:EXCH]; Boyle, Kevin [NCRTP:3Z70:EXCH];
> Jos Marcelis (EED); [email-masked]
> > > 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