Subject: RE: [Megaco] Doubt regarding immAckRequired field.

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 2 Jan 2002 14:36:02 -0500

The immAckRequired flag was introduced because without it a protocol glitch
was possible, so what you postulate is not a nice situation.  Anyway, to
answer your question, I would say that retransmission of the final response
(with exponential backoff) is necessary until an acknowledgement is
received.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, December 30, 2001 8:23 AM
To: [email-masked]
Subject: [Megaco] Doubt regarding immAckRequired field.

Hi

I have a doubt regarding immAckRequired field.

Section D.1.4 says

"An entity that sends a provisional response, SHALL include the
immAckRequired
field in the ensuing final response, indicating that an immediate
confirmation
is expected."

Now what would happen, if the entity receiving the final response with
immAckRequired field, does not send the immediate confirmation? In this case
do
we need to retransmit the response till we get the confirmation?

Please clarify.

Regards
Vivek

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

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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 2 Jan 2002 14:36:02 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, December 30, 2001 8:23 AM
To: [email-masked]
Subject: [Megaco] Doubt regarding immAckRequired field.

Hi

Section D.1.4 says

Please clarify.

Regards
Vivek

---

From: [email-masked]
Date: Thu, 3 Jan 2002 20:04:49 +0530

If this is the case, then we need update the same in the v2 draft.

Regards
Vivek

"Tom-PT Taylor" <[email-masked]> on 01/03/2002 01:06:02 AM

To:   Vivek Bansal/HSS@HSS, [email-masked]
cc:

Subject:  RE: [Megaco] Doubt regarding immAckRequired field.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, December 30, 2001 8:23 AM
To: [email-masked]
Subject: [Megaco] Doubt regarding immAckRequired field.

Hi

Section D.1.4 says

Please clarify.

Regards
Vivek

---

From: [email-masked]
Date: Wed, 9 Jan 2002 14:16:48 +0530

Hi Christian

Regarding the Immediate ACK nothing has been mentioned in the protocol. I had
asked if the entity sending response sends the response with immAckRequired
field, and the entity receiving the response does not send back ACK, then what
should entity sending the response do. To handle this Tom had suggested that the
entity sending rerponse will retransmit the response till it gets the ACK of it.
And this solutions seems fine, otherwise the presence of immAckRequired field in
the message will not make any difference.

This is all that I wanted to be updated in V2.

Regards
Vivek

Christian Groves <[email-masked]> on 01/09/2002 08:27:43 AM

To:   Vivek Bansal/HSS@HSS
cc:   Tom-PT Taylor <[email-masked]>, [email-masked]

Subject:  Re: [Megaco] Doubt regarding immAckRequired field.

G'Day Vivek,

What exactly do you propose to update in v2?

Regards, Christian

---

From: Raphael Tryster <[email-masked]>
Date: Wed, 9 Jan 2002 11:33:32 +0200

I have some questions related to this discussion.

1.	What should an entity receiving a response do if the immAckRequired
field is absent?  Is sending ACK at other times optional?
2.	When an entity sends ACK because it received a response with
immAckRequired, should it ACK only that transaction, or also other
transactions for which it recently received responses, but where no
immAckRequired was specified?
3.	In the previous question, is there a precise definition of
"recently"?
4.	When an entity sends ACK with a transaction id range, may the
recipient of the ACK assume that every number in the range represents a
transaction that was actually sent?  Or is the sender of the ACK permitted
to send a range even though it only used some of the transaction numbers in
that range, and the meaning is "whatever transactions in this range I sent,
I got your answers"?

Raphael Tryster

	-----Original Message-----
	From:	[email-masked] [SMTP:[email-masked]]
	Sent:	Wednesday, 09 January, 2002 10:47 AM
	To:	Christian Groves
	Cc:	Tom-PT Taylor; [email-masked]
	Subject:	Re: [Megaco] Doubt regarding immAckRequired field.

	Hi Christian

	Regarding the Immediate ACK nothing has been mentioned in the
protocol. I had
	asked if the entity sending response sends the response with
immAckRequired
	field, and the entity receiving the response does not send back ACK,
then what
	should entity sending the response do. To handle this Tom had
suggested that the
	entity sending rerponse will retransmit the response till it gets
the ACK of it.
	And this solutions seems fine, otherwise the presence of
immAckRequired field in
	the message will not make any difference.

	Regards
	Vivek

	Christian Groves <[email-masked]> on 01/09/2002
08:27:43 AM

	To:   Vivek Bansal/HSS@HSS

	G'Day Vivek,

	Regards, Christian

---

From: Raphael Tryster <[email-masked]>
Date: Wed, 9 Jan 2002 11:33:32 +0200

Raphael Tryster

	-----Original Message-----
	From:	[email-masked] [SMTP:[email-masked]]
	Sent:	Wednesday, 09 January, 2002 10:47 AM
	To:	Christian Groves
	Cc:	Tom-PT Taylor; [email-masked]
	Subject:	Re: [Megaco] Doubt regarding immAckRequired field.

	Hi Christian

	Regards
	Vivek

	To:   Vivek Bansal/HSS@HSS

	G'Day Vivek,

	Regards, Christian

---

From: "Marcello Pantaleo (EED)" <[email-masked]>
Date: Thu, 10 Jan 2002 16:36:48 +0100

Hi Vivek,

how does it sound this (addition between <SA> and <EA>?

H.248, Section D.1.4 Provisional response:
...
Upon receipt of a final response following receipt of provisional responses, an immediate confirmation shall be sent, and normal repetition timers shall be used thereafter.  An entity that sends a provisional response, SHALL include the immAckRequired field in the ensuing final response, indicating that an immediate confirmation is expected.
<SA>If an immediate confirmation is not received, the entity that sent the final response will retransmit the final response including the immAckRequired field (with exponential backoff) until a confirmation is received.<EA> Receipt of a Transaction Pending after receipt of a reply shall be ignored.

If it sounds ok I guess this should be also added to the IG.

Regards,
Marcello

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, January 10, 2002 1:04 AM
To: [email-masked]
Cc: Tom-PT Taylor; [email-masked]
Subject: Re: [Megaco] Doubt regarding immAckRequired field.

G'Day Vivek,

I understood that its not mentioned what I was asking for was a wording
proposal to D.1.4 or whereever it is relevant to assist the IG and v2
editors.

Regards, Christian

---

From: "Marcello Pantaleo (EED)" <[email-masked]>
Date: Thu, 10 Jan 2002 16:36:48 +0100

Hi Vivek,

Regards,
Marcello

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, January 10, 2002 1:04 AM
To: [email-masked]
Cc: Tom-PT Taylor; [email-masked]
Subject: Re: [Megaco] Doubt regarding immAckRequired field.

G'Day Vivek,

Regards, Christian

---

From: [email-masked]
Date: Tue, 15 Jan 2002 17:09:22 +0530

Hi Marcello, Christian

I need some more clarification to this. Now when we are retransmitting the
response, then we should have some kind of threshold value for the
retransmission also. And if the number of retries exceeds the threshold, then
should it assume that the peer entity has gone down and start the recovery
mechanism as suggested for transaction request.

Regards
Vivek

"Marcello Pantaleo (EED)" <[email-masked]> on 01/10/2002
09:06:48 PM

To:   Vivek Bansal/HSS@HSS
cc:   "Christian Groves (EAA)" <[email-masked]>, Tom-PT Taylor
      <[email-masked]>, [email-masked]

Hi Vivek,

H.248, Section D.1.4 Provisional response:
...
Upon receipt of a final response following receipt of provisional responses, an
immediate confirmation shall be sent, and normal repetition timers shall be used
thereafter.  An entity that sends a provisional response, SHALL include the
immAckRequired field in the ensuing final response, indicating that an immediate
confirmation is expected.
<SA>If an immediate confirmation is not received, the entity that sent the final
response will retransmit the final response including the immAckRequired field
(with exponential backoff) until a confirmatio is received.<EA> Receipt of a
Transaction Pending after receipt of a reply shall be ignored.

Regards,
Marcello

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, January 10, 2002 1:04 AM
To: [email-masked]
Cc: Tom-PT Taylor; [email-masked]
Subject: Re: [Megaco] Doubt regarding immAckRequired field.

G'Day Vivek,

Regards, Christian

---

From: [email-masked]
Date: Tue, 15 Jan 2002 17:09:22 +0530

Hi Marcello, Christian

Regards
Vivek

To:   Vivek Bansal/HSS@HSS

Hi Vivek,

Regards,
Marcello

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, January 10, 2002 1:04 AM
To: [email-masked]
Cc: Tom-PT Taylor; [email-masked]
Subject: Re: [Megaco] Doubt regarding immAckRequired field.

G'Day Vivek,

Regards, Christian

---

From: [email-masked]
Date: Thu, 17 Jan 2002 08:54:32 +0530

Hi Marcello, All

Before actually phrasing the paragragh can we discuss this issue some more to
make it even clearer. We should remember that we need to handle the LONG timer
also. Here is the suggested behavior for the entity sending the Transaction
response containing immAckRequired field

1. The entity sending response with immAckRequired field will start
retransmission timers as per section D.1.5. It shall not start the long timer.

2.If the acknowledgement comes, the entity sending response will stop
retransmitting the response and start the long timer for the remaining duration.

3.If the acknowledgement does not come within N retries (or  time elapsed since
the sending of the initial datagram is no greater than T-MAX), then entity
sending response shall assume that the peer entity has gone down and would start
the recovery action as suggested in section 11.4/11.5 of rfc 3015. It shall stop
retransmitting the response and it start the long timer for that transaction
response for the remaining duration.

With this we have tried to avoid running two timers for the same transaction.

Regards
Vivek
Hughes Software Systems

To:   Vivek Bansal/HSS@HSS

Hi Vivek,

(with exponential backoff) until a confirmation is received.<EA> Receipt of a

Regards,
Marcello

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, January 10, 2002 1:04 AM
To: [email-masked]
Cc: Tom-PT Taylor; [email-masked]
Subject: Re: [Megaco] Doubt regarding immAckRequired field.

G'Day Vivek,

Regards, Christian

---

From: [email-masked]
Date: Thu, 17 Jan 2002 08:54:32 +0530

Hi Marcello, All

Regards
Vivek
Hughes Software Systems

To:   Vivek Bansal/HSS@HSS

Hi Vivek,

Regards,
Marcello

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, January 10, 2002 1:04 AM
To: [email-masked]
Cc: Tom-PT Taylor; [email-masked]
Subject: Re: [Megaco] Doubt regarding immAckRequired field.

G'Day Vivek,

Regards, Christian

---

From: [email-masked]
Date: Thu, 17 Jan 2002 10:30:29 +0530

Hi Marcello, All

Regards
Vivek
Hughes Software Systems

To:   Vivek Bansal/HSS@HSS

Hi Vivek,

Regards,
Marcello

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, January 10, 2002 1:04 AM
To: [email-masked]
Cc: Tom-PT Taylor; [email-masked]
Subject: Re: [Megaco] Doubt regarding immAckRequired field.

G'Day Vivek,

Regards, Christian

---

From: [email-masked]
Date: Thu, 17 Jan 2002 10:30:29 +0530

Hi Marcello, All

Regards
Vivek
Hughes Software Systems

To:   Vivek Bansal/HSS@HSS

Hi Vivek,

Regards,
Marcello

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, January 10, 2002 1:04 AM
To: [email-masked]
Cc: Tom-PT Taylor; [email-masked]
Subject: Re: [Megaco] Doubt regarding immAckRequired field.

G'Day Vivek,

Regards, Christian

---

From: [email-masked]
Date: Thu, 17 Jan 2002 19:04:52 +0530

Hi Marcello, All

Regards
Vivek
Hughes Software Systems

To:   Vivek Bansal/HSS@HSS

Hi Vivek,

Regards,
Marcello

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, January 10, 2002 1:04 AM
To: [email-masked]
Cc: Tom-PT Taylor; [email-masked]
Subject: Re: [Megaco] Doubt regarding immAckRequired field.

G'Day Vivek,

Regards, Christian

---

From: [email-masked]
Date: Thu, 17 Jan 2002 19:04:52 +0530

Hi Marcello, All

Regards
Vivek
Hughes Software Systems

To:   Vivek Bansal/HSS@HSS

Hi Vivek,

Regards,
Marcello

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, January 10, 2002 1:04 AM
To: [email-masked]
Cc: Tom-PT Taylor; [email-masked]
Subject: Re: [Megaco] Doubt regarding immAckRequired field.

G'Day Vivek,

Regards, Christian

---

From: "Kaul, Bharat" <[email-masked]>
Date: Fri, 18 Jan 2002 15:14:43 -0800

Agreed...I don't see any reason to develop retransmission mechanisms for the
responses just because immAck was sent and we are not receiving replies.
immAck is just a request which may or may not get fulfilled and doesn't
affect any protocol operation.

- Bharat

-----Original Message-----
From: J K Ramchandra [mailto:[email-masked]]
Sent: Friday, January 18, 2002 2:49 PM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Megaco] Doubt regarding immAckRequired field.

Hi all,

I think we are heading somewhere here. If I remember correctly, the sole
purpose
of responseAck is to reduce the overall memory consumption. The entity
sending
the response (transaction Reply) can clean up its response buffer once
responsAck is received for that transaction. Otherwise it has to wait till
long
timer to clean up these buffer. Normally, the response ack is appended with
the
next message sent towards that destination (MG/MGC). By setting
immAckRequired
flag in the response, it is requesting to send it immediately (not waiting
till
the next message). Probably, the receving entity will send a stand-alone
response ack message back.

Now, let us see what is the impact of not receiving responseAck. This could
be
due to two reasons:
a. The response with immAckRequired field has not reached the remote entity,
b. The remote entity receved the response with immAckRequired field, but
simply
ignored it and not sent the responseAck back.

In case 'a', the remote entity will re-transmit the transation request and
everything should be OK this time. No harm done.

In case 'b', the response buffers are held till long timer. Except for this
longer holding of buffers, no other damage here as well. I don't see why
responding entity WAIT for his response to reach the destination. It is
orginator who care about the response.

The reason for setting the immAckRequired in the final response (i.e. after
one
or more transaction Pending was sent), I believe, is due to the fact that
this
specific transaction has already  active for quite some time and better to
be
cleaned up with the immediate response ack.

The re-transmission is always initiated by the entity who is initiating the
transaction request as specified in the D.1.3. Responding entity will
retransmit
the response only when the repeated request is received. This is the case
with
most of the protocols (mgcp, SIP or any of the PSTN protocols) and I don't
see
why we have to invent re-transmission  mechanism on the responding side. A
simple long timer based clean up is sufficient currently on the receving
side
and it is better be that way.

Am I missing something here?

Regards,

J K Ramachandra,
IPGEN

---

From: "Kaul, Bharat" <[email-masked]>
Date: Fri, 18 Jan 2002 15:14:43 -0800

- Bharat

-----Original Message-----
From: J K Ramchandra [mailto:[email-masked]]
Sent: Friday, January 18, 2002 2:49 PM
To: [email-masked]; [email-masked];

Hi all,

Regards,

J K Ramachandra,
IPGEN

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 22 Jan 2002 14:35:49 -0500

I finally made the effort to track down the original issue that led to the
specification of immAckRequired back in Feb'00.  Here is the reason as
stated at the time (from a Chip Sharp/Flemming Andreasen intervention):

<begin>

Section:        D.1.4
Category:       Technical
Issue:          The draft text specifies that receipt of a provisional
response
will imply a switch to a longer repetition timer for the transaction.
However, there is no other reliability mechanism in place to detect the
loss of the final response for that transaction, and consequently a lost
final response may not be detected for a while (depends on the longer
repetition timer). This leads to suboptimal behaviour of the protocol with
unnecessary long time-outs.
Proposal:       It is proposed, that a final response issued after a
provisional
response requires an immediate confirmation to enable rapid detection of a
lost final response. Since the provisional response itself may be lost,
this implies that the final response should include an indication that a
response acknowledgement is required (immediately).

<end>

The implication is that it's not just a matter of the response sender's
convenience (i.e. faster clearing of buffers), but of ensuring that the
response is retransmitted as quickly as possible in the event of loss.  The
problem is that we don't actually have any text which says that the
responder should retransmit responses of its own accord.  J K Ramchandra
appears to be right in saying that responses are retransmitted only when
retransmitted requests are received.

Flemming, is this an oversight and departure from what was really intended?
People in general: do we agree on this interpretation, and is it adequate? 

-----Original Message-----
From: Kaul, Bharat [mailto:[email-masked]]
Sent: Friday, January 18, 2002 6:15 PM
To: [email-masked]
Subject: RE: [Megaco] Doubt regarding immAckRequired field.

- Bharat

-----Original Message-----
From: J K Ramchandra [mailto:[email-masked]]
Sent: Friday, January 18, 2002 2:49 PM
To: [email-masked]; [email-masked];

Hi all,

Regards,

J K Ramachandra,
IPGEN