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

From: "Goel, Soni" <[email-masked]>
Date: Thu, 21 Feb 2002 18:53:44 -0800

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

- 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

Maria-Cruz Bartolome-Rodrigo (ECE) wrote:              (Tue, 24 Jul 2001
11:28:47)
>
> Brian,
> 
> I glanced over the mail below... I have a question,
> what is the need to have this broadcast mode? What is the
> point to process one message in all active ASPs for one AS?
> 
> You may have already talked about that in a previous 
> thread... which one?
> 
> Thanks
> /MCruz
> 

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Thursday, February 21, 2002 3:49 PM
To: Goel, Soni
Cc: [email-masked]'
Subject: Re: [Sigtran] M3UA: Broadcast traffic Mode

Goel,,

Goel, Soni wrote:                                           (Thu, 21 Feb
2002 12:52:52)
> Hi Brian,
> The question here is why Broadcast mode is required ?

Please reference the cited threads.

> I agree with you that active/standby mode is not required either but
that's
> totally different discussion. The usage of Correlation Id is also not
being
> questioned. The question is the basic need of Broadcast mode. We can't
> simply add new procedures/modes just because some other procedures/modes
> were present which were considered useless by authors themselves. 

There is no requirement in the document to support any of the three
modes.  If you don't see a need for broadcast or active/standby, I
suggest you just use/implement loadshare.

> If there is no justification for a specific mode except to address
> implementation dependent solutions, these modes shouldn't be specified in
> protocol specifications. 

All three modes address implementation dependent solutions.

> The issues discussed in draft-bidulock-sigtran-corrid-00.txt are also not
> relevant for this discussion as long as IETF doesn't approve it as an
> extension.

M3UA has not yet been approved as a proposed standard.

What would you like to see changed in the spec?  It is a little late
in the day to propose major wording changes with regard to traffic
modes which have been in the last 6 or so revisions of the draft.

--brian

> 
> - Soni
>  
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, February 20, 2002 6:53 PM
> To: Goel, Soni
> Cc: [email-masked]'
> Subject: Re: [Sigtran] M3UA: Broadcast traffic Mode
> 
> 
> Goel,
> 
> Goel, Soni wrote:                            (Wed, 20 Feb 2002 15:58:36)
> > Hi,
> > 
> > (Lyndon, this is in reference to the mail I sent to you earlier)
> > 
> > Please clarify the following -
> 
> > 1) What was the exact requirement for Broadcast mode ? 
> 
> See the thread "M2UAv0, M3UAv8, SUAv7: Traffic Mode Type" from
> July-August 2001, the thread "M3UA-07: Broadcast mode changes" from July
> 2001 and "m2ua AS broadcast mode" from July.
> 
> Also note that this question was again addressed in "m2ua v10: Broadcast
> Mode" in October.
> 
> Can you tell me what is the use of active/standby mode?  It is just 1+m
> loadsharing after all.
> 
> > Was it to prevent message loss/mis-sequencing/duplication ?
> 
> No.  draft-bidulock-sigtran-corrid-00.txt is to prevent message
> loss/mis-sequencing/duplication.  Use of Correlation Id with Broadcast
> mode is so that an ASP joining a broadcast AS knows where in the
> dataflow it is joining.
> 
> > If yes, then why not the procedures similar to MTP3 be
> > defined at M3UA using message retrieval procedures of SCTP ?
> 
> See draft-bidulock-sigtran-corrid-00.txt for a detailed answer to that
> question.  SCTP retreival is not sufficient in of itself.  Coordination
> between peers is also required and acheived in this corrid draft by
> applying similar techniques as provided for broadcast to loadshare
> and override.
> 
> > As per the procedure described in a mail in SIGTRAN mailing list
> > archive (dated 6/1/2001) for thread "M3UA: Changeover between ASPs" if
> > there are  10 ASPs for an AS in Broadcast mode, SGP will send each
> > DATA message to all the 10 ASPs.
> >
> > And the ASP  which is master of a traffic flow, will need to inform
> > (or checkpoint) 9 slave ASPs with the Correlation Id and  Stream Id of
> > each message it processed.  Such type of procedure will multiply the
> > network traffic and processing load at ASP & SGP manifold. This will
> > definitely effect the network performance and lead to a lesser
> > reliable network.  Do we really want this ?
> 
> See the last note in that thread dated Jun 5/2001.  It is the
> reponsibility of the ASP to communicate with its other ASPs using an
> unspecified implementation dependent ASP to ASP protocol concerning the
> state of the ASP's internal processing of received MSUs.
> 
> Neither the spec nor the traffic mode require any such onerous
> checkpointing.
> 
> I suggest you don't use broadcast groups of 10 if you are worried about
> network bandwidth.  See also draft-bidulock-sigtran-loadsel-00.txt for
> more reasonable scenarios.
> 
> > 
> > 2) Moreover, M3UA Draft 12 also doesn't clearly define the
> > functionality of ASP in Broadcast mode nor the usage of correlation
> > id. It leaves too many implementation dependent assumptions. Can
> > anybody who is working on this, give me some reference ?
> 
> The behavior of the SGP with regard to the ASP is clear and specified.
> ASP to ASP communication and coordination of state is outside the
> scope of the specification.  Consult the cited threads and drafts
> if you are interested in implementation-dependent considerations.
> 
> --brian
> 
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> _______________________________________________
> 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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Feb 2002 22:16:51 -0600

Goel,

Goel, Soni wrote:                                (Thu, 21 Feb 2002 18:53:44)
> Isn't the Hot standby approach required for complete synchronisation of two

No.  The note you attached below describe situations where only loose
synchornization is required.

> 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

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

---

From: "Sundaresan M" <[email-masked]>
Date: Fri, 22 Feb 2002 18:44:03 +0530

Hi,

Can anyone give me reference drafts/docs/links on IP Security Implementation
over VoIP networks.

Best Regards,
Sundar.