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

From: "Goel, Soni" <[email-masked]>
Date: Tue, 26 Feb 2002 11:48:38 -0800

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

---

From: "Nitin Vairagare" <[email-masked]>
Date: Tue, 26 Feb 2002 15:10:05 -0500

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,

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 26 Feb 2002 16:53:11 -0600

Nitin,

There is no need to remove an OPTIONAL feature.  Particularly
at this stage.  If your implementation (or network) cannot
support Broadcast mode, don't use it.  Broadcast use and
advantages have been expounded on this list for over a year
now.

There would be no more use in removing Broadcast at this point
than there would be removing Override (which is just 1+1 loadshare).

Striping and Mirroring are valid engineering approaches.  Loadshare
and Broadcast are equally valid.

Do you have a technical argument why Broadcast is not usable?

--brian

Nitin Vairagare wrote:                                      (Tue, 26 Feb 2002 15:10:05)

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

---

From: "Nitin Vairagare" <[email-masked]>
Date: Wed, 27 Feb 2002 11:22:51 -0500

Brian,

Its really *NOT* important if any particular implementation or network
supports optional feature or not. It's more of a protocol design.

We really need to determine what is this protocol intended for and
what are primary objectives of this protocol.

Using Broadcast method is not of any use unless there is ASP-ASP
communication, which this protocol doesn't define. And it was not
objective of this Protocol to go in that direction as well.  It is
up to userpart or application for that matter to share state
information.

Right now main issues we have with this method is too many implementation
dependencies and there by interoperability issues. When implementation
dependencies are bound to single host or internal to node, it doesn't
matter. But when you are excahnging messages on publicly deployed
networks (naturally with different vendor implementation) without clearly
defined procedures, this can lead to chaos and loss of data. In such cases
either you define procedures completly or don't do it.

Further I don't see its job of adaptation layer to synchronise state of
user parts, if that is the main objective of the broadcast.

Thanks,
Nitin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian F. G. Bidulock
Sent: Tuesday, February 26, 2002 5:53 PM
To: Nitin Vairagare
Cc: Goel, Soni; [email-masked]
Subject: Re: [Sigtran] M3UA: Broadcast traffic Mode

Nitin,

--brian

Nitin Vairagare wrote:                                      (Tue, 26 Feb
2002 15:10:05)
> > > List-Unsubscribe:
<mailto:[email-masked]>

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 27 Feb 2002 16:15:32 -0600

Nitin,

It has been assumed from the start that ASP-ASP communication
is necessary in all traffic modes.  All traffic modes can get
away without ASP-ASP communication if you want to get lost and
hung state.  All traffic modes have some requirement for
ASP-ASP comunication.  Someone even put a draft forward
suggesting a protocol for ASP-ASP communication.

The need for or lack of a need for ASP-ASP communication has
no bearing on the use of broadcast mode.  As for override and
loadshare, ASP-ASP communication is implementation dependent.

I suggest that you look at current references on reliable
distributed computing algorithms.  Your choices are: leader-
follower or broadcast.  Both override and loadshare are
leader-follower algorithms.  To synchronize state, the AS
receiving the message must communicate state changes also to
the AS not receiving the message.  This requires a lot of
protocol between ASPs for an AS.  Broadcast obliviates the
need for leader-follower ASP-ASP protocols by simply sending
the message to all ASPs in the AS.  Then it is up to the AS to
determine the need and level of synchronization required. 

Broadcast at the ASP can work identical to load-share, where
the ASP is in control of which load selection it is
processing.

In the simple case of two ASPs for an AS, one ASP processes
half the offered traffic and the other processes the other
half.  If an ASP receives a NTFY("ASP Failure") from the SGP
indicating that the other ASP has failed, it can begin
processing the entire traffic load instead of just half.  This
can being immediately.  There is no delay due to switchover.
No missequencing of messages can occur in a fail-over.  No
change has occured to the message load offered the host.  No
cascading failures can occur due to congestive fail-over.  In
this simple example, the ASPs need not even communicate with
each other (the SGP sends them the NTFY).

So. There is the trivial example not requiring ASP-ASP
communication for broadcast mode, with a plethora of
advantages over loadshare.

I trust that with this simple example, you can see that the
statements you have made about broadcast mode below are false.

Please see also commments below...

Nitin Vairagare wrote:                                      (Wed, 27 Feb 2002 11:22:51)
> communication, which this protocol doesn't define.

False.

> And it was not objective of this Protocol to go in that
> direction as well.

False.

> It is up to userpart or application for that matter to share
> state information.

The spec does not specifiy where state information is to be
synchronized.  Broadcast mode does not require you to do it
here or there.

> dependencies and there by interoperability issues.

What are the interoperability issues?  I have seen none
mentioned.

> When implementation
> matter.

Handling of fail-over *between* hosts is implementation
dependent for override and loadshare as well...

<skip motherhood>
> But when you are excahnging messages on publicly deployed
</skip motherhood>

> user parts, if that is the main objective of the broadcast.

False.   That is not the main objective of broadcast.

--brian

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