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

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.

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

_______________________________________________
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: Flemming Andreasen <[email-masked]>
Date: Tue, 22 Jan 2002 16:42:20 -0500

> Flemming, is this an oversight and departure from what was really intended?

Yes. The idea was, that upon receiving a provisional response, you switch to a
longer repetition timer aimed at detecting endpoint/termination failures as
opposed to transmission problems. If you don't employ active retransmission of
the final response, a lost final response will only be resent at the long
transaction retransmit interval, which is suboptimal. Depending on the timer
values involved, it could even lead to the transaction timing out (incorrectly).

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 22 Jan 2002 16:42:20 -0500

-- Flemming