Subject: Re: Washington Issue 22 - Root Package

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 23 Nov 1999 14:52:05 -0500

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
>

---

From: Paul Hollis <[email-masked]>
Date: Wed, 24 Nov 1999 08:32:10 +0100

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.

--

oooooooooooooooooooooooooooooooooooooooooooooo
  Paul Hollis
  Ericsson Eurolab Deutschland GmbH
  Ericsson Allee 1
  D-52134 Herzogenrath
  Germany
  Phone: +49 2407 575 8092
  email: [email-masked]
oooooooooooooooooooooooooooooooooooooooooooooo