Subject: RE: [Sigtran] ASP load sharing..

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sat, 14 Dec 2002 14:48:45 -0800

Brian,

Well said ! Please make no assumptions about how ASPs detect failures
and how reliable ASPs are.

-mohan
> 
> Samuel,
> 
> ASP-ASP communciation an protocols are outside the scope of 
> the UAs.  This is
> particularly true because there are many architectural 
> approaches that can be
> taken between ASPs.  Certainly heartbeat is not the only (and 
> often, in my
> experience, not the best) way to indicate failure between 
> ASPs, whether they
> be processes on the same host or separate hosts.
> 
> Some examples that come to mind are synchronized 
> error-checking I/O buses (the
> typical hot-standby of switch front-ends), two out of three 
> vote (another
> typical switching front-end approach), watchdog timers, 
> atomic synchornization
> based on reliable broadcast, leader-follower, or other 
> coordinated system (bus
> level) fault detection and recovery.
> 
> The yester-year approach of two big UNIX hosts exchanging 
> application-level
> heartbeats, was infamous for its unsatisfactory failure 
> detection and recovery
> response times, normally resulting in an undesirably large 
> number of failed
> calls/transactions.  (Typical failure detection and recover 
> times on the order
> of 10 seconds, where some of the approaches above can both 
> detect and recover
> on the order of milliseconds).
> 
> However, no UA requires nor prohibits (nor should it require 
> or prohibit) any
> given approach between ASPs.  The only mention is in the requirements,
> framework and applicability documents which state that for 
> carrier class
> operation, the arrangement should not lose stable calls or 
> transactions.
> 
> This is achieved not by trying to place a requirement on the 
> ASP, but to allow
> the SGP (as the RFCs do) to place the AS in AS-PENDING state, 
> inform all
> available ASPs in the ASP-INACTIVE state for the AS, and 
> allow the inactive
> ASPs sufficient time to assume the load.  In an SS7 node, 
> time-controlled
> procedures at Level 3 are permitted 1 to 2 seconds of 
> witholding traffic in
> this manner, so it seems reasonable that a network operators 
> would set T(r) to
> some values like 1-2 seconds.  So, unless perhaps you have a 
> yester-year
> system with recovery intervals of 10 seconds, it should be 
> very easy for
> another ASP to assume the load within these kinds of 
> intervals.  If not, the
> SG will be forced to discard some traffic because the ASP is 
> the weak link in
> the chain.
> 
> Certainly a time expiry is not necessary if the detecting ASP 
> understands a
> number of things about the failing ASP and the specific ASP 
> architecuture.
> The objective here was not to have ASPs interoperating with 
> ASPs (intra-node),
> but to have ASPs interoperating with SGPs (inter-node).
> 
> --brian
> 
> 
> Samuel Dur D. Jeyaseelan wrote:                  (Sat, 14 Dec 
> 2002 00:52:50)
> > Tolga,Brian,
> > 
> > If an ASP failure has been deducted by neighbour ASP
> > with the help of Heartbeat procedure after timer
> > 2*T(beat) expiry then your new modification holds
> > good.Because after confirming the failure(timer 
> > expiry), neighbour ASP sends ASP-DONW to SG.
> > 
> > If any other method(i think no other method) which 
> > finds the ASP failure without timer expiry may not 
> > be a good method and it may cause misunderstanding 
> > between SGP and ASP.This is what i wanted to clarify.
> > 
> > -Samuel
> > 
> >   Alcatel USA, Inc.                  Internet: 
> <userid>@ssd.usa.alcatel.com
> >   1000 Coit Road, Plano, Texas 75075
> >   ******* The opinions expressed are not those of Alcatel 
> USA, Inc. *******
> > 
> > On Fri, 13 Dec 2002, Tolga Asveren wrote:
> > 
> > > Samuel,
> > > 
> > > > [samuel]
> > > > state of failed ASP is ASP_ACTIVE in SGP(because of
> > > > SGP is unaware of 
> > > > this failure).
> > > > Now neighbour ASP identifies the failure and  sends
> > > > ASP-DOWN(with failed ASP ID) to SGP.
> > > > Suppose before sending ASP_DOWN message if failed
> > > > ASP comes up and sends
> > > > ASP_UP message to SGP,  SGP also sends (as per
> > > > section 4.3.4.1 of sua)
> > > > ASP Up Ack and ERROR message with "Unexpected
> > > > Message" and ASP state is
> > > > changed to ASP_INACTIVE in all relevant Application
> > > > Servers.
> > > [TOLGA] When the failed ASP comes up, first it should
> > > establish the SCTP association. This will put ASP to
> > > DOWN state on SG.
> > > > 
> > > > Now SGP receives ASP-DOWN(with failed ASPID) from
> > > > neighbour ASP in
> > > > ASP_ACTIVE state and state will be changed to
> > > > ASP_DOWN at SGP.
> > > > 
> > > > So at SGP -> failed ASP(but now in-service) is in
> > > > ASP_DOWN
> > > >    at ASP -> failed ASP(but now in-service) is in
> > > > ASP_INACT
> > > >    
> > > >    
> > > >  Obviously ASP will try to send ASP-ACT to SGP but
> > > > SGP is in ASP_DOWN
> > > >  state, so Will it reject the message ? and What
> > > > will happen to this
> > > >  ASP ?
> > > [TOLGA] Such a race condition might happen, but IMO
> > > quite unlikely. I would expect SG to tear down SCTP
> > > association to the ASP, after receiving ASPDN for it
> > > from another ASP. So, eventually even for the scenario
> > > you mentionm, ASP will be aware that SCTP association
> > > is lost and will try to reestablish it.
> > > 
> > > 
> > > 
> > > __________________________________________________
> > > Do you Yahoo!?
> > > Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> > > http://mailplus.yahoo.com
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > 
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 14 Dec 2002 16:04:49 -0700

Mohan,

Mohan Parthasarathy wrote:                  (Sat, 14 Dec 2002 14:48:45)
> and how reliable ASPs are.

I'm permitted to make all the assumptions I want.  The RFC doesn't, so there
is no problem there.  Besides, I wasn't making assumptions about the ASPs
absolute reliability, I was making statements about the ASPs reliability in
comparison to the SG.

Considering that SG are SS7 connected, they must meet operator reliability
requirements imposed on SS7 signalling equipment.  This is rather strict in
public SS7 networks: (e.g. 6 nines instead of just 5 for most STPs).

One of the major purpose of traffic modes in the UA is to allow lesser
reliable ASPs to joint together in a system in such a way that the system is
more reliable than its components.

Because in public networks switches and databases only have to meet 5 nines
(not the 6 of STPs), it would be bad engineering and a waste of money to
engineer the ASP to the level of reliability of the SG/STP.  Even if the SG is
not an STP, but an SEP (5 nines as well), engineering the individual ASPs to 5
nines and then combining them using UA traffic modes is also a waste.

So, expecting that engineers will honestly do their job and not throw cost
into the ASP where it is not necessary, it is safe to say that the ASP as a
component is less reliable than the SG as an SS7 node.

Can you give an example in a real network where an SG would be allowed to not
meet the reliability requirements of SS7 (and yet be SS7 connected) and where
the ASP has been so over-engineered that it exceeds the SG reliability? ;)

--brian