Subject: RE: [Megaco] Baseroot v2 Use case query

From: "Anant Kumar \(anant\)" <[email-masked]>
Date: Wed, 17 May 2006 07:27:01 -0700

more inline

________________________________

From: B Venkat S.R Swamy [mailto:[email-masked]] 

 "Anant Kumar \(anant\)" [email-masked]

This is probably the right place for this query. We are implementing the
baseroot v2 package and discussing the various timers and retransmission
limits. I will present this discussion in the context of a transaction
originated by and MGC  but this could apply in the reverse direction as
well.

Lets say a transaction is originated by the MGC and a provisional
response is received from the MG. It does not make any sense for the MGC
to continue to retransmit the transaction request - it starts an
appropriately long timer and sleeps waiting for the final response.

[BVS] You are right that retransmission should not be at the same
frequency
as the earlier ones, and should switch to some bigger timer values. 
[/BVS]

Clearly, if/when the final response is received, it will stop the timer
and everything is good. The problem case is when the final response is
not received by the MGC.

In this situation, one of the following 2 cases is true:

Possibility 1: The MG never sent the final response (error/bug).
Possibility 2: The MG sent the response but it was lost in the network.

The question is: what is the behavior (on the MG and the MGC) in this
situation.

1. Should the MGC retransmit the transaction request upon expiry of the
timer mentioned earlier?

[BVS] Yes, MGC should re-transmit the request if the timer gets expired
and restart
the timer. If the MGC never gets reply of the request, then depending on
implementation
it can even clear the association and wait for re-registration or
Disconnect method from MG.
Other possiblity is that in V2, pendingLimit feature has been introduced
and MGC on receiving
multiple pending can take corrective action itself or should wait for
the 
Error 506 ("Number of TransactionPendings Exceeded") from MG.
[/BVS]

[anant] I do not quite understand the rationale behind this.
Retransmissions are, generally speaking, made to guarantee delivery of
the original message. If the pending response has been received, it is
safe to assume that the original transaction request was received by the
MG. Why retransmit?

 The question is not really what the behavior should be upon expiry of
some intermediate timer but when the last timer fires and pendingLimit
is not reached and no final response has been seen!

2. Should the MG request ImmediateAck on the final response (MGCP
requires this) and if the immediate ack is not received, keep
retransmitting the response - much like it was a request (MGCP (or is it
TGCP) mandates this).

[BVS] Megaco Protocol clearly provide the guidelines to send IMMACK on
the final response if it has 
already generated pending. If the IMMACK is received then MG removes the
transaction context. If
however IMMACK is not received, then protocol does not say anything on
sending the transaction response again
untill retransmission occur from MGC. The transaction context is removed
once LongTimer gets expired.
If MG has generated enough pending and exceeds pending limit then it
generates 
Error 506 ("Number of TransactionPendings Exceeded")to the MGC and
clears its transaction context.
[/BVS]

[anant] once again, the reason this question arose is because the
protocol is silent on this! 

If the gateway is buggy, I guess field intervention will be needed and
the MGC can assume the transaction to be in error. Before it does that,
does it make sense to retx the request one last time, to accommodate
posibility 2 (the response wa slost in the network).

In the situation where the gateway behaves correctly, it will generate
an error response when pendingLimit is reached. I guess the tricky
question is when possibility 2 (final response is lost in the network)
happens. Gateway has sent final (OK or Error) response with IMMACK. It
has not received the IMMACK and the MGC has not received the final
response.

I personally see merit to the original request being retransmitted at
least once at the expiry of the timer above (I think we are thinking of
setting it to pendingLimit*provisionalResponseTimer).

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

---

From: "Anant Kumar \(anant\)" <[email-masked]>
Date: Thu, 18 May 2006 07:10:07 -0700

Kevin, Albrecht, would like to hear your thoughts on this.

From: Anant Kumar (anant) 
Sent: Wednesday, May 17, 2006 7:27 AM
To: B Venkat S.R Swamy
Cc: [email-masked]
Subject: RE: [Megaco] Baseroot v2 Use case query

more inline

---

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 18 May 2006 14:48:43 -0400

Comments inline. [KJBII]
 
Kevin

	From: Anant Kumar (anant) [mailto:[email-masked]] 
	Sent: Wednesday, May 17, 2006 10:27 AM
	To: B Venkat S.R Swamy
	Cc: [email-masked]
	Subject: RE: [Megaco] Baseroot v2 Use case query

	more inline

	From: B Venkat S.R Swamy
[mailto:[email-masked]] 

	
	This is probably the right place for this query. We are
implementing the
	baseroot v2 package and discussing the various timers and
retransmission
	limits. I will present this discussion in the context of a
transaction
	originated by and MGC  but this could apply in the reverse
direction as
	well.
	
	Lets say a transaction is originated by the MGC and a
provisional
	response is received from the MG. It does not make any sense for
the MGC
	to continue to retransmit the transaction request - it starts an
	appropriately long timer and sleeps waiting for the final
response.
	
	[BVS] You are right that retransmission should not be at the
same frequency
	as the earlier ones, and should switch to some bigger timer
values. 
	[/BVS]
	[KJBII] This is not entirely correct.  The MGC switches to a
much longer retransmit timer, and then awaits its expiry to retransmit
the message.  If there is not another Pending, or a Reply by the time
this longer retransmit timer expires, the MGC would retransmit the
original Transaction again. 

	Clearly, if/when the final response is received, it will stop
the timer
	and everything is good. The problem case is when the final
response is
	not received by the MGC.

	Possibility 1: The MG never sent the final response (error/bug).
	Possibility 2: The MG sent the response but it was lost in the
network.
	
	The question is: what is the behavior (on the MG and the MGC) in
this
	situation.
	
	1. Should the MGC retransmit the transaction request upon expiry
of the
	timer mentioned earlier?
	
	[BVS] Yes, MGC should re-transmit the request if the timer gets
expired and restart
	the timer. If the MGC never gets reply of the request, then
depending on implementation
	it can even clear the association and wait for re-registration
or Disconnect method from MG.
	Other possiblity is that in V2, pendingLimit feature has been
introduced and MGC on receiving
	multiple pending can take corrective action itself or should
wait for the 
	Error 506 ("Number of TransactionPendings Exceeded") from MG.
	[/BVS]
	[KJBII] There is nothing that restricts the MG from using Error
506 in V1. 

	 The question is not really what the behavior should be upon
expiry of some intermediate timer but when the last timer fires and
pendingLimit is not reached and no final response has been seen!
	[KJBII] Pending does not fulfill the requirement of a reply --
all it does is indicate that the reply is going to take longer than the
normal retransmit time to produce.  The sender of the transaction cannot
consider the transaction complete until it receives a reply.  The way
the receiver prevents getting multiple retransmissions of the
transaction is to send pending before the longer retransmission timer
expires.  The purpose of pending is to temporarily prevent
retransmission, not exclude retransmission as a possibility.  All this
is discussed in Annex D.

	2. Should the MG request ImmediateAck on the final response
(MGCP
	requires this) and if the immediate ack is not received, keep
	retransmitting the response - much like it was a request (MGCP
(or is it
	TGCP) mandates this).
	[KJBII] Keep in mind that this is not MGCP, and just because
MGCP does or does not require something is irrelevant.
	
	[BVS] Megaco Protocol clearly provide the guidelines to send
IMMACK on the final response if it has 
	already generated pending. If the IMMACK is received then MG
removes the transaction context. If
	however IMMACK is not received, then protocol does not say
anything on sending the transaction response again
	untill retransmission occur from MGC. The transaction context is
removed once LongTimer gets expired.
	If MG has generated enough pending and exceeds pending limit
then it generates 
	Error 506 ("Number of TransactionPendings Exceeded")to the MGC
and clears its transaction context.
	[/BVS]

	[anant] once again, the reason this question arose is because
the protocol is silent on this! 
	[KJBII] Silent?  To quote from clause D.1.4: "An entity that
sends a provisional response shall include the immAckRequired field in
the ensuing final response, indicating that an immediate confirmation is
expected."  I'm not sure how much more explicit the text can get.  The
reply would be retransmitted until such time the TransResponseAck is
received.

	If the gateway is buggy, I guess field intervention will be
needed and the MGC can assume the transaction to be in error. Before it
does that, does it make sense to retx the request one last time, to
accommodate posibility 2 (the response wa slost in the network).

	In the situation where the gateway behaves correctly, it will
generate an error response when pendingLimit is reached. I guess the
tricky question is when possibility 2 (final response is lost in the
network) happens. Gateway has sent final (OK or Error) response with
IMMACK. It has not received the IMMACK and the MGC has not received the
final response.

	I personally see merit to the original request being
retransmitted at least once at the expiry of the timer above (I think we
are thinking of setting it to pendingLimit*provisionalResponseTimer).