Subject: RE: [Megaco] Provisional Response Timer Clarification

From: "Jerker Zetterlund \(AL/EAB\)" <[email-masked]>
Date: Wed, 18 Jan 2006 16:48:17 +0100

Hello again,
 
Please find comments inline.
 
BR
 
Jerker

________________________________

From: Kevin Boyle [mailto:[email-masked]] 
Sent: den 17 januari 2006 17:31
To: Jerker Zetterlund (AL/EAB); [email-masked]
Subject: RE: [Megaco] Provisional Response Timer Clarification

Comments inline. [KJBII]
 
Kevin

________________________________

	From: Jerker Zetterlund (AL/EAB)
[mailto:[email-masked]] 
	Sent: Tuesday, January 17, 2006 10:48 AM
	To: Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked]
	Subject: RE: [Megaco] Provisional Response Timer Clarification

	Hello Kevin,
	 
	I have a couple of follow up comments as respons to your
statements.
	 
	1. As H.248.1 states that the normalMGExecutionTime is "settable
by the MGC to indicate the interval within which the MGC expects a
response to any transaction from the MG (exclusive of network delay)",
this means the RTT is not included in the normalMGExecutionTime. So the
normalMGExecutionTime should not be reduced with RTT. As a matter of
fact, the normalMGExecutionTime, which does not include any RTT, is of
relevance only for the MG, as the MGC must take RTT into account.
	[KJBII] You're right.  I didn't review the text prior to
responding and forgot about this point.  The receiving entity has to
account for delay, not the sending entity. 
	 
	2. I think usage of the base root timers is simpler if the
timers are kept apart between the two nodes so that separate timers are
used on each side. Then neither of the nodes have to locally add or
subtract any delay from any of the timers but the values set through the
base root properties are the ones really used. Here is how this can be
done:
	 
	- MG needs to send transaction response or transaction pending
normalMGExecutionTime seconds after transaction request was received or
last transaction pending was sent.
	- MGC expects transaction response or transaction pending
MGProvisionalResponseTimerValue seconds after transaction request was
sent or after last transaction pending was received.
MGProvisionalResponseTimerValue is typically set to
normalMGExecutionTime + RTT.
	[KJBII] Upon receipt of a pending, the receiver is supposed to
go to a longer retransmission timer -- which would be the execution
timer under normal circumstances.  It seems to me that the
MGProvisionalResponseTimerValue would be that timer.  So it doesn't make
a lot of sense for it to differ from the normal execution time solely by
network delay.  It also seems to me that the MGC would account for
network delay automatically when running the MGExecutionTime and waiting
for an original answer.  I need to think on this some and perhaps I will
draft a contribution to the upcoming SG16 meeting, since there appears
to be some redundancy, or at least a deficiency in the root package. 
	[Jerker Zetterlund (AL/EAB)] I think it is important that for
each side, but maybe especially for the MG, the values set on the base
root timers can be used as they are so that the nodes don't have to
locally add or subtract anything from the timers. Those base root timers
are not easy to use if you need to change them before applying them.
That's why I think the base root package timers more or less only need
to contain one timer for the MG to know when it latest should send a
response or pending to a transaction and another timer for the MG to
know when it latest should expect a transaction response or pending from
the MGC. 
	The equivalent timers in the MGC can be set locally without
involving any base root properties towards the MG (really, what should
the MG do if MGC sends down the MGC timers, store them but not use them
or ignore them?).

	And similar when MGC is responder.
	 
	Best regards,
	 
	Jerker

________________________________

	From: Kevin Boyle [mailto:[email-masked]] 
	Sent: den 16 januari 2006 20:04
	To: Jerker Zetterlund (AL/EAB); [email-masked]
	Subject: RE: [Megaco] Provisional Response Timer Clarification

	Comments inline. [KJBII]
	 
	Kevin

________________________________

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jerker Zetterlund (AL/EAB)
		Sent: Monday, January 16, 2006 9:33 AM
		To: [email-masked]
		Subject: [Megaco] Provisional Response Timer
Clarification

		Hello Kevin, 

		I do have a question of clarification regarding the
below thread. This is how I think the timers should be used: 

		When MG is responder: 
		- MG sends pending at the latest at expiry of MG timer
"MGNormalExecutionTime". The "MGNormalExecutionTime" is started when the
transaction request is received in MG.
		[KJBII] Well... yes. But remember that the MGC will
already be running the MGNormalExecution timer when it SENDS the
message.  So the MG will be a bit behind when you account for latency in
the network.  So, really, the MG should reduce its timer by twice the
amount of latency in the network, in order to allow for the RTT. 

		- MGC resends transaction request if it did not receive
a pending or reply at expiry of MGC timer "MGProvisionalResponseTimer".
The "MGProvisionalResponseTimer" is started when transaction request is
sent from MGC and when pending is recevied from MG.
		[KJBII] No.   The MGC retransmits if it hasn't heard
anything by the expiry of the MGNormalExecutionTime.  If the MGC
receives a Pending, then it reverts to the MGProvisionalResponseTimer
for all retransmissions after the receipt of the Pending. 

		When MGC is responder: 
		- MGC sends pending at the latest at expiry of MGC timer
"MGCNormalExecutionTime". The "MGCNormalExecutionTime" is started when
the transaction request is received in MGC.

		- MG resends transaction request if it did not receive a
pending or reply at expiry of MG timer "MGCProvisioalResponseTimer". The
"MGCProvisionalResponseTimer" is started when transaction request is
sent from MG and when pending is recevied from MGC.
		[KJBII] See the above answers.  These would be similar,
except using the timers for the MGC rather than the MG. 

		Do you agree with this? 

		Thanks, 

		Jerker 

		To: "Navdeep Bhatia" <navdeep.bhatia at
flextronicssoftware.com>, <megaco at ietf.org> 
		Subject: RE: [Megaco] Provisional Response Timer
Clarification 
		From: "Kevin Boyle" <kboyle at nortel.com> 
		Date: Tue, 29 Nov 2005 03:02:03 -0500 
		Cc: 
		List-help: <mailto:[email-masked]?subject=help
<mailto:[email-masked]?subject=help> > 
		List-id: Media Gateway Control <megaco.ietf.org> 
		List-post: <mailto:[email-masked]
<mailto:[email-masked]> > 
		List-subscribe:
<https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco> >,
<mailto:[email-masked]?subject=subscribe
<mailto:[email-masked]?subject=subscribe> > 
		List-unsubscribe:
<https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco> >,
<mailto:[email-masked]?subject=unsubscribe
<mailto:[email-masked]?subject=unsubscribe> > 

		Sender: megaco-bounces at ietf.org 
		Thread-index: AcX0nkKDM+bCuipfR9CLOKQMytS4MwAHE4tQ 
		Thread-topic: [Megaco] Provisional Response Timer
Clarification 

------------------------------------------------------------------------
-------- 

		In terms of practical application, the responder should
send the first 
		Pending just as soon as it is known that a Reply cannot
be returned 
		within the normalExecutionTime.  This allows the sender
to reset its 
		retransmission timers accordingly.  Subsequent Pendings
should be sent 
		prior to the exhaustion of the
ProvisionalResponseTimerValue, which 
		would then be reset. 

		For the MG as responder, the MG should send Pendings per
the MG timers 
		(MGProvisionalReponseTimerValue and
normalMGExecutionTime).  For the MGC 
		as responder, it should send Pendings per the MGC timers

		(MGCProvisionalReponseTimerValue and
normalMGCExecutionTime). 

		Kevin 

		-----Original Message----- 
		From: megaco-bounces at ietf.org [mailto:megaco-bounces
<mailto:megaco-bounces>  at ietf.org] On Behalf 
		Of Navdeep Bhatia 
		Sent: Monday, November 28, 2005 11:33 PM 
		To: megaco at ietf.org 
		Subject: [Megaco] Provisional Response Timer
Clarification 

		Hi 

		As per V3, definition of
MGProvisionalResponseTimerValue Indicates the 
		time within which the MGC should expect a Pending
Response from the MG 
		if a transaction cannot be completed. 
		Initially set to normalMGExecutionTime plus network
delay, but may be 
		lowered. 

		So the query is , which entity should run the 
		MGProvisionalResponseTimer- 
		1) MGProvisionalResponsetimer(value for which is defined
above) should 
		be run at MGC, whereas MG will use the "Normal MG
Execution Time"  for 
		generating any  Pending response. 

		or 
		2) MG should use the (MGProvisionalResponsetimerValue
minus 
		NetworkDelay) for generating the pending responses. 

		If it is (1)  then what is MGC supposed to do after the
expiry of 
		MGProvisionalResponsetimer since the re-transmissions
timers are 
		calculated using exponential Backoff mechanism as
suggested in the 
		Section D.1.3 (V3). 

		Regards, 
		Navdeep 

		***********************  FSS-Private
*********************** 
		"DISCLAIMER: This message is proprietary to Flextronics
Software Systems 
		Limited (FSS) and is intended solely for the use of the
individual to 
		whom it is addressed. It may contain  privileged or
confidential 
		information and should not be circulated or used for any
purpose other 
		than for what it is intended. If you have received this
message in 
		error, please notify the originator immediately. 
		If you are not the intended recipient, you are notified
that you are 
		strictly  prohibited  from  using, copying, altering, or
disclosing the 
		contents of this message.  FSS  accepts no
responsibility  for loss or 
		damage arising from the use of  the information
transmitted by this 
		email including damage from virus." 

		_______________________________________________ 
		Megaco mailing list 
		Megaco at ietf.org 
		https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>  

		_______________________________________________ 
		Megaco mailing list 
		Megaco at ietf.org 
		https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>  

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Christian Groves <[email-masked]>
Date: Thu, 19 Jan 2006 11:31:22 +1100

Attached is some history on the matter from the person who added it (not 
me)...

Christian

Jerker Zetterlund (AL/EAB) wrote:

> *From:* Kevin Boyle [mailto:[email-masked]]
> *Sent:* den 17 januari 2006 17:31
> *To:* Jerker Zetterlund (AL/EAB); [email-masked]
> *Subject:* RE: [Megaco] Provisional Response Timer Clarification
>
> Comments inline. [KJBII]
>  
> Kevin
>
>     *From:* Jerker Zetterlund (AL/EAB)
>     *Sent:* Tuesday, January 17, 2006 10:48 AM
>     *To:* Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked]
>     *Subject:* RE: [Megaco] Provisional Response Timer Clarification
>
>     Hello Kevin,
>      
>     I have a couple of follow up comments as respons to your statements.
>      
>     response to any transaction from the MG (*exclusive of network
>     delay*)", this means the RTT is not included in the
>     normalMGExecutionTime. So the normalMGExecutionTime should not be
>     reduced with RTT. As a matter of fact, the normalMGExecutionTime,
>     which does not include any RTT, is of relevance only for the MG,
>     as the MGC must take RTT into account.
>     responding and forgot about this point.  The receiving entity has
>     to account for delay, not the sending entity. 
>      
>     2. I think usage of the base root timers is simpler if the timers
>     are kept apart between the two nodes so that separate timers are
>     used on each side. Then neither of the nodes have to locally add
>     or subtract any delay from any of the timers but the values set
>     through the base root properties are the ones really used. Here is
>     how this can be done:
>      
>     normalMGExecutionTime seconds after transaction request was
>     received or last transaction pending was sent.
>     MGProvisionalResponseTimerValue seconds after transaction request
>     was sent or after last transaction pending was received.
>     [KJBII] Upon receipt of a pending, the receiver is supposed to go
>     to a longer retransmission timer -- which would be the execution
>     MGProvisionalResponseTimerValue would be that timer.  So it
>     doesn't make a lot of sense for it to differ from the normal
>     execution time solely by network delay.  It also seems to me that
>     the MGC would account for network delay automatically when running
>     the MGExecutionTime and waiting for an original answer.  I need to
>     think on this some and perhaps I will draft a contribution to the
>     upcoming SG16 meeting, since there appears to be some redundancy,
>     or at least a deficiency in the root package. 
>     [Jerker Zetterlund (AL/EAB)] I think it is important that for each
>     side, but maybe especially for the MG, the values set on the base
>     root timers can be used as they are so that the nodes don't have
>     to locally add or subtract anything from the
>     timers. Those base root timers are not easy to use if you need to
>     change them before applying them. That's why I think the base root
>     package timers more or less only need to contain one timer for the
>     MG to know when it latest should send a response or pending to a
>     transaction and another timer for the MG to know when it latest
>     should expect a transaction response or pending from the MGC.
>     involving any base root properties towards the MG (really, what
>     should the MG do if MGC sends down the MGC timers, store them but
>     not use them or ignore them?).
>      
>      
>      

Subject: Re: Provisional Response Timer Value
From: "Rosen, Brian" <[email-masked]>
To: [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.

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

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

>
> 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.
Covered above.  It's the receiver, and the value includes network delay

>
> 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?
The SENDER runs a timer which is used to trigger request repetitions.
The RECIEVER runs a timer which is used to trigger Pending responses.
>
> 5. Why do we need this property in Base root Package separately? Is it
> not derivable from
> normalMGExecutionTime/normalMGCExecutionTime and the
> network delay?
See above - one is a timer for the sender, the other if for the receiver.

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

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