Subject: Re: Washington Issue 22 - Root Package

From: Prashant Jain <[email-masked]>
Date: Thu, 25 Nov 1999 01:37:37 +0530

hi brian,
In the following, it is written that ProvisionlaResponseTimerValue is initially
set to normalExecutionTime, but later on it may be lowered. The Qs. how can we
lower the value of  ProvisionlaResponseTimerValue as the time progresses and on
what basis. Please clarify.

Also, related to these parameters, we have some more queries:

1. Does the normalExecutionTime for MG or MGC includes only the time required
for execution of transactions in MG or MGC or does it also include the network
delay. We think it is only the execution time. Are we correct?

2. If it is only the execution time, then will the normalExecutionTime be used
only to generate the Transaction Pending Response,  as indicated from the
ProvisionlaResponseTimerValue being set to the normalExecutionTime  initially.

3. It is mentioned in the version 12 that when a requesting entity receives a
Transaction Pending Response, it increases its RETRANSMIT TIMER   to long timer
values. The Qs. is does the normalExecutionTime can play some role in
determining the increase in the Timer values on the receipt of Pending Response
or it is just that the timer is increased by a random amount.

We would appreciate if you reply.

Regards,

Prashant Jain

Brian Rosen <[email-masked]> on 11/16/99 04:07:44 AM

Please respond to Brian Rosen <[email-masked]>

To:   [email-masked]
cc:    (bcc: Prashant Jain/HSS)

Subject:  Washington Issue 22 - Root Package

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: "Rosen, Brian" <[email-masked]>
Date: Wed, 24 Nov 1999 16:33:39 -0500

> hi brian,
> In the following, it is written that
> ProvisionlaResponseTimerValue is initially
If the MGC wants more frequent Pending messages, it lowers the value.

You lower it by Modify of Root.

> delay. We think it is only the execution time. Are we correct?
Hmmm, I think you are correct, but then we need to change the
definition of the initial value of ProvisionalResponseTimerValue
because it has to include network delay.

> normalExecutionTime  initially.
Right.

Your next question should be - how do you estimate network
delay.  I think that, at least for now, that should be
provisioned (although I don't like that answer).

> or it is just that the timer is increased by a random amount.
It is just increased by a random amount

Brian

---

From: Hollis Family <[email-masked]>
Date: Thu, 25 Nov 1999 20:31:44 +0100

Hi Tom,

so you would have a buffer of last N transaction numbers used. If we
receive a transaction with one of these numbers then we discard it.
Otherwise it is treated as a new transaction. ie. it keeps
a history of the last few numbers that we have replied to.
Is that the idea?

Regards Paul.

Tom-PT Taylor wrote:

>
>
> I'm not sure you need this timer.  What you need instead is a record
> of transactionIDs received, similar to that maintained in SCTP (i.e.
> last consecutive number received, then the individual ranges received
> after that).  With a sufficiently large transaction number range you
> don't get transaction number overlap, so you have an exact idea of
> whether a given transaction is new or a duplicate.
>
> Of course, this assumes that transactionIDs are consecutive between a
> given MGC and given MG.  If that is too restrictive a model we may
> have to rethink it, but I think it fits with the association models we
> currently support.
>
>      -----Original Message-----
>      From:   Paul Hollis [SMTP:[email-masked]]
>      Sent:   Thursday, November 25, 1999 9:32 AM
>      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 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.
>
>
>      "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:
>      > > > > >
>      > > > > >                 The maximum number of allowed
>      terminations
>      > > > > in a context
>      > > > > >                 See section 6.1
>      > > > > >                 Type: Integer
>      > > > > >                 Possible Values: any integer,
>      represents
>      > > > > milliseconds
>      > > > > > normalMGCExecutionTime
>      > > > > >                 Possible Values: any integer,
>      represents
>      > > > > milliseconds
>      > > > > >                         Response if a Transaction
>      cannot be
>      > > > > completed.
>      > > > > >                         Initially set to
>      > > normalMGExecutionTime or
>      > > --
>      > > 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: Harpreet Singh Anand <[email-masked]>
Date: Fri, 26 Nov 1999 14:24:38 +0530

Hello Nancy,

> Harpreet, The Notify command goes from the MG to the MGC, and the MGC is
> supposed to send a Notify Reply within a certain amount of time. The MG uses
> ProvisionalResponseTimerValue set to normalMGCExecutionTime to figure out how
> long to wait for the reply.

I am not sure if that is the meaning of ProvisonalResponseTimerValue. The text
is ambiguous and does not say who (MG / MGC) is expecting PendingResponse.

I am rephrasing my query as below:

At any instant of time, MG will need two type of timers:

1. Provisional Response timer: This timer is used by the MG to send provisional
responses to the MGC. This timer would be based on the value
normalMGExecutionTime.

2. Retry timer: This timer is used by MG to wait for a reply for commands send
by MG to MGC (example, Notify, ServiceChange etc). This timer would be based on
the value of  normalMGCExecutionTime.

Given the above understanding, my questions are:

1. What is the need of ProvisonalResponseTimer ?  normalMGExecutionTime &
normalMGCExecutionTime are sufficient for the MG to derive  values for the two
timers that are kept by MG.

2. Assuming that there is a need for ProvsionalResponseTimer, it can be used for
only one purpose, that is either to derive value for Provisional Response Timer
or the value for Retry Timer and NOT both. The text seems to suggest that the
variable gets initialised to "normalMGExecutionTime or normalMGCExecutionTime as
appropriate". My point is that it can be initialised to just one of them.

>
>
> Nancy
> --------------------------------------------------------------------------
> Nancy M. Greene
> Internet & Service Provider Networks, Nortel Networks
> T:514-271-7221 (internal:ESN853-1077) E:[email-masked]
>
>      ----------
>      From:   Harpreet Singh Anand[SMTP:[email-masked]]
>      Sent:   Thursday, November 25, 1999 6:48 AM
>      Hello Brian,
>      A few questions on normalExecutionTime and ProvisionalResponseTimerValue:
>
>      1. The purpose of having normalMgExecutionTime is to tell MG, how much
>      time MGC
>      expects MG to take for executing a transaction. Therefore, if MG would
>      take more
>      time then, the MG should send a TransPending.
>
>      The same purpose is being served by ProvisionalResponseTimerValue,
>      whereby, MGC
>      tells MG to send a provisional response every
>      millisecs.
>      MG would *always* be using ProvisionalResponseTimerValue to start a
>      provisional
>      timer.
>
>      When would MG use normalMgExecutionTime ? I believe only
>      ProvisionalResponseTimerValue is sufficient.
>
>      How can ProvisionalResponseTimerValue be initialised to either
>      normalMGExecutionTime  or normalMGCExecutionTime  ?
>
>      It has only one meaning and should be initialised to
>      normalMGExecutionTime.
>
>      Regards,
>      Harpreet
>
>      _________________________________
>      Harpreet Singh Anand
>      Ficon Technology
>      E-mail :  mailto:[email-masked]
>      Web    :  http://www.ficon-tech.com
>
--

Regards,
Harpreet

_________________________________
Harpreet Singh Anand
Ficon Technology
E-mail :  mailto:[email-masked]
Web    :  http://www.ficon-tech.com

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 29 Nov 1999 13:59:28 -0500

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

> To: Rosen, Brian; MEGACO Mailing list
> 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
> 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
> > > this may be the case, but this does not solve the problem that
> > > If there is a crossover of a repeated Transaction request and a
> > > 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
> > > of the repeated transaction request to be treated as such by the
> > > MG and be discarded, rather than re-executed. Once this certain
> > > > 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
> > > > another transaction".  One way to achieve this is to
> use a 32 bit
> > > > if transactions were issued at an average rate of one every 100
> > > > > From: Christian Groves [mailto:[email-masked]]
> > > > > The MGC repeats transaction (transID 123)[time 1000] because
> > > > > Should the MG treat transID123 as a new transaction
> or should it
> > > > > I'd say for the that for a certain X period of time
> then it should
> > > > > Should there be a timer between the sending of a reply and the
> > > > > 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:

---

From: Harpreet Singh Anand <[email-masked]>
Date: Tue, 30 Nov 1999 13:37:19 +0530

Hello Nancy

> I see your point now, Harpreet. ROOT identifies properties on an MG that an
> MGC might want to know or set. However, an MGC would have some of the same
> properties, it would just not have them in a ROOT termination. The MG does not
> need to know these values, nor need to set them, so they do not need to be
> part of the protocol, i.e. the MG does not need to be able to get at them
> through the protocol.
>
> There are timers that an MGC needs as you point out, and the protocol
> procedures could define default values for them or give guidelines for setting
> them, but they would not be in an MGC's ROOT termination, since it does not
> have a ROOT termination.
>
> So, the text suggesting that the ProvisionalResponseTimer gets initialized to
> "normalMGExecutionTime or normalMGCExecutionTime as appropriate" means this:
> On the MGC, ProvisionalResponseTimer is set to the normal MG execution time
> (the MGC can get the value normalMGExecutionTime from Auditing the MG's ROOT
> termination), plus the current value for network delay. On the MG,
> ProvisionalResponseTimer is set to the normalMGCExecutionTime from the MG's
> ROOT termination, plus the current value for network delay.

Since ProvisionalResponseTimer is only a property on MG side, in the description
of this property there should not be any mention of setting this property on
MGC. It can be misleading.

One of my query is still unanswered - why do we need a separate property as
ProvisionalResponseTimer ? Isn't normalMGExecutionTime and
normalMGCExecutionTime sufficient ?

Regards,
Harpreet

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 30 Nov 1999 10:05:32 -0500

We can argue whether this is reasonable, but normalMGExecution time
is inalterable and represents the expected execution time independent of
transport.  ProvisionalResponseTime includes transport delay and can be
altered if the MGC wants more frequent updates.

Brian

> From: Harpreet Singh Anand [mailto:[email-masked]]
> 1. The purpose of having normalMgExecutionTime is to tell MG,
> how much time MGC
> expects MG to take for executing a transaction. Therefore, if
> MG would take more
> The same purpose is being served by
> ProvisionalResponseTimerValue, whereby, MGC
> MG would *always* be using ProvisionalResponseTimerValue to
> start a provisional
> timer.
>