Subject: RE: [MEGACO] Question on failover

From: "Kaul, Bharat" <[email-masked]>
Date: Wed, 15 Aug 2001 12:09:06 -0700

Terry, 

Logically I understand your point of new MGC not knowing it is
retransmission and in real world it is quite possible that while MGC is
auditing, MG sends a command to MGC.

Where I am trying to differentiate from you is that MG should not remember
that this particular transaction was related to primary MGC that failed and
ditto for responses it needed to send to primary MGC.

I guess my concern boils down to "What to do with responses that needed to
be sent out to primary MGC" ? Infact I had raised the same concern sometime
earlier also and never really got a answer. 

- Bharat

P.S. It is high time we start evaluating control associations...this area is
quite murky.

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

"Kaul, Bharat" wrote:

> 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.

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.

> 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.

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.

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

Agreed. But shared state is not needed.

>
>
> - 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

--
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: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 23 Aug 2001 10:22:34 -0400

I'll jump in here, hoping this isn't covered later in the thread.  Steven
raises the very appropriate question of what to do with the retransmission
counter for an outstanding transaction after a change in control.  It seems
reasonable that we add something to say it is reset to 0 for the new MGC.

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

Steven Weisz wrote:

> First off Terry thanks for taking the time to help me out. However, I
think
> the confusion lies in what is meant by "Failover" and "Disconnected".

see below.

> > association establishment).  Are you assuming the need to
> > keep sending to the
> This section is easily understood and I have no problems with it but it
> occurs after we
> have established a new association. What I'm asking about is what goes on
> between the time we "suspect" a failing MGC and the establishement of a
new
> association. The question is, what do we do with that pesky transaction
that
> led us to believe the MGC is failing. We can't get rid of it because we
only
> "suspect" a failure. Yet we can't send it to one of the provisioned
> secondary MGC because a connection has not yet been established. Should we
> just suspend it?
>
> > 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
> > could "start over" (reset transmission counter to 0) and send
> > the transaction
> In my understanding of the protocol when the max number of retransmissions
> has taken place we enter the disconnect procedure. Before that time we
will
> be in the failover procedure which seems to state, in lay mans terms,
"From
> you provision list of secondary MGC's, try to establish a connection, so
> that you can send this pesky transaction there".

First of all, there are a lot of gray areas in the association states and
there
is a draft to appear soon that tries to be precise about association states
and
transitions.  After this is discussed and agreed to, we need to change the
several spots in H.248 that relate to this to remove the ambiguities.

"disconnect" and "failover" are not procedures but ServiceChange Methods.
There
was a recent clarification (discussed on the list and to appear in the next
release of the IG) to the first paragraph of 11.5 to make it clear that in
the
Failure procedure, an attempt to establish an association with a different
MGC
(from the pre-provisioned list) ServiceChange is sent with method
="failover",
but if an attempt is made to re-establish the association with the original
MGC
(either because there is no list of secondaries or because one has tried all
of
them and is not re-trying the original), that ServiceChange is sent with
method
= "disconnected".  Both of these are part of a single procedure outlined in
11.5.  11.5 also discusses an MGC directed change using method = "handoff",
which is not necessarily due to a failure.

The 11.5 failure procedure (register with a secondary or re-register with
original) will be invoked after a "failure" is detected.  This may be by
exceeding the max retransmissions (D.1.5) or some other means (eg, ICMP
error,
loss of connection in TCP, etc.)

> > 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
> Ths problem I'm still faced with is trying to give the failover procedure
a
> chance to establish a new connection before my "pesky" transaction sets
off
> the disconnect procedure, since at that time it will be deleted.

again, I don't think that there are two "procedures" and there is no reason
to
"delete" a transaction when failure is detected - MG simply sends the
transaction to the new MGC after registering.

> Thanks again,