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

From: J K Ramchandra <[email-masked]>
Date: Fri, 18 Jan 2002 16:48:34 -0600

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

> ----- Original Message -----
> From: <[email-masked]>
> To: "Marcello Pantaleo (EED)" <[email-masked]>
> Cc: "Christian Groves (EAA)" <[email-masked]>; "Tom-PT
> Taylor" <[email-masked]>; <[email-masked]>
> Sent: Thursday, January 17, 2002 10:30 AM
> Subject: RE: [Megaco] Doubt regarding immAckRequired field.
>
> >
> >
> >
> > 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
> >
> >
> >
> >
> >
> >
> >
> > "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]
> >
> > Subject:  RE: [Megaco] Doubt regarding immAckRequired field.
> >
> >
> >
> >
> > 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
> >
> > [email-masked] wrote:
> > >
> > > 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
> > >
> > > [email-masked] wrote:
> > > >
> > > > 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.
> > > >
> > > > 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
> > > >
> > > > _______________________________________________
> > > > Megaco mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/megaco
> > >
> > > _______________________________________________
> > > Megaco mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/megaco
> >
> >
> >
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/megaco
> >
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/megaco
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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: J K Ramchandra <[email-masked]>
Date: Fri, 18 Jan 2002 16:48:34 -0600

Hi all,

Regards,

J K Ramachandra,
IPGEN