Subject: Re: Washington Issue 22 - Root Package

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 2 Dec 1999 08:55:18 -0500

Paul

I think that it is the responsibility of the initiator to use
transactionIDs so that the situation does not occur.  An
incrementing transactionID is one way, there are others.

I do not believe that it is necessary to specify use of timers
at the responder to avoid the problem, and I would not wish
to specify any behavior other than the initiator must not
cause the situation to occur.  We do need to have some words
to this effect in the document.

Brian

> -----Original Message-----
> From: Paul Hollis [mailto:[email-masked]]
> Sent: Thursday, December 02, 1999 3:08 AM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: Re: Washington Issue 22 - Root Package
>
>
> Hi Brian,
>
> Firstly, I dont think that the protocol states that the
> Transaction ID needs
> to be
> sequential. (ie. I thought it just said something like it was
> to be unique
> within
> the sender).
>
> Secondly, this doesn't solve the cross over problem! As the
> protocol is
> transport independent then I think we need to handle it in
> the protocol,
> either with a timer based solution or using Tom's solution of keeping
> the last X transaction replies stored somewhere. I think Toms solution
> would be a bit hard to figure out for a large, busy MG. So I
> still think
> the use of a timer is needed.
>
> Regards Paul.
>
> "Rosen, Brian" wrote:
>
> > Roll over on a 32 bit transactionID is hours on a very high volume
> > MG.  I do not believe a timer is required.  If you want to keep all
> > transaction replies for a time greater than worst case
> timeout of your
> > transport, which could be tens of seconds, go ahead.  I
> don't think we
> > need to require such behavior.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Paul Hollis [mailto:[email-masked]]
> > > Sent: Thursday, November 25, 1999 9:32 AM
> > > To: Rosen, Brian; MEGACO Mailing list
> > > Subject: Re: Washington Issue 22 - Root Package
> > >
> > >
> > > Hi Brian,
> > >
> > > I'm not sure what the suggested timer is that you are talking
> > > about below,
> > > but I think we still need a timer similar to the one that
> > > Christian has
> > > suggested below. I.e A timer in the MG, started at the
> sending of the
> > > reply, and during whichtime the transaction ID is treated as
> > > a duplicate
> > > and discarded. Upon timeout, the transaction ID can be treated as
> > > a new transaction and executed. Sure it is only going to
> handle the
> > > exceptional cases of when the could be a cross over, but then most
> > > timers are for the exceptional cases.
> > >
> > > As the protocol is meant to be transport independent I dont think
> > > using ALF has got anything to do with it.
> > >
> > > Regards Paul.
> > >
> > >
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > > If you are using ALF techniques, you hold the request until
> > > > you get the ack on the reply.  Repeated requests in the face
> > > > of lost replies are then easily detected and extra replies
> > > > generated.  If the request comes after the ack, it is ignored.
> > > >
> > > > In the case of reliable transport, you may wish to retain
> > > > requests for a while after reply to assure that there has not
> > > > been a failure not directly due to transport.  There is, for
> > > > example, a suggestion for a timer already in the text.  Perhaps
> > > > we need some more text suggesting the same for the responder,
> > > > keeping replies for a while.  I don't think we need more than
> > > > that, but I'm open to suggestions.
> > > >
> > > > Brian
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Paul Hollis [mailto:[email-masked]]
> > > > > Sent: Wednesday, November 24, 1999 2:32 AM
> > > > > To: Rosen, Brian
> > > > > Cc: [email-masked]
> > > > > Subject: Re: Washington Issue 22 - Root Package
> > > > >
> > > > >
> > > > > Hi Brian,
> > > > >
> > > > > this may be the case, but this does not solve the problem that
> > > > > Christian has raised here.
> > > > >
> > > > > If there is a crossover of a repeated Transaction
> request and a
> > > > > Transaction Reply, then the MG will repeat execution of the
> > > > > Transaction, which is not desirable. This is why Christian has
> > > > > suggested the use of a timer in the MG to allow it to
> think that
> > > > > it is in fact still executing the Transaction that it has
> > > > > just replied to
> > > > > for a certain extra period of time. This then allows for the
> > > > > possibility
> > > > > of the repeated transaction request to be treated as
> such by the
> > > > > MG and be discarded, rather than re-executed. Once
> this certain
> > > > > period of time expires then a Transaction Request coming in
> > > > > can be treated as a new transaction and executed.
> > > > >
> > > > > Regards Paul.
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > >
> > > > > > I think this is clear now based on the last design
> team meeting,
> > > > > > but just in case:
> > > > > >
> > > > > > TransactionIds are expected to be unique over a
> "long" period
> > > > > > of time.  Long is "no possibility of being confused with
> > > > > > another transaction".  One way to achieve this is to
> > > use a 32 bit
> > > > > > transactionID that increments with every transaction.  Even
> > > > > > if transactions were issued at an average rate of
> one every 100
> > > > > > microseconds, there is still several hours of time between
> > > > > roll-over.
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Christian Groves
> [mailto:[email-masked]]
> > > > > > > Sent: Tuesday, November 23, 1999 8:58 AM
> > > > > > > To: Brian Rosen
> > > > > > > Cc: [email-masked]
> > > > > > > Subject: Re: Washington Issue 22 - Root Package
> > > > > > >
> > > > > > >
> > > > > > > G'Day Brian,
> > > > > > >
> > > > > > > Isn't there a situation where?
> > > > > > >
> > > > > > > The MGC sends a transaction (transID 123)[time 0ms]
> > > > > > > The MG sends transaction reply (transID 123)[time 990]
> > > > > > > The MGC repeats transaction (transID 123)[time
> 1000] because
> > > > > > > normalexecution [1000] timer in MGC expires.
> > > > > > > The MGC receives (transID 123) at time 1005ms.
> > > > > > > The MG receives (transID 123) at time 1015ms.
> > > > > > >
> > > > > > > We've just had signalling cross over.
> > > > > > >
> > > > > > > Should the MG treat transID123 as a new transaction
> > > or should it
> > > > > > > consider that the transaction has been repeated?
> > > > > > >
> > > > > > > I'd say for the that for a certain X period of time
> > > then it should
> > > > > > > consider it to be the same and discard the 2nd
> > > > > Transaction request.
> > > > > > > After this time then it should be a new transaction ID.
> > > > > > >
> > > > > > > Should there be a timer between the sending of a
> reply and the
> > > > > > > determination that a transaction containing the same
> > > > > transID is a new
> > > > > > > transaction not a repeated one?
> > > > > > >
> > > > > > > This won't occur often, probably only when timers
> are stuffed
> > > > > > > up but no
> > > > > > > the less it can occur and may cause some pretty
> "interesting"
> > > > > > > behaviour
> > > > > > > in the MG and MGC. But being 'good' protocol
> > > designers we should
> > > > > > > probably fix this.
> > > > > > >
> > > > > > > Therefore I propose:
> > > > > > > > TransactionExpiryTimerValue
> > > > > > > >                 PropertyId: TransactionExpiryTimerValue
> > > > > > > >                 When an duplicate transactionID is
> > > received it
> > > > > > > >                 indicates the period of time that the
> > > > > transaction
> > > > > > > >                 shall be discarded. After this time the
> > > > > transaction
> > > > > > > >                 is treated as a new transaction.
> > > > > > >
> > > > > > > Cheers, Christian
> > > > > > >
> > > > > > >
> > > > > > > Brian Rosen wrote:
> > > > > > > >
> > > > > > > > A number of issues were raised in the Washington
> > > meeting that
> > > > > > > > were "send to the list".  This is one of these
> > > issues, with the
> > > > > > > > problem and my suggested fix.
> > > > > > > >
> > > > > > > > Problem
> > > > > > > >
> > > > > > > > Base package annex does not specify the base
> Root package
> > > > > > > > Need a definition of this package
> > > > > > > >
> > > > > > > > Proposed Solution:
> > > > > > > > Base Root Package
> > > > > > > > PackageID: root (0x00??)
> > > > > > > > Version: 1
> > > > > > > > Extends: None
> > > > > > > > Description:
> > > > > > > > This package defines Gateway wide properties.
> > > > > > > >
> > > > > > > > Properties
> > > > > > > >         MaxTerminationsPerContext
> > > > > > > >                 PropertyID:
> > > maxTerminationsPerContext (0x0001)
> > > > > > > >                 The maximum number of allowed
> terminations
> > > > > > > in a context
> > > > > > > >                 See section 6.1
> > > > > > > >                 Type: Integer
> > > > > > > >                 Possible Values: any integer
> > > > > > > >                 Defined In: TerminationState
> > > > > > > >
> > > > > > > >         normalMGExecutionTime
> > > > > > > >                 PropertyId: normalMGExecutionTime
> > > > > > > >                 Settable by the MGC to indicate the
> > > > > interval within
> > > > > > > >                         which the MGC expects a
> > > response to any
> > > > > > > >                         transaction from the MG
> > > > > > > >                 Type: Integer
> > > > > > > >                 Possible Values: any integer, represents
> > > > > > > milliseconds
> > > > > > > > normalMGCExecutionTime
> > > > > > > >                 PropertyId: normalMGCExecutionTime
> > > > > > > >                 Settable by the MGC to indicate the
> > > > > interval within
> > > > > > > >                         which the MG should expects a
> > > > > > > response to any
> > > > > > > >                         transaction from the MGC
> > > > > > > >                 Type: Integer
> > > > > > > >                 Possible Values: any integer, represents
> > > > > > > milliseconds
> > > > > > > > ProvisionalResponseTimerValue
> > > > > > > >                 PropertyId:
> ProvisionalResponseTimerValue
> > > > > > > >                 Indicates the time within which to
> > > > > expect a Pending
> > > > > > > >                         Response if a
> Transaction cannot be
> > > > > > > completed.
> > > > > > > >                         Initially set to
> > > > > normalMGExecutionTime or
> > > > > > > >                         normalMGCExecutionTime as
> > > > > appropriate, but
> > > > > > > >                         may be lowered.
> > > > > > > > Events
> > > > > > > >         None
> > > > > > > > Signals
> > > > > > > >         None
> > > > > > > > Statistics
> > > > > > > >         None
> > > > > > > > Procedures
> > > > > > > >         None
> > > > > > > >
> > > > > > > > Brian
> > > > > > >
> > > > >
> > > > > --
> > > > >
> > > > > oooooooooooooooooooooooooooooooooooooooooooooo
> > > > >   Paul Hollis
> > > > >   Ericsson Eurolab Deutschland GmbH
> > > > >   Ericsson Allee 1
> > > > >   D-52134 Herzogenrath
> > > > >   Germany
> > > > >   Phone: +49 2407 575 8092
> > > > >   email: [email-masked]
> > > > > oooooooooooooooooooooooooooooooooooooooooooooo
> > > > >
> > > > >
> > >
> > > --
> > >
> > > oooooooooooooooooooooooooooooooooooooooooooooo
> > >   Paul Hollis
> > >   Ericsson Eurolab Deutschland GmbH
> > >   Ericsson Allee 1
> > >   D-52134 Herzogenrath
> > >   Germany
> > >   Phone: +49 2407 575 8092
> > >   email: [email-masked]
> > > oooooooooooooooooooooooooooooooooooooooooooooo
> > >
> > >
>
> --
>
> oooooooooooooooooooooooooooooooooooooooooooooo
>   Paul Hollis
>   Ericsson Eurolab Deutschland GmbH
>   Ericsson Allee 1
>   D-52134 Herzogenrath
>   Germany
>   Phone: +49 2407 575 8092
>   email: [email-masked]
> oooooooooooooooooooooooooooooooooooooooooooooo
>
>

---

From: Paul Hollis <[email-masked]>
Date: Fri, 3 Dec 1999 09:34:36 +0100

Hi Brian,

yes, I agree, the document probably does need to be tightened up
in the transaction ID area.

The problem of crossover is still an issue though!

Regards Paul.

--