Subject: [Megaco] RE: Base Root Package Interpretation

From: "Dave Stephens" <[email-masked]>
Date: Mon, 15 Jan 2007 09:55:37 -0800

I posted the email below back in December and so far have had no response.
Could someone please review the request and let me know if:
A. This is indeed the correct place to post such question.
B. If A is yes if someone would be able to take the time to answer it or
propose where we might be 
able to gather more information to allows us to clarify this issue.
 
Thanks in advance,
 
Dave
 
-------------------------------------------------------------------
Dave Stephens
Team Leader VXML Team
RadiSys Canada Inc.
Ph:  604 918 6381
Fax: 604 918 6400

  _____  

From: Dave Stephens [mailto:[email-masked]] 
Sent: Friday, December 08, 2006 3:01 PM
To: [email-masked]'
Subject: Base Root Package Interpretation

We are currently working through implementing the Base Root Package and
would appreciate hearing your interpretation of how
these elements should be applied to the transaction resend algorithm. Our
interest is only in the MG side although this would 
apply equally to the MGC.  We are using UDP/ALF.
 
We reviewed the previous posting below by Jerker Zetterlund and the follow
up discussion:
http://www1.ietf.org/mail-archive/web/megaco/current/msg06418.html
 
In particular, we are interested in this portion of the posting:
>> 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.
 
Subsequent discussion indicated there might be some follow up in SG16.
However, we have not seen any subsequent clarification of this issue.
 
Our interpretation is that in the absence of the Base Root Package, or the
setting of elements in the package, the retry algorithm as defined in
H.248.1 Appendix D .1.3  is used . In particular, "Implementations SHALL
ensure that the algorithm used to calculate retransmission timing performs
an exponentially increasing backoff of the retransmission timeout for each
retransmission or repetition after the first one."
 
The Base Root package defines the MGCProvisionalResponseTimer element. This
value is calculated by the MGC and represents the time the MGC would like
the MG to wait before retransmitting requests that have received neither a
provisional response  nor a reply to the actual outstanding transaction.
The value is constant and replaces the rate of retransmission as calculated
by the back-off algorithm.  It is in effect as soon as it is set.  One of
the ambiguities here is when does this value take effect.  Does it take
effect as soon as it is set or does it take effect only after the receipt of
a provisional response?  
Our assumption is that the behaviour associated with the
MGCProvisionalResponseTimer is:
1. A timer is started for the MGCProvisionalResponseTimer period after the
initial transaction request has been sent.
2. If it expires without receipt of a provisional response or transaction
reply then the transaction request is resent and the timer restarted for the
same period
3. If a provisional response is received the timer is stopped and restarted
for the same period.
4. If the transaction reply is received it is stopped and not restarted. 
 
Is anybody aware of any subsequent clarification of this issue?  
 
Thanks,
 
Dave
-------------------------------------------------------------------
Dave Stephens
Team Leader VXML Team
RadiSys Canada Inc.
Ph:  604 918 6381
Fax: 604 918 6400
 
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Christian Groves <[email-masked]>
Date: Tue, 16 Jan 2007 10:45:18 +1100

Hello Dave,

Yes this is the correct list for questions. Given the usual December 
rush people don't have a lot of extra time so this may have been lost 
(either that or you were on the wrong one of Santa's lists :). )

Please see my responses below.

Regards, Christian

Dave Stephens wrote:
> B. If A is yes if someone would be able to take the time to answer it 
> or propose where we might be
> ------------------------------------------------------------------------
> *From:* Dave Stephens [mailto:[email-masked]]
> *Sent:* Friday, December 08, 2006 3:01 PM
> *To:* [email-masked]'
> *Subject:* Base Root Package Interpretation
>
> We are currently working through implementing the Base Root Package 
> and would appreciate hearing your interpretation of how
> these elements should be applied to the transaction 
> resend algorithm. Our interest is only in the MG side although this would
> We reviewed the previous posting below by Jerker Zetterlund and the 
> follow up discussion:
> "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.
>  
> Our interpretation is that in the absence of the Base Root Package, or 
> the setting of elements in the package, the retry algorithm as defined 
> in H.248.1 Appendix D .1.3  is used . In particular, "Implementations 
> SHALL ensure that the algorithm used to calculate retransmission 
> timing performs an exponentially increasing backoff of the 
> retransmission timeout for each retransmission or repetition after the 
> first one."
[CNG] To begin with, implementation of the base root package is pretty 
much mandatory. You don't have to set the properties through signalling 
but these base property values should be at least set via provisioning. 
Once the provisional response timer is exceeded Annex D.1.3 would come 
into play.

>  
> The Base Root package defines the MGCProvisionalResponseTimer element. 
> This value is calculated by the MGC and represents the time the MGC 
> would like the MG to wait before retransmitting requests that have 
> received neither a provisional response  nor a reply to the actual 
> outstanding transaction.  The value is constant and replaces the rate 
> of retransmission as calculated by the back-off algorithm.  It is in 
> effect as soon as it is set.  One of the ambiguities here is when does 
> this value take effect.  Does it take effect as soon as it is set or 
> does it take effect only after the receipt of a provisional response? 
[CNG] I always assumed it took effect as soon as it was set.
> 1. A timer is started for the MGCProvisionalResponseTimer period after 
> the initial transaction request has been sent.
> 2. If it expires without receipt of a provisional response or 
> transaction reply then the transaction request is resent and the timer 
> restarted for the same period
> 3. If a provisional response is received the timer is stopped and 
> restarted for the same period.
[CNG] I agree with your assumptions.
> Is anybody aware of any subsequent clarification of this issue? 
[CNG] Any specific suggestions of changes to the text of H.248.1?
> ------------------------------------------------------------------------
>

---

From: "Alvin Chubbs" <[email-masked]>
Date: Tue, 16 Jan 2007 18:04:14 -0800

Christian,

Thank you very much for taking the time to reply to Dave's posting. 

This is an issue that Dave and I have discussed a number of times and we
appreciate that somebody else has taken an interest in clarifying the
expected behaviour.

With respect to your question about specific changes to H.248.1 text, I
attempted to identify the relevant portions of text in Annex D of H.248.1 as
follows:
a) D.1.3 - "Implementations SHALL ensure that the algorithm used to
calculate retranmission timing performs an exponentially increasing
backoff..."
b) D.1.3 - "One possibility is to use the algorithm implemented in TCP-IP,
which uses two variables: The average acknowledgement delay (AAD), estimated
through an exponentially smoothed average of the observed delays..."
c) D.1.4 - "Entities that receive a Transaction Pending shall switch to a
different repetition timer for repeating terminations."
This had a subsequent comment about ProvisionalResponseTimerValue in the
original H.248.1 specification but I believe this line has been removed in
the Implementor's Guide.

After looking again at this text, I'm not so sure that our assumptions below
are correct. In any case, I will provide several possible interpretations of
the retransmission algorithm and indicate where I feel they disagree with
the above text.

Possible retransmission algorithms:
1) Initially use algorithm similar to TCP-IP (estimate delays via observed
delays). When ProvisionalResponseTimerValue received from MGC then use fixed
ProvisionalResponseTimerValue instead of TCP-IP algorithm.
	- this was our assumption below. We assumed that
ProvisionalResponseTimerValue was not mandatory.
	- this appears to disagree with statements a) and c) above when
using the fixed ProvisionalResponseTimerValue

2) Use a fixed mandatory ProvisionalResponseTimerValue all the time with
initial value being provisioned
	- this appears to be what you are suggesting (please correct me if
my understanding is wrong)
	- this also appears to disagree with statements a) and c) above
	- also, this seems to indicate that statement b) in the H.248.1
specification is meaningless / misleading

3) Use exponentially increasing timer with starting value being a mandatory
ProvisionalResponseTimerValue
	- this would be a variation on algorithm 2) that would satisfy the
H.248.1 requirement in statement a)

4) Use algorithm similar to TCP-IP until first Transaction Pending received,
then use fixed ProvisionalResponseTimerValue
	- we know of at least one implementation of this particular
algorithm
	- this appears to agree with all of the statements above from the
H.248.1 specification

Regards,
Alvin

Alvin Chubbs
RadiSys Canada Inc.
Tel:   604-918-6307 
Fax:   604-918-6400  

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Monday, January 15, 2007 3:45 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Megaco] RE: Base Root Package Interpretation

Hello Dave,

Yes this is the correct list for questions. Given the usual December rush
people don't have a lot of extra time so this may have been lost (either
that or you were on the wrong one of Santa's lists :). )

Regards, Christian

Dave Stephens wrote:
> or propose where we might be able to gather more information to allows 
> us to clarify this issue.
>  
> Thanks in advance,
>  
> Dave
>  
> and would appreciate hearing your interpretation of how these elements 
> should be applied to the transaction resend algorithm. Our interest is 
> only in the MG side although this would apply equally to the MGC.  We 
> are using UDP/ALF.
>  
[CNG] To begin with, implementation of the base root package is pretty much
mandatory. You don't have to set the properties through signalling but these
base property values should be at least set via provisioning. 
Once the provisional response timer is exceeded Annex D.1.3 would come into
play.

> restarted for the same period 3. If a provisional response is received 
> the timer is stopped and restarted for the same period.