Subject: Re: [Sigtran] Re: M3UA Notify message

From: "TOLGA ASVEREN" <[email-masked]>
Date: Wed, 26 Feb 2003 07:51:30 +0200

Brian,
> Tolga,
>
> Tolga Asveren wrote:
>                                 (Tue, 25 Feb 2003
> 13:02:20)
> > Brian,
> > --- "Brian F. G. Bidulock" <[email-masked]>
> > wrote:
> > > Tolga,
> > >
> > > Tolga Asveren wrote:
>
> > >                                 (Tue, 25 Feb
> 2003
> > > 12:15:22)
> > > > Brian,
> > > >
> > > > [..snip..]
> > > >
> > > > > For example n=5. SG decides to start traffic
> > > with
> > > > >the 2nd ACTIVE ASP.
> > > > >But
> > > > > according to RFC ASPs will wait for the 5th
> > > ACTIVE
> > > > >ASP before
> > > > >starting
> > > > > traffic. In my opinion, this is a problem.
> > > >
> > > > There is no problem.  The ASPs should wait for
> the
> > > 5th
> > > > ASP to be active
> > > > before
> > > > starting traffic regardless of when the SG
> starts
> > > > traffic.
> > > > [TOLGA]O.K. finally there we are, the source
> of
> > > the
> > > > disagreement. IMO, it is not a good idea to
> > > open/close
> > > > the traffic path between ASP/SGP
> unidirectionaly.
> > >
> > > Nowhere does it say that the traffic path need
> be
> > > opened or closed unidirectionally.  The RFC
> talks
> > > about
> > > the "start" of traffic, not the establishment of
> > > unidirectional flows.
> > [TOLGA]IMO, the path between ASP/SGP will be
> opened
> > unidirectionslly, if ASPs will wait for n of them
> to
> > be ACTIVE whereas SG decides to not withhold
> traffic
> > when number of ACTIVE ASPs is less than n.
>
> | For the n+k redundancy case, ASPs which are in
> that AS should
> | coordianate amoung themselves the number of active
> ASPs in the AS, and
> | should start sending traffic only after n ASPs are
> active.
>
> This does not say that the ASP should not respond to
> traffic
> delivered to it by the SG: it says that the ASP
> should not
> "start" sending traffic.
>
> It is just saying that the ASPs should coordinate
> going into
> service and shouldn't start sending traffic until
> they are
> capable of handling the expected load (and they
> shouldn't).
[TOLGA]What is the reason behind allowing ASP to respond to messages from
SG but not starting traffic? How does ASP-M3UA know whether a message
coming from user parts is a response or newly initiated traffic(whatever
the definition of newly initiated traffic is)? If SG decides that there are
enough number of ACTIVE ASPs, why should we prevent ASPs to initiate
traffic?
BTW, I proposed that text to the RFC and I never thougth that somebody can
interprete the word "start" like you do. If you are really uncomfortable
and think that the sentence is not clear, will changing "traffic" to
"messages" make the ambiguity disappear?
>
> > >
> > > > And secondly, if you prefer SG to decide
> > > dynamically
> > > > to start traffic, why do you want ASPs to
> decide
> > > for
> > > > this statically by interpreting n as
> mandatory?
> > >
> > > The SG is neither required nor prohibited by the
> RFC
> > > to
> > > decide dynamically.  Nor is the ASP required to
> > > decide
> > > statically.
> > [TOLGA]For SG part I agree.But for ASP I disagree,
> RFC
> > says that ASPs SHOULD not start traffic before n
> of
> > them are ACTIVE, and this n is a static attribute.
> If
> > ASPs rely on NTFY for this, starting traffic will
> be
> > decided by SG and will be decided dynamically (or
> > better said by SG, which can base this decision
> also
> > to the configured value n statically, this IMO is
> > totally responsibility of SG)
>
> You are making many assuptions, most of which are
> not valid.
> The SG does not "start" traffic because there is no
> stimulus
> at the SG: the stimulus is either at the ASP or in
> the SS7
> network.  All the SG can do is decide to "direct"
> traffic.
> That does not mean that traffic actually exists, or
> that it
> will exist any time in the near future after.
>
> This is not a switch that you throw and current
> starts flowing.
[TOLGA]I think several times I explained what I mean with "SG starting
traffic", but O.K. I will use "directing", it is more clear, but doesn't
change too much from this discussion point of view IMO.
>
>
> > >
> > > The RFC permits the SG to do what it needs to do
> > > with
> > > regards to the SS7 network because of the "MAY".
> > [TOLGA]The MAY is about withholding traffic to ASP
> > destination. I don't interprete it directly
> related
> > with interaction of SG with SS7 network.
>
> But it is directly related to the SS7 network and
> that was
> the reason for the MAY.  This is an AS which is
> newly active:
> not an AS recovering from AS-PENDING.  Regardless of
> the
> granularity of the RK, the SG has performed
> necessary management
> functions towards the SS7 network with regards to
> the AS.
> This could be UPU response, TFC response, or even
> TFP response
> if the SG is acting as STP.  Directing traffic back
> to the
> ASP for the AS requires that something be done to
> undo whatever
> was told to the SS7 network.
[TOLGA] Of course SG will execute necessary SS7 procedures. And if you
interprete it as undoing something told to SS7 network, I think SG should
do this, whenever it decides that there are enough number of ACTIVE ASPs.
>
> As the SG's primary purpose in life is to transer
> traffic between
> ASPs and the SS7 network, what did you think the SG
> was going to
> do to "direct" traffic if it is not going to
> interact with the
> SS7 network to do so?
[TOLGA]I didn't say that SG won't interact with SS7 network. But the word
"MAY" about withholding traffic is mainly related for communication between
SGP/ASP.
BTW, before SG decides that AS can be considered ACTIVE, it won't execute
necessary SS7 procedures. So, where does the traffic, SG needs to withhold
comes from? So, I would think, this withholding traffic will be meaningfull
only for PENDING case(?).
>
>
> > >
> > > The RFC recommends that the ASPs wait until "n"
> > > because
> > > they SHOULD.
> > [TOLGA]So it is static according to RFC.
>
> Where does it say static?  It says "coordinate"
> which sounds
> pretty dynamic to me.
[TOLGA]Because it relies on the statically configured value n. IMO, only SG
can decide dynamically, when to open the communication path between
ASP/SGP. And for that we need to make ASPs to decide based on received NTFY
from SG, not to count number of ACTIVE ASPs by themselves.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 26 Feb 2003 02:58:37 -0700

TOLGA,

All in all nothing has changed from the original discussions:

o   The ASP should coordinate with other ASPs the number of active ASPs.

o   An ASP should not start traffic until sufficient ASPs are active.

o   The SG may choose not to direct traffic to an ASP until sufficient ASPs
    are active.

o   The SG should withhold NTFY(AS_Active) until it does direct traffic.

This is just as it is in the RFC.

--brian

TOLGA ASVEREN wrote:                                                                 (Wed, 26 Feb 2003 07:51:30)
> SG but not starting traffic?

When the stimulus is at the ASP, this provides for more graceful recovery
regardless of what the SG does or does not do.

But the ASP need not respond.  There is no requirement to respond and no
requirement not to respond.  The ASP designer could chose to discard messages,
buffer them, or activate the local MTP User and deliver them.

> How does ASP-M3UA know whether a message coming from user parts is a
> response or newly initiated traffic(whatever the definition of newly
> initiated traffic is)?

It is used for "starting" traffic at the ASP.  The MTP User at the ASP
should not be informed that MTP is available to it until "n" ASPs are
available.

> If SG decides that there are enough number of ACTIVE ASPs, why should we
> prevent ASPs to initiate traffic?

Because of the "start decision" criteria explained earlier on this thread.
The ASPs should wait, otherwise, they stand a chance of failure and wasting
network resources during an already critical network outage condition with
oscillating congestive failures.  SGs will typically always be able to handle
the traffic and have higher availability requirements than ASPs, particularly
in the SG as STP configuration.

> "messages" make the ambiguity disappear?

I know the history of the passage: I started the "M3UA-10: Example 5.1.4"
thread.  It was one of my LC issues.

It was Greg's original suggestion from his note of Jan 2, 2002:

	"Do we need to add a hint that an ASP should wait for the
	Notify(AS_Active) (or via internal knowledge that sufficient
	ASPs are ASP Active)."

I have no problems with changing "n" in your text to "sufficient" (but its
really the same thing now isn't it?)

> > > destination. I don't interprete it directly related

It is germane to the discussion because the "MAY" permits the SG
to take any necessary actions with respect to the SS7 network.
To say "SHOULD" would be inappropriate (placing a requirement on how
the SG interacts with the SS7 network).

> "MAY" about withholding traffic is mainly related for communication between

Here I disagree.  There is no mention of buffering data in the SG as there
is for the AS-PENDING state.  The statement is directly with regard to SPMC
management.

> only for PENDING case(?).

Now your going around in circles...  The text does not say that the SG
withholds traffic.  It says that it "MAY choose not to direct traffic to
an newly active ASP".  Withholding traffic (placing it into a buffer) is
what happens in AS-PENDING state.  Choosing not to direct traffic to a
newly active ASP (for a newly active AS) consists of not telling the SS7
network (or local MTP Users) that the AS is accessible yet.  What *is*
"withheld" is the NTFY(AS_Active).

Consider the following example because it appears that you don't understand
what is involved:

AS1 RK1 = PCA/ISUP.  n = 2, k = 1.  3 ASPs: ASP1, ASP2, ASP3, 1 SGP: SGP1

AS1 is inactive.  ASP1 comes up and goes active for AS1.  SGP1 knows that
n=2 and also knows that ASP2 and ASP3 are in the ASP-DOWN state.  Until
now it has been responding to local MTP User MTP-TRANSFER requests to PCA,
SI=5 with MTP-STATUS(Inaccessible User).  Messages from the SS7 network
have been replied to with UPU(Inaccessible).  Now, SGP1 MAY decide to not
direct traffic to ASP1, but continue to respond to local MTP-TRANSFER
requests destined to AS1 with MTP-STATUS(Inaccessible User) and respond to
received SS7 messages for AS1 with UPU(Inaccessible).  If it does so, it
SHOULD withhold the NTFY(AS_Active).  If it decides to direct traffic to
ASP1, it MUST send NTFY(AS_Active) and will mark the MTP User as accessible
(and stop responding with MTP-STATUS and UPU).  The RFC cannot tell the
SGP designer what they should or should not do here because it is intricately
involved with SS7 conformance and performance.

ASP2 and ASP3 SHOULD coordinate with ASP1 the number of active ASPs.  That
is, ASP2 and ASP3 should know that "n" are required and should take action
to establish associations, go ASP-UP and at least one of them should go
ASP-ACTIVE for AS1.  There is no way for SGP1 to "tell" an ASP to go active
for an AS, so this is something the ASPs need to do on their own.  Also,
ASP1 SHOULD wait until one of ASP2 or ASP3 is active for AS1 before informing
the local ISUP (MTP User at PCA/SI=5) that it can start traffic.

Any questions?

There is absolutely nothing the matter with the statements in the RFC.

> from SG, not to count number of ACTIVE ASPs by themselves.

In the above example, when ASP1 starts traffic is based on the situation with
regard to itself, ASP2, ASP3 and SGP1 and from the view of the M3UA protocol
is no different than the basis on which the SG decides.  SGP1 decides on its
own status, and its knowledge of the status of ASP1, ASP2 and ASP3.

In fact in the example the SGP has less information than ASP1 (because it does
not coordinate with ASP2 and ASP3 which are in the down state as far as the
SGP is concerned).

The SGP has some information about MTP users in the SS7 network, but then ASP1
has information about its local MTP users to which the SGP is not privy.

What kinds of dynamic information did you think the SGP has at its disposal
that the ASP does not?

--brian

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