Subject: Re: Washington Issue 22 - Root Package

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 24 Nov 1999 07:46:44 -0500

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
>
>

---

From: Paul Hollis <[email-masked]>
Date: Thu, 25 Nov 1999 15:31:47 +0100

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 which time 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.

--