Subject: [Megaco] Provisional Response Timer Clarification

From: "Jerker Zetterlund \(AL/EAB\)" <[email-masked]>
Date: Mon, 16 Jan 2006 15:32:36 +0100

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

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.

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> 
List-id: Media Gateway Control <megaco.ietf.org> 
List-post: <mailto:[email-masked]> 
List-subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
<mailto:[email-masked]?subject=subscribe> 
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
<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 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

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

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

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 16 Jan 2006 14:04:00 -0500

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: 

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

	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 

	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>

---

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

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

	Hello Kevin, 

	When MG is responder: 

	When MGC is responder: 

	Do you agree with this? 

	Thanks, 

	Jerker 

	Kevin 

	-----Original Message----- 

	Hi 

	or 

	Regards, 
	Navdeep

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 17 Jan 2006 11:31:03 -0500

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. 

	Best regards,
	 
	Jerker

	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: 

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