Subject: RE: [Sigtran] M3UA: Broadcast traffic Mode

From: "Vats, Umesh" <[email-masked]>
Date: Tue, 26 Feb 2002 14:53:25 -0800

I agree with the removal of broadcast mode from the
M3UA draft. Infact, the only useful Traffic Handling Mode
appears to be LOADSHARE. 

I don't see much use of Override mode Either.  Some thing 
like Overide mode can be implemented in loadshare mode itself 
with just 1 out of N ASPs going active for an AS. 
To handle the case where all traffic for an AS is to be routed 
to another  ASP, the new ASP should send ASP Active message to SGP 
wherease the currently Active ASP should send ASP Inactive message
to SGP.

The M3UA draft should clarify the procedures for handling failover
scenarios in LOADSHARE mode.

Umesh 

-----Original Message-----
From: Nitin Vairagare [mailto:[email-masked]]
Sent: Tuesday, February 26, 2002 12:10 PM
To: Goel, Soni; [email-masked]
Subject: RE: [Sigtran] M3UA: Broadcast traffic Mode

Soni,

I would Agree on this..

What Broadcast method achieves can achieved by redundant distributed
applications (userparts here). Draft already specifies ASP-ASP
redundancy and communication is out of scope of this document.
Then why again user part state synchronisation (application level logic)
be incorporated in this draft???

I would vote in favour of removing Bradcast Traffic mode. It
would definitely remove too many implementation dependencies,
which is putting interoperability of protocol in suspicion.

Regards,
Nitin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Goel, Soni
Sent: Tuesday, February 26, 2002 2:49 PM
To: [email-masked]'
Subject: RE: [Sigtran] M3UA: Broadcast traffic Mode

Hi All,

>From all the discussions in this thread for Broadcast mode usage, it is
clear that Broadcast mode tries to achieve minimal loss of input events as
compared to the network traffic it multiples and too many open
issues/complications at SGP/ASP which are termed to be implementation
dependent. Therefore the Broadcast mode should be removed from the M3UA
draft.

It is also suggested that before adding any feature in a protocol
specification its implications, drawbacks and advantages should be carefully
considered. It should not only be based on personal implementation
requirements.

- Soni

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Friday, February 22, 2002 9:02 PM
To: Goel, Soni
Cc: [email-masked]'
Subject: Re: [Sigtran] M3UA: Broadcast traffic Mode

Goel,,

Both ASPs process each message to loosely sychronize state.  Only
the response from one ASP is acrually returned, the response from
the other is discarded before it is sent.

Because both ASPs have the same inputs events, they are in the same
state but loosely synchronized.

The only communication necessary between the ASPs is a periodic
heartbeat to determine if the other ASP is alive.  If an ASP fails,
the output events for all messages are sent from the remaining ASPs.

A few output events might be lost, but far less than the input events
that would be lost in an active/standby or loadshare failover.

This is a cost-effective way to acheive high reliability at a distance
using loose coupling but resulting anyway close syncrhonization.

--brian

Goel, Soni wrote:                                    (Fri, 22 Feb 2002
13:07:40)
> Hi Brian,
>
> This means Broadcast mode is required only for loose synchronization of
> ASPs.
> It seems from this mail that a master ASP (Suppose ASP1) will receive DATA
> messages and send MTP-TRANSFER indication to M3UA user.
> While the slave ASP (Suppose ASP2) will receive DATA messages and discard
> them.
> This means that the M3UA User of ASP2 is not synchronized with the present
> state of M3UA User of ASP1 (i.e. they are not tightly synchronized)
> Now SGP sends a DATA message to both ASP1 and ASP2.
> M3UA User at ASP1 processed this DATA message and reached a state X.
> Since the M3UA User at ASP2 has not been processing any messages,
therefore
> it is in its initial state.
> Suppose now the association of ASP1 with SGP went down.
> Now how do you expect that the M3UA user at ASP2 can straightaway start
> processing further messages sent by SGP when it is still in its initial
> state ?
>
> - Soni
>
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, February 21, 2002 8:17 PM
> To: Goel, Soni
> Cc: [email-masked]'
> Subject: Re: [Sigtran] M3UA: Broadcast traffic Mode
>
>
> Goel,
>
>
> Goel, Soni wrote:                                (Thu, 21 Feb 2002
18:53:44)
> > Hi Brian,
> >
> > This is in reference to the threads you listed.
> > I am attaching a mail from archive which talks about the usage of
> Broadcast
> > mode.
> >
> > As per this mail Broadcast mode supports a Hot standby approach at ASPs.
> > Isn't the Hot standby approach required for complete synchronisation of
> two
> > entities ?
>
> No.  The note you attached below describe situations where only loose
> synchornization is required.
>
> > If yes, then does it mean that M3UA Users at 2 ASPs acting in Broadcast
> mode
> > should be completely synchronised ?
> > If yes, then the slave ASP should also send MTP-TRANSFER indications to
> keep
> > the M3UA user completely synchronised.
> > But this means it will need to respond back to this DATA message and
thus
> > all the ASPs will be responding back to the same DATA message. Am I
> > missing/adding something ?
>
> I think you are missing that broadcast does not mean that any tighter
> sychronization is required that is required in loadshare.  Losdshare
> merely requires the SGP to do complicated switchovers for which both
> SCTP and M3UA are poorly suited; broadcast mode does not.
>
> --brian
>
> >
> > - Soni
> >
> > Date: Tue, 24 Jul 2001 05:29:26 -0500
> > From: "Brian F. G. Bidulock" <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Subject: Re: M3UA-07: Broadcast mode changes
> > Reply-To: [email-masked]
> > User-Agent: Mutt/1.2i
> > Organization: http://www.openss7.org/
> > Dsn-Notification-To: <[email-masked]>
> > X-SMTP-HELO: bfgbhome.inetint.com
> > X-SMTP-MAIL-FROM: [email-masked]
> > X-SMTP-RCPT-TO: [email-masked]
> > X-SMTP-PEER-INFO: [209.44.42.202]
> > X-Orig: <[email-masked]>
> > X-Orig: <[email-masked]>
> > X-Orig: <[email-masked]>
> > List-Unsubscribe: <mailto:[email-masked]>
> >
> > Maria,
> >
> > It was discussed briefly in two threads (grep for "broadcast" and
"Traffic
> > Modes").
> >
> > The purpose of broadcast mode is to permit the a pool of ASPs to run
fully
> > synchronized and Hot Standby.
> >
> > The leader-follower synchronization afforded by override and load-share
> are
> > what I would call "Warm" Standby.
> >
> > It also permits a loosely coupled synchronization for applications where
> > precise state syncrhonization between ASPs is neither necessary nor
> > economical.
> >
> > The purpose of adding it was to support these modes, and because the UAs
> do
> > not permit any implementation-defined traffic modes.
> >
> > Broadcasting could be accomplished between the ASPs instead; however,
> > broadcasting at the SG handles the situation (it is more efficient)
where
> > ASPs are geographically diverse, particularly where loose
synchronization
> is
> > permitted by the application.
> >
> > Most SS7 applications (ISUP, TCAP) are robust against duplication and
> > ommission errors, permitting loose synchronization.
> >
> > Consider that one ASP is in Madrid and the other is in Dallas.
> > It is efficient if the SGP sends messages to both and the ASPs
coordinate
> on
> > who is actively processing which messages (although both process each,
> only
> > one reacts).  Say, one ASP is master for one traffic flow and the other
is
> > slave.  Visa versa for other traffic flows.  When an ASP is informed of
> the
> > failure of the other, it starts active processing of slave messages.
> > This is just one possible arrangement with broadcast mode.
> >
> > Certainly the SGP performs this simple little broadcast function and a
> wide
> > spectrum of redundancy arrangements become possible at the ASP.
> >
> > Certainly the SCTP assocations permit the SGP to perform a time-bounded
> > reliable broadcast: the basis for all distributed atomic locking
> protocols.
> > Even hard and tight synchronization is possible.  ASPs can use a
> symmetrical
> > voting algorithm and better address babbling idiot and psychotic sister
> > syndromes.
> >
> > For example the common 3 out of 4 voting performed between fault
tolerant
> > processor quads is possible in a more distributed architecture.
> >
> > These symmetrical voting algorithms depend upon the fact that there is
no
> > one member of the vote who is responsible for calling for the vote
('cuase
> > if that guy failed, so would the whole voting process).  Implementing
them
> > is easier when the incoming messages are broadcast over a bus (or
> network).
> >
> > Is that enough detail?  (Or, should I draw diagrams...  ;)
> >
> > --Brian
> >
>
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/

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

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

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 26 Feb 2002 15:11:45 -0800

Folks,

Remember, if no one (or only one) implements a feature
it will be taken out as the protocol evolves from
Proposed to Draft.

Cheers,

L. Ong

-----Original Message-----
From: Vats, Umesh [mailto:[email-masked]]
Sent: Tuesday, February 26, 2002 2:53 PM
To: [email-masked]
Subject: RE: [Sigtran] M3UA: Broadcast traffic Mode

Umesh 

-----Original Message-----
From: Nitin Vairagare [mailto:[email-masked]]
Sent: Tuesday, February 26, 2002 12:10 PM
To: Goel, Soni; [email-masked]
Subject: RE: [Sigtran] M3UA: Broadcast traffic Mode

Soni,

I would Agree on this..

Regards,
Nitin

-----Original Message-----

Hi All,

- Soni

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Friday, February 22, 2002 9:02 PM
To: Goel, Soni
Cc: [email-masked]'
Subject: Re: [Sigtran] M3UA: Broadcast traffic Mode

Goel,,

--brian

therefore
18:53:44)
thus
"Traffic
fully
where
synchronization
coordinate
is
tolerant
no
('cuase
them

--
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/