Subject: RE: [MEGACO] Question on failover

From: "Kaul, Bharat" <[email-masked]>
Date: Wed, 15 Aug 2001 11:04:03 -0700

Terry,

  In all this we are making an assumption that that the new MGC knows "what
that retransmitted transaction" is ? And I don't think that is the right
assumption to make and standards also don't imply what you suggested.

First of the all the paragraph that you pointed Steven to is meant for
"Handoff"...The paragraph begins with "No recommendation is made on how MGCs
involved in HANDOFF maintain state information....." and not for "failover"
as you suggested.

So, the MGs are provisioned with the list of MGCs doesn't imply MGC's share
the state information about MGs.

- Bharat

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Wednesday, August 15, 2001 10:21 AM
To: Steven Weisz
Cc: [email-masked]'
Subject: Re: [MEGACO] Question on failover

NO.  Not to the failing MGC.  The quote says to the NEW MGC (after control
association establishment).  Are you assuming the need to keep sending to
the
failing MGC because of the delay in control association establishment?

Admittedly the quote is in a paragraph dealing with MGC directed handoff
rather
than detected failure, but in the absence of another statement I assume the
same principle should apply to failure.

Failure detection may have occurred due to reaching max number of
retransmissions.  Then clearly one would not retransmit to failed MGC, but
could "start over" (reset transmission counter to 0) and send the
transaction
to the new MGC after control association establishment.

Though H.248 does not indicate all the ways an MG could detect failure,
presumably MGs may be capable of detecting some failures without reaching
the
retransmission count max (e.g., ICMP errors, etc.).  In these cases it
futile
to continue retransmitting to the failed MGC while establishing the control
association with the new MGC but even if one did, the exponential backoff
timer
described in D.1.5 would would minimize the number of retransmissions before
the new control association is established.

Steven Weisz wrote:

> So this is an implicit requirement stating that we continue sending the
> transaction to the current (i.e. failing) MGC. Is it also implicit that we
> reset the retransmission count of the offending transaction to 0 or do we
> continue to increment. Keep in mind that it won't be long before we hit
the
> disconnect threshold discussed in D.1.5
>
> Thanks,
>
> Steve
>
> -----Original Message-----
> From: Terry L Anderson [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2001 12:43 PM
> To: Steven Weisz
> Cc: [email-masked]'
> Subject: Re: [MEGACO] Question on failover
>
> Steven Weisz wrote:
>
> > Hi List,
> >
> > I need a little clarification on section 11.5 of RFC 3015, it states:
> >
> >     "If the MG detects a failure of its controlling MGC, it attempts to
> >    contact the next MGC on its pre-provisioned list.  It starts its
> >    attempts at the beginning (Primary MGC), unless that was the MGC that
> >    failed, in which case it starts at its first Secondary MGC.  It sends
> >    a ServiceChange message with a "Failover" method and a " MGC
> >    Impending Failure" reason."
> >
> > In this statement it seems clear that a Service Change Message  with
> > "Failover" method and a "MGC Impending Failure" reason, however, what do
> we
> > do with the transaction that caused us to notice this? Do we now attempt
> to
> > send it also to the next provisioned MGC or do we continue to send it to
> the
> > current MGC?
>
> Read a little further in 11.5 and you will find.
> "Repeated transaction requests shall be directed to the new MGC...."
> This is after you have established the new control association as stated
in
> the
> sentence previous to my quote.
>
> >
> >
> > Thanks,
> >
> > Steven Weisz
> >
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/megaco
>
> --
> Waiting for the other shoe to drop but hoping its a one legged man.
> ------------------------------------------------------------
> Terry L Anderson              mailto:[email-masked]
> Tel:908.582.7013   Fax:908.582.6729
> Lucent Technologies/INS/Voice Over IP Access Networks
> Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
> http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

--
Waiting for the other shoe to drop but hoping its a one legged man.
------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

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

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 15 Aug 2001 14:44:22 -0400

> assumption to make and standards also don't imply what you suggested.

I don't think that the original MGC knows "what a retransmitted transaction" is,
other than it is a transaction.  A common reason for retransmission is that the
original was not received.  There is nothing in it that says it is a
"retransmitted" transaction.  Both the original MGC and a secondary MGC would
simply process the transaction (unless it matched a transactionid already
processed).  I don't see the problem.

> involved in HANDOFF maintain state information....." and not for "failover"

I agree that much of the paragraph applies only to handoff.  I am simply
suggesting that without any other statement to the contrary, parts that fit the
"failure" scenario might still be used.  I have no problem with a change to
clarify this after we all agree.

> the state information about MGs.

Agreed. But shared state is not needed.