Subject: Re: Washington Issue 22 - Root Package

From: Paul Hollis <[email-masked]>
Date: Thu, 2 Dec 1999 09:07:56 +0100

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