Subject: RE: [Megaco] MGC-MG dialogue failure detection

From: Carl Rutter <[email-masked]>
Date: Fri, 12 Jul 2002 10:13:55 -0400

In Alex defense I would argue that the Secondary MGC Handoff
might be a good addition to the protocol.

I know security is the big concern on this approach but if the 
Secondary must be registered with the MG, the MG should
be password etc protected, so not just any MG could take over.
So I don't see too much down side from that aspect.
On the MGC side you might keep the HW simplier ie) Sun boxes
with no specialized HW.  If the secondary detects through 
its replication LAN that the Primary craped out he could quickly 
switch over.   This would be if you wanted seperate IP Addresses.
If you keep the same IP you wouldn't need this mechanism.

I'm in the MG domain but figured I'd give my two-cents on this.
Valid points on both sides.

Carl

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, July 11, 2002 11:13 PM
To: Aleksandr Ryabin
Cc: [email-masked]; Kevin Boyle; Carl Rutter
Subject: Re: [Megaco] MGC-MG dialogue failure detection

G'Day Aleks,

No, I still believe this is a non issue for the reasons and questions that
have
been
raised before.

Christian

Aleksandr Ryabin wrote:
> 
> Hi Christian,
> 
>          Yes it is to stop calls being dropped as well as calls already
> in progress to be processed.
> 
> Does it mean we identified the problem to be an issue in the protocol?
> 
> Thanks
>          Aleks
> 
> At 02:35 AM 7/11/2002, Christian Groves wrote:
> >G'Day Aleks,
> >
> >Please see my responses below.
> >
> >Regards, Christian
> >
> >Aleksandr Ryabin wrote:
> > >
> > > At 03:37 PM 7/10/2002, Kevin Boyle wrote:
> > > >If you are already talking about building in state synchronization,
> > then why
> > > >don't you build it hot-swap capability too?  Then this isn't a
problem.
> > >
> > > State synchronization and hot-swap are two different animals.
> > > The first can depend only on software support, while the second
> > > heavily depends on hardware support.
> > >
> > > I'd like to stress that "why not this or that" is not a question here.
> > > We are not trying to solve MGC implementation issue, but rather
> > > MEGACO protocol limitation issue.
> >
> >[CHG] Its not as easy as that. For this issue implementation and protocol
are
> >linked. Some are saying there is no problem. You (I assume) because of an
> >implementation
> >choice are saying that it is a protocol limitation issue. Before we put
> >something into the main protocol we have to understand why it is needed
and in
> >what situations. Carl has given a good explanation of his MGC/MG system
> >and what
> >call load he is managing and the fact that he has gone for a "hot swap"
> >system.
> >If the main aim of the addition is to stop calls being dropped then fine.
But
> >if the fact that call control redirection means we can't get new calls in
that
> >time then the problem is a non-issue.
> >
> >...snip..

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

---

From: Terry L Anderson <[email-masked]>
Date: Fri, 12 Jul 2002 11:19:12 -0400

Security is only one concern.  There is still the issue that MG would 
have two or more masters and cannot know who to trust.  Ideally MGC2 
doesn't try to take over unless MGC1 is failed, but detection of failure 
is never perfect (unless MGC1 and MGC2 are tightly integrated in which 
case fault-tolerant methods can work invisibly to MG) and so there is 
always the chance that MGC2 decides MGC1 has failed even though MG is 
still getting messages and responses from MGC1.  Who does MG trust if 
both MGC1 and MGC2 claim to be controlling it.

It seems reasonable to expect a protocol such as H.248 to deal with 
failure detection and recovery with times on same order as message 
retransmissions/timeouts.  This is what H.248.14 (Inactivity Timer 
Package) is intended to do.  I would argue that failure detection and 
recovery on shorter times, while desirable for some systems, should use 
a different mechanism (SCTP, fault-tolerant hardware, ...) rather than 
expect that the protocol can be modified to do this.

-- 

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:732.949.5628   Fax:732.949.7016
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2G-219A, 101 Crawfords Corner Rd, Holmdel, NJ 07733-3030
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: Terry L Anderson <[email-masked]>
Date: Fri, 12 Jul 2002 11:19:12 -0400

--

---

From: Aleksandr Ryabin <[email-masked]>
Date: Fri, 12 Jul 2002 12:48:59 -0400

Hi Terry,

         MG does not have to "trust" ether one. The requirement is to have 
only one
active/primary MGC and it is still maintained. If secondary MGC takes over
"by accident" then primary MGC can regain control right away by initiating 
handoff
on control loss detection. Since primary MGC will detect "the loss" the 
very next
time it will try to send a message to MG (which will reply with error 505) 
there will
be no service delay. State still be maintained ether by re-auditing, or 
some other
non-protocol means.

I see your point on recovery timing expectations, and I do agree with you
that it is absolutely reasonable to expect the delay.
But nobody said the current timing is perfect, and thus if possible, with
maintaining all other protocol integrity concerns, it would be very desirable
to to refine the timing in scope of the protocol. It is very natural to refine
things, that why we see new iterations of the protocol after all :)

Thanks
         Aleks

At 11:19 AM 7/12/2002, Terry L Anderson wrote:
>Security is only one concern.  There is still the issue that MG would have 
>two or more masters and cannot know who to trust.  Ideally MGC2 doesn't 
>try to take over unless MGC1 is failed, but detection of failure is never 
>perfect (unless MGC1 and MGC2 are tightly integrated in which case 
>fault-tolerant methods can work invisibly to MG) and so there is always 
>the chance that MGC2 decides MGC1 has failed even though MG is still 
>getting messages and responses from MGC1.  Who does MG trust if both MGC1 
>and MGC2 claim to be controlling it.
>
>recovery on shorter times, while desirable for some systems, should use a 
>different mechanism (SCTP, fault-tolerant hardware, ...) rather than 
>>I know security is the big concern on this approach but if the Secondary 
>>must be registered with the MG, the MG should
>>with no specialized HW.  If the secondary detects through its replication 
>>LAN that the Primary craped out he could quickly switch over.   This 
>>would be if you wanted seperate IP Addresses.

---

From: Aleksandr Ryabin <[email-masked]>
Date: Fri, 12 Jul 2002 12:48:59 -0400

Hi Terry,

Thanks
         Aleks