Subject: Provisional Response Timer Value

From: J Ramachandra <[email-masked]>
Date: Mon, 4 Dec 2000 07:05:46 -0600

Hi list,

I was trying to understand the usage of 'Provisional Response Timer'.
After reading through the sections D.1.4 and E.2.1, I have the following
doubts. Could some one clarify?

1. The section D.1.4 specifies "The root termination has a property
(ProvisionalResponseTimerValue), which can be set to the requested
maximum number of milliseconds between receipt of a command and
transmission of the TransactionPending response". Does it mean this
timer value is used for sending the TransactionPending by the entity
RECEIVING the TransactionRequest? If so, it is only the worst case or
maximum self (MGC/MG)execution time and no network delay factor coming
into picture.

2. The section E.2.1 for 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, plus network delay, but may be
lowered". Does it mean it is a timer started at the entity SENDING the
TransactionRequest and is based on the remote (MG/MGC) Execution time
plus network delay?

3. Which one of the above is correct; (1) or (2)? It can not be both, as
both are not same and base root package can only hold one value.

4. The wordings from (2) indicates one has to start two timers while
sending TransactionRequest. One for expecting transactionPending and
another for normal repetition timer. Is it correct? If not what is the
timer started while sending a transactionRequest?

5. Why do we need this property in Base root Package separately? Is it
not derivable from normalMGExecutionTime/normalMGCExecutionTime and the
network delay?

6. The secion D.1.4 also specifies "Entities that receive a Transaction
Pending shall switch to a different repetition timer for repeating
requests". What is different repetition timer? Is it ProvisionalResponse
TimerValue? Is the same timer value used for subsequent
transactionPending received till you receive TransactionReply - i.e. no
exponetially increasing timer as done with normal repetiton timer?

7. Finally, what is the criteria for sending TransactionPending? The
same section D.1.4 specifies "They SHOULD send this response if they
receive a repetition of a transaction that is still being executed". Is
this the criteria or after timeout as in (1) above. Do one necessarily
has to wait till a  transactionRequest is repeated from the remote end?

Sorry, if the mail is bit long. My intention is to make my doubt clear
and expecting the answers to specific items listed.

Thanks for your patience,

- J.K. Ramachandra,
  ipGen inc.

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 4 Dec 2000 09:35:25 -0500

I vaguely recall a discussion of whether the parameters include network
delay,
and I recall that they do.

> maximum self (MGC/MG)execution time and no network delay factor coming
It is the internal processing time, plus an estimate of network time.
It is NOT the worst case time to execute a command, it is the maximum time
the entity will wait for a command to complete before sending a
Pending response (plus the estimated network delay).

> TransactionRequest and is based on the remote (MG/MGC) Execution time
No the timer is started by the entity RECIEVING the Request.  Of course,
the timer is actually set to the max time before sending a pend WITHOUT the
estimated network delay.

> both are not same and base root package can only hold one value.
Covered above.  It's the receiver, and the value includes network delay

> timer started while sending a transactionRequest?
The SENDER runs a timer which is used to trigger request repetitions.
The RECIEVER runs a timer which is used to trigger Pending responses.
> not derivable from
> normalMGExecutionTime/normalMGCExecutionTime and the
> network delay?
See above - one is a timer for the sender, the other if for the receiver.

> exponetially increasing timer as done with normal repetition timer?
This means that when you get a pending response, you should know that
the next response should be determined by the ProvisionalResponseTimerValue
and not the normalMGExecutionTime.  So the timer for the SENDER should
be reset to ProvisionalResponseTimerValue.

> has to wait till a  transactionRequest is repeated from the
Pending is sent when you aren't finished executing, but your pending timer
expires.  The SENDER sends a Pend to the Receiver, which resets it's
repetition
timer.

In the normal case, you will receive the Pend before your repetition timer
times out, but what if it doesn't.  You send a repeat of the request.  When
you do get the Pend, you reset your repetition timer (holding off sending
of yet another repetition until at least ProvisionalResponseTimerValue from
the receipt of the pend.  The RECIEVER of the request sees the duplicate
request
after he sends a Pend.  We recommend that it send another Pend at that time.
The RECIEVER then sees two pends, the (delayed) original pend, plus the one
that is sent in response to the duplicate request.  It resets it's timer
again,
and continues waiting for (a) another pend or (b) a Response.

Brian