Subject: AW: reqs - failover support

From: Ross Christopher ICM CA MS MI E 7 <[email-masked]>
Date: Tue, 30 Jan 2001 10:27:42 +0100

Dear Qiaobing,

thank you for your reply, I think the crucial issue with failover discovery
is time. If in our example (see below) the PU asks failed PE1 to tear down
the call and waits 30 seconds for a time-out before asking PE2, this won't
be
good enough.

Is it difficult / does it make sense (scaleability) for the ENRP server to
communicate PE1's failure to the PU?

Or is there an option for the PU to switch to PE2 without the application in

the PU having to wait for too long, maybe using the information of some
auditing mechanism (this seems rather complicated, not in line with the req
-
suitable for small devices-, and is a funtionality which is aready located
at
the ENRP server).

regards,

Chris

> -----Ursprungliche Nachricht-----
> Von: Qiaobing Xie [mailto:[email-masked]]
> Gesendet: Freitag, 26. Januar 2001 22:22
> An: [email-masked]
> Betreff: Re: reqs - failover support
>
>
> Christopher Ross wrote:
> >
> > Dear all,
> >
> > I've been thinking about how a failover would work when
> first detected
> > by the ENRP server.
> >
> > I'm considering an example where we have two PEs, PE1 and PE2, which
> > somehow share state, and a PU requesting a service, starting up with
> > using PE1. The application I have in mind is handling of (voice)
> > calls, to keep things simple. So the PU uses PE1 to set up
> a call, and
> > call state is held at PE1, and by some means exchanged with PE2.
> > Assuming that the call reaches the state "talk" and soon after PE1
> > fails, what happens next? If we have no communication between the
> > server pool and the PU during the call in state "talk", we
> really need
> > the ENRP server to tell the PU to use PE2 to when PU wants to tear
> > down his call, rather than having the PU find out the hard way.
>
> The key is that the PU (to be exact, the A-SAP layer in the PU) knows
> both PE1 and PE2 from its first ENRP query. When the PU tries to tear
> down the call and finds PE1 is unreachable, it already has PE2 in its
> local cache and only needs to simply redirect the "tear down"
> message to
> PE2. And since PE2 is sharing state and hence knows the call, it will
> perform the tear down correctly.
>
> -Qiaobing
>
> >
> > As far as I can make out, in the example 2.5.1 (see stage
> 12) it's the
> > PU who discovers the failure of PE(1,A), and who then
> switches over to
> > PE(1,B). This makes sense for the FTP example, but not in
> the case of
> > a failure during a stable call.
> >
> > Has the communication from the ENRP server to the PU been
> catered for?
> >
> > Thanks
> >
> > Chris
>

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 30 Jan 2001 14:36:52 -0600

Chris,

See my comments interspersed...

regards,
-Qiaobing

Ross Christopher ICM CA MS MI E 7 wrote:
> be good enough.

Yes, the failure detection latency will be a major factor when
fine-tuning the system for a specific application. In the case of call
control, you definitely want to have a detection latency shorter than 30
sec. This latency is adjustable via the timer and retransmission
threshold control in SCTP.

However, one must keep in mind that it is always a trade-off between
faster failover to alternate server and the probability of false failure
detection.

> communicate PE1's failure to the PU?

Yes, scalability is certainly a concern if we want to make ENRP to
actively communicate to the PU upon the detection of the failure,
because the ENRP server does not know which PU is interested in PE2's
status.

ENRP already has the mechanism to detection the failure of PE1 by itself
(of cause there will also be a detection latency), but it won't "push"
the information to the PU, instead it waits the PU's next query to pass
the information to PU.

> at the ENRP server).

The key is still the latency due to that the auditing mechanism
(whatever it is) will normally only be executed once a while (actually
in a certain sense, the A-SAP PU is already doing auditing (sort of) by
aging out old query results).

---

From: "Randall R. Stewart" <[email-masked]>
Date: Wed, 31 Jan 2001 14:00:50 -0600

Q:

Seems to me you covered everything... but just
to show everyone I have not fallen off the planet (it
seems like it here lately :->) I will add just a few words.

> faster failover to alternate server and the probability of false failure

This trade-off is absolutely the case.. and a key issue. Now as to
adjusting SCTP timers... in a private Intra-Net it does not matter.
In a public Inter-Net then this really should not be messed with, but
instead shorten the max.retransmissions. This can still provide
a quicker detection of failure ... but of course involves the
same trade-off issues :)

> the information to the PU, instead it waits the PU's next query to pass

I know you and I looked at this item long ago when we first laid
out and played with ENRP/ASAP. And I think we are both in
violent agreement that the amount of state that an ENRP deamon
would need to hold in order to do this is completely un-scalable.
Worse, you get all sorts of state-synchronization issues since
the ENRP deamons themselves need to be fault tolerant.

- If I have this info, how do I replicate it?
- If I replicate, who is the one that needs to tell the PU the
  problem, all? just the parent?

It becomes a real nightmare :)

> aging out old query results).

Exactly, the ENRP server does do some very slow auditing but it
also depends on the A-SAP PU's to give reports about un-reachability
to "call attention to" a possible faulty PE..

R

--
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)