Subject: Re: [Sigtran] Re:n+k issue

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Sat, 28 Jun 2003 01:36:10 -0500 (CDT)

Brian,

question in-line.
 
  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, 27 Jun 2003, Brian F. G. Bidulock wrote:

> Lyndon,
> 
> I don't think that I have misinterpreted anything as I authored half the text
> in question and helped with the other half.  Consider the history of consensus
> on this issue:
> 
> This began with the thread that I initiated entitled
> 
>   "M3UA-10: Example 5.1.4" that extended from Jan 2, 2002 to Jan 7, 2002.
> 
> This was a LC issue on M3UA.  The example showed in the "n+k" case the SG
> sending NTFY(AS-Active) after this first (yes, the first) ASP activated for
> the AS even thought "n=2" in the example.  I asked why the SG did not withhold
> NTFY(AS-Active) until after "n=2" ASPs were active for the AS.
> 
> Greg proposed the text:
> 
>   An SGP or IPSP, upon reception of an ASP Active message for the first ASP in
>   a Load-share AS, MAY choose not to direct traffic to a newly active ASP
>   until it determines that there are sufficient resources to handle the
>   expected load (e.g., until there are "n" ASPs in state ASP-ACTIVE in the
>   AS)."
> 
> The MAY was intentional to permit the SG to activate on the first ASP.
> 
> I proposed that the SG then withhold the NTFY(AS-Active) until after it
> directs traffic if the SG follows the MAY and waits for sufficient ASPs.  (The
> point of the original issue.)
> 
> It was agreed on this thread that some implementations would want to wait for
> 'n' and some would want to activate immediately, relying on the congestion and
> flow controls of the ASP and MTP-User parts to handle any potential traffic
> overloads.
> 
> Consensus was reached in the LC process and the text was adopted in M3UA-11.
> 
> On the thread:
> 
>   "n+k redundancy + NTFY  changes" from Jan 30, 2002 to Feb 1, 2002.
> 
> Tolga (surprising now) asks John Loughney to echo the changes of these two
> passages into SUA and the same procedures are incorporated into SUA by
> consensus.
> 
> On the thread:
> 
>   "m3ua-implementors-guidev00,  OPC list + missing issues" from March 31, 2002
>   through April 10, 2002.
> 
> The discussion of "n+k" is brought up again by Tolga.  In this thread, Vikas,
> Ken Morneault, and I agree that the text is clear.  Vikas and I also defend
> the text.  Tolga is the only dissenter.  Umesh asks for clarification in the
> IG, but it is agreed that the text in the RFC is clear.
> 
> On the thread:
> 
>   "m3ua: IG : n+k redundancy" from Jun 21, 2002 to Jun 26, 2002
>   and
>   "m2ua: IG : n+k redundancy - AS state machine"
> 
> Tolga brings up the same arguments again.  Javier's conclusion from previous
> discussion initially was that no change was necessary.  Javier and Tolga then
> go on to have a discussion between the two of them.  (I would have disagreed
> in the middle of this, as consensus was already reached twice, but I was in a
> U-haul between Texas and Alberta for the remainder of their exchange).  No one
> else commented on the matter.
> 
> On the next thread:
> 
>   "I-D ACTION:draft-ietf-sigtran-m3ua-implementors-guide-02.txt"
> 
> I initiated a number of issued on the new release of the IG including the
> section 3.15 which was not included by consensus, but only on the basis of
> this brief discussion between Javier and Tolga.   I pointed out to Ken the
> previous consensus points on this matter and he agreed to review the mail
> threads.  Ken did not comment further.
> 
> Next on the thread:
> 
>   "M3UA Notify message" from Feb 12, 2003 to Feb 26, 2003
>   (rejoined recently and extending from Jun 18, 2003 to Jun 26, 2003)
> 
> Srini asks some questions about Notify messages and n+k comes up again.  Srini
> agrees that active ASPs < n corresponds to the AS-ACTIVE state as in the RFC
> and that the ASP should use congestion and flow control procedures to limit
> traffic if it is presented with too much traffic.  Bijoy agrees as well.
> Srivats agrees as well with not stopping traffic #ASPs < n.  Samuel also
> agrees with not stopping traffic #ASPs < n.  Javier agrees to the MAY.

Could you please give me a pointer where i agreed?

--Samuel

> 
> The thread is rejoined recently.  The only dissenting voice on the thread is
> Tolga (and most recently Javier).
> 
> Now, it appears to me that Tolga has brought this up on 4 or 5 separate
> occasions, on each occasion (except when I was in the U-Haul) consensus was
> that the existing RFC text stands and that the SG can activate with the first
> ASP active in the AS regardless of 'n' or MAY wait for 'n' and SHOULD withhold
> then NTFY(AS-Active) is reiterated.
> 
> 10 separate individuals have come to consensus 4 times on this issue,
> including last call, and the result was always that the RFC stands.  This text
> also appears by consensus (as proposed by Tolga!) in SUA.  In subsequent
> discussions Tolga was the only dissenting voice.  It appears Tolga wants 'n'
> to be required (only) and never preferred.
> 
> The existing text allows it to be preferred or required depending on SG
> implementation or configuration.  Although Tolga states that "1+k" required is
> the same as preferred, the Notify(Insufficient ASPs Active in AS) behavior is
> different for "1+k" required than it is for "n+k" preferred.
> 
> 10 separate individual disagree with Tolga's proposals over the cited threads
> (he disagrees with himself on a couple of occasions too).
> 
> Section 3.15 was NOT included on the consensus of the WG and stands against
> the consensus of the WG.  There is no rough consensus to adopt the proposal as
> evidenced by the archive.
> 
> As the WG has consistently spoken against these changes over the last 18
> months, please do the right thing and strike Section 3.15 from the IG.
> 
> Thank you.
> 
> --brian
> 
> 
> Lyndon Ong wrote:                                                                   (Thu, 26 Jun 2003 18:16:18)
> > Hi Folks,
> > 
> > At the risk of blowing up the issue (although I think we
> > are there already), I would like to make the following
> > points:
> > 
> > -- the issue of n+k is in fact confusing in the RFC text
> >   - n+k as defined in the introduction is subject to multiple
> >     interpretations
> >   - n+k has the following procedure defined in 4.3.4.3 -
> >   "For the n+k redundancy case, ASPs which are in that AS should
> >    coordinate among themselves the number of active ASPs in the AS, and
> >    should start sending traffic only after n ASPs are active."
> >     This seems to imply that traffic should only be resumed after
> >     n ASPs are active, even if traffic is sent from the SG the ASPs
> >     should not reply.
> >   - the examples in 5.1.4 and 5.2.3 also appear to reflect this usage.
> >   - n+k is not clearly reflected in the current state diagrams
> > 
> > Given that this appears to be a valid issue with the RFC and
> > there seems to be a greater weight of opinion on the side of
> > the proposed text I believe that the rough consensus exists
> > supporting the proposed text in the M3UA implementor's guide draft.
> > 
> > However, I understand the concern on the part of some folks
> > that have interpreted n+k differently.  As a result I think
> > we also should add clarifying text to the n+k definition in
> > 1.4.4.1 stating that in this definition, traffic is not sent
> > until "n" ASPs are active, and that the "k" ASPs may be either 
> > active at the same time as "n" or kept inactive until needed
> > due to a failed or unavailable ASP.  Hopefully that will 
> > cover other situations acceptably.
> > 
> > Cheers,
> > 
> > L. Ong
> 
> -- 
> 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, 28 Jun 2003 01:29:16 -0600

Samuel,

Samuel Dur D. Jeyaseelan wrote:                                                     (Sat, 28 Jun 2003 01:36:10)

> Could you please give me a pointer where i agreed?

Correct me if I'm wrong but it appears in the following two statements that
you agreed to not stopping traffic for #ASPs < n.

> Date: Tue, 25 Feb 2003 08:11:31 -0600 (CST)
> From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
> To: "Javier Pastor-Balbas (ECE)" <[email-masked]>
> cc: "Brian F. G. Bidulock" <[email-masked]>,
>    TOLGA ASVEREN <[email-masked]>, [email-masked]
> Subject: RE: [Sigtran] Re: M3UA Notify message
> 
> Javier,
> 
> On Tue, 25 Feb 2003, Javier Pastor-Balbas (ECE) wrote:
> 
> > Hi Samuel et al., 
> > 
> > Take into account that if you define two ASes:
> > - AS1 DPC+SLS1  with two ASPs (ASP1 and ASP2) and redundancy: n=1 k=1
> > - AS2 DPC+SLS2  with two ASPs (ASP1 and ASP2) and redundancy: n=1 k=1
> > 
> > And 
> > - ASP1 active for AS1 and backup for AS2
> > - ASP2 active for AS2 and backup for AS1
> > 
> > You get the desired behaviour. This case can be solved with a right 
>   network configuration without changing the current "required"
>   qualification for "n".
> > 
> > 
> > 
> > Apart from this, 
> > 
> > I would say that a compromise option would consist of considering "n" as 
>   the normal working case, but make it implementation dependent (maybe
> configurable) whether an implementation may have more than "n" ASPs 
>  working at the same time for an AS, and whether the SG keeps working when
> the number of ASP is under "n". We could make a recommendation with "MAY" 
> allowing both options.
> >
> [Samuel] Yes .SG keeps working when n=1 or n >=2.
> but current RFC says that SG NOTIFIES 'k' ASP to become active only
> when n<2 and it does not say what will happen when SG requires more than
> 'n' ASP to handle the traffic 't+1'.
>  
> > But now, the problem comes with the AS state machine. If we agree upon here,
>  we could say the AS is ACTIVE in the range n_min to n_max, where these two
>  values are configurable.
> > 
> [Samuel] To handle the 'normal(best) traffic T' SG requires 'n=2' ASPs.
> In the course of traffic if 'n became 1'(means ASP1 failed), here SG can
> handle the traffic with 'n=1' ASP. 
> So only intially SG requires 'n=2' ASPs to make the AS state as ACTIVE
> and 'n=2' is fed during configuration.But while handling traffic due to 
> failure of ASP1 'n' becomes '1', here still AS is ACTIVE with single ASP.
> 
> --Samuel

[snip]

> Date: Tue, 25 Feb 2003 06:08:39 -0600 (CST)
> From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
> To: TOLGA ASVEREN <[email-masked]>
> cc: [email-masked]
> Subject: Re: [Sigtran] Re: M3UA Notify message
> 
> 
> Tolga,
> 
> From this thread we can end up with two kinds of SGs.
> 
> The SG which decides to stop taking the traffic when 'n' changed
> from '2' to '1'.
> 
> The other SG which decides to continue the traffic  when 'n' 
> changed from '2' to '1'.
> 
> When performance is considered, i think everyone will prefer second case.
> Second case follows the existing network standards.But first case does
> not follow any standards.

[snip]

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

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Sat, 28 Jun 2003 03:24:46 -0500 (CDT)

Brian,

In this attached mail i have said that 'n=2'(example) is mandatory at
start case.
This is what Javier,Tolga are also proposing to make 'n=2' as mandatory
at start case.

SGP will stop taking traffic when # ASPS < n at start case.

But while handling the traffic if # ASPs < n , this will not stop the
traffic.This is what i comprised in this mail.

So from the beginning i disagree to make an AS as active as soon as a
single ASP goes to ACTIVE state in n+k reduntancy case.

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 28 Jun 2003 02:42:03 -0600

Samuel,

In the note I only said that you and Srivats agreed to not
stopping traffic #APSs < n.  I didn't say that you agreed
to starting traffic on the first ASP.  The others in this
and previous disccusions did, however.

--brian

Samuel Dur D. Jeyaseelan wrote:                                                     (Sat, 28 Jun 2003 03:24:46)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 28 Jun 2003 04:17:53 -0600

Samuel,

I should point out that the proposal to require that the SG wait for 'n' to
start traffic does not have much merit.

Example: n=256, k=1

2 ASPs fail, permanently and need to be manually replaced.

A temporary network failure causes SCTP associations to be lost to the
remaining 255 ASPs.  They move to the ASP down state and immediately
re-establish SCTP associations and move to the ASP-Active state.  Because the
number of ASPs is < n, the SG will not restart traffic for some time.

Consider the same example with: n=2, k=1, two ASPs failed.

Any system that introduces hysteresis to aggravate and perpetuate an outage in
this fashion is not very useful.

In the examples, what would have been a brief AS-PENDING situation has been
turned into a prolonged and complete system failure.  It is certainly not good
practice to design redundant systems in that fashion and recommending or
requiring such a design would be a bad thing.

To further the example, consider the multiple SG as STP situation.  One SG
cannot know the state of ASPs for the its mated SG and therefore cannot
distinguish between the restart scenario and the start scenario as far as the
AS state is concerned because the SG does not know the state of the AS itself:
the AS could be active with other SGs.

This is the same case for SGP.  Unless AS state is synchronized across SGPs,
one SGP cannot know the total state of the AS (only its partition).  There is
no requirement to synchronize AS state across SGP (on the SGP side, AS-state
is per-SGP), and there is certainly no requirement to synchronize AS-state
across SGs.

So, take the (n=2, k=0) example where there are two SGs.  Due to a network
partitioning at startup, one ASP can communicate only with one SG, and the
other ASP can communicate only with the other SG.  Because n=2, neither SG
will start traffic and the system suffers 100% failure until the network
partitioning ceases.

Consider the same example where there are two SGPs (instead of SGs) and the
two ASPs normally only form one association (e.g., ASP1-SGP1, ASP2-SGP2).
Note that there is no requirement in the RFC to form full-mesh associations.
Because the number of active ASPs with each SGP is < 2, the system will never
start.

These are not strange scenarios.  These situations are all permitted by the
RFC.  Yet, in each situation it is clear that one cannot recommend that the SG
wait.  The result would be a non-functional system.  There are many more
examples.

n+k is a model for redundancy (not for congestion and flow control).  A system
with an SG that waits for n is, in general, not a fully redundant system at
all, but is, rather, prone to these failure syndromes.

When you look at the situation and apply the experience of reliability
engineering, the recommendation is that the SG SHOULD start traffic when the
first ASP goes active.

Why wait for 'n' anyway?  Because the ASP cannot handle some level of traffic?
Any ASP that conforms to MTP-User standards, must have the standardized
MTP-User (ISUP/SCCP) congestion and flow controls and must have the SCTP
congestion controls and is therefore able to accept any amount of traffic
overload.

So there is no real reason for the SG to wait for 'n'.  Nevertheless, the RFC
allows this as an OPTION.  Requiring (MUST) or recommending it (SHOULD)
regardless of whether the number of active processors is rising or falling,
whether start, restart or failure, is unacceptable.

On the other side, at the ASPs, the ASPs have a requirement to share state
between them.  They must share circuit state and transaction state in all
configurations to meet carrier grade.  This is stated in the RFC.  It is
implicit that the ASPs are capable of knowing with which SGs, and which SGPs
for which they are active.  They have access to the total state of the AS that
they collectively represent, that the SG/SGP does not.  Therefore is it
reasonable for the ASPs to coordinate among themselves the number of active
ASPs and to ensure that there are sufficient ASPs active to handle the
expected load before starting traffic.  Because the ASPs need not respond to
user test traffic (UPT/SST), the ASPs are also in control of when remote SS7
MTP-User restart traffic toward them.

Therefore, the recommendation that the ASPs SHOULD coordinate among
themselves the number of active ASPs and not start traffic until a sufficient
number of them are active is sound.  This is not a MUST, permitting ASPs
that know that they are capable of handling any overload, to start traffic
immediately, or at some earlier point.

Back to the RFC, the RFC sets the normal case where the SG starts traffic on
the first active ASP but explicitly permits as an OPTION to wait until it
considers that there are sufficient ASPs active to handle the offered load.
The RFC also RECOMMENDS that the ASPs coordinate among themselves the number
of active ASPs so that there are sufficient ASPs to handle the expected load.

The provisions in the RFC are both sound, where the proposal and section 3.15
is clearly not.

Remember when looking at the AS state diagram in the RFC that this is the
SGP's view of the AS state and not the total state of the AS, that can only
known to the ASPs for all configurations.  'n' as defined has no meaning to
the state machine at the SGP because is not required to know, and often cannot
know, how many ASPs are active for the AS via other SGPs and SGs, or even via
direct connection to the SS7 network.

Some SGs might have special knowledge, or sophisticated algorithms that allow
it to determine whether a congestive failure will be the immediate result of
starting or restarting traffic.  These SGs are permitted as an OPTION to wait.

The ASPs SHOULD have the knowledge of how many are required to handle the
expected load, because they must share circuit/transaction state and they must
have congestion and flow controls as required by the standards.

So again, the RFC is adequate in this regard.  The current proposal and
section 3.15 are not.

--brian

Brian F. G. Bidulock wrote:                                                         (Sat, 28 Jun 2003 02:42:03)

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

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 28 Jun 2003 07:36:29 -0700 (PDT)

Brian,

IMO -although you disagree-, your arguments should
lead to discarding n+k concept from SG side, and
always activating with the first ACTIVE ASP, because I
don't see how SG can dynamically decide to activate or
not an AS. (BTW, getting rid of n+k was also proposed
as one of the options at one of the n+k discussions,
basically there were three options 
1) If there is no use for n+k, no need to define it
2) Making AS state changes based on NTFY on ASP side
3) Using n as a static value at both SGP and ASP so
that their AS state views are the same.)
So, I think n+k case -as in IG- with n=1 should give
the operation characteristics you want.
Please see also some other comments/questions below.

     Tolga
--- "Brian F. G. Bidulock" <[email-masked]>
> number of ASPs is < n, the SG will not restart
[TOLGA] So, maybe you should have n=254, k=2, or n
=200 k=56 (IMO your example is very extreme -a low k
value, 2 systems going down and global network
failure)
> turned into a prolonged and complete system failure
>  It is certainly not good
[TOLGA]So? This is always possible. What is wrong that
SGs have different view of AS state? (Although I don't
believe multiple SG scenario is well supported with
M3UA, I believe n+k does not bring any disadvantage)
> failure until the network
[TOLGA]For n=2 -I speak from IG 3.15 point view-, this
is the expected and desired behaviour. Nothing wrong
with this. This can be avoided with n=1. And from your
point of view, there is no way SG can know anything
about the situation either. In fact this is an example
for my point at the beginning of the message: SG can
only statically decide to activate AS (and this might
be forced always to happen with the first ACTIVE ASP
or with a configurable number of ACTIVE ASPs, which
certainly allows that number also to be 1)
BTW, it is also very unlikely that two ASPs have
different IP connectivity to the network and that a
network isolation happens. 
> Because the number of active ASPs with each SGP is <
[TOLGA] IMO, this is definitly a configuration
problem. Either let both ASPs form association to both
SGPs, or use n=1.
> all, but is, rather, prone to these failure
[TOLGA]Because transition from AS-ACTIVE to AS-PENDING
has been changed, I think n+k increases redundancy of
the system. 
> SHOULD start traffic when the
[TOLGA] Then just using n=1 should be fine.
> congestion controls and is therefore able to accept
[TOLGA]This is just another level of operation. If the
operator knows that n ASPs are required for a healthy
operation, what is wrong by giving the operator the
choice of configuring n, where n=1 is also possible?
> So again, the RFC is adequate in this regard.  The

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 29 Jun 2003 00:35:04 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Sat, 28 Jun 2003 07:36:29)
> Brian,
> 
> IMO -although you disagree-, your arguments should lead to discarding n+k
> concept from SG side, and always activating with the first ACTIVE ASP, because
> I don't see how SG can dynamically decide to activate or not an AS.  (BTW,
> getting rid of n+k was also proposed as one of the options at one of the n+k
> discussions, basically there were three options 1) If there is no use for n+k,
> no need to define it

The SG MAY withhold traffic in the RFC.  This is an OPTIONAL feature.  OPTIONAL
features that are not implemented between "Proposed Standard" and "Standard"
will be automatically dropped.  Therefore, if we choose 1), no change is
necessary and we can strike 3.15 and wait for the OPTIONAL feature to drop
between "Proposed Standard" and "Standard".

OTOH, others could find it useful, even if you do not and implement the option,
in which case it would remain an option when the protocol moves to "Standard".
I described a number of ways in which the option can be used.  I have considered
implementing a procedure similar to the link oscillation procedures in ANSI/2000
MTP, where the SG would withhold traffic and NTFY(AS Active) for a probation
period on restart to avoid failure oscillation.  Under such a scheme, if the ASP
is restarting within a suspension interval from the last restart, the SG would
withhold traffic until a probation interval expired.  This makes sense because
SCTP has no proving period for M3UA.

> 2) Making AS state changes based on NTFY on ASP side

The ASP is already permitted to do this now.  If we choose 2), no change is
necessary and we can strike 3.15.

> 3) Using n as a static value at both SGP and ASP so that their AS state views
> are the same.)

The AS state view at the SGP and ASP are not the same.  One SGP can view the AS
state as AS-DOWN while another SGP and the ASP view the AS state as AS-ACTIVE.
Therefore you cannot make the AS state view the same unless protocol is added to
have the ASP notify the SGP what the total ASP state is with regard to the AS.

Your proposal does not make this view the same, because each SGP already has an
independent state view of the AS.  The SGP's view of the AS-state is its own.
So, for example, ASP1 has an association with SGP1 and SGP2.  The ASP has
executed ASP-UP on the association to SGP1, and has executed ASP-Active/Ack for
AS1 with SGP1.  The ASP has not executed ASP-UP with SGP2 yet.  SGP1's view is
that ASP1 is ASP-ACTIVE for AS1 and that AS1 is in the AS-ACTIVE state.  SGP2's
view is that ASP1 is ASP-DOWN and that AS1 is in the AS-DOWN state.  The ASPs
view is that it is AS-ACTIVE for AS1.  SGP2 and ASP1 have a different view of AS
state.  This inherent to the protocol.  Neither the current section 3.15 nor
your proposal can achieve this.

> So, I think n+k case -as in IG- with n=1 should give the operation
> characteristics you want.

No.  Because the SG will not send Notify(Insufficient ASPs active in AS) for
n=1.  That is an operational characteristic that is not achieved by setting n to
1.  Also, if n is set to 1, the ASPs are not expected to wait until the true 'n'
of them are active before starting traffic themselves.  Also, the SG can no
longer wait for the true 'n' ASPs to become active before starting traffic is
its its prerogative in the current RFC.

Setting n to one changes both points in the RFC: that the SG MAY wait for 'n'
and that the ASP SHOULD wait for 'n'.  These are the fundamental operating
characteristics as I have already described below.

The option you missed:

4) Leave the RFC as it is, because there is nothing the matter with it.

> > re-establish SCTP associations and move to the ASP-Active state.  Because
> > the number of ASPs is < n, the SG will not restart traffic for some time.
> [TOLGA] So, maybe you should have n=254, k=2, or n =200 k=56 (IMO your example
> is very extreme -a low k value, 2 systems going down and global network
> failure)

There are no restrictions on n or k.  However, the same example was repeated
with n=2 and k=1.  Pick a number.  It appears that if n=7 and k=1, you will tell
me that I should have made n=6 and k=2 and then if 3 ASPs fail, you will tell me
I should have set n=5 and k=3 and so on, until you tell me finally as you have
above that I should set n=1 and k=6.

Well, n is not some arbitrary value.  It is the number of processors necessary
to handle the engineered load with the engineered level of reliability,
considering k.  When n=6 and the number of active ASPs drops to 5, the SG sends
notification to all the active and inactive ASPs (i.e. the k ASPs) that there
are insufficient ASP resources active in the AS.  Arbitrarily setting n=1 does
not accomplish this.

> > Any system that introduces hysteresis to aggravate and perpetuate an outage
> > in this fashion is not very useful.
> > 
> > turned into a prolonged and complete system failure It is certainly not good
> > distinguish between the restart scenario and the start scenario as far as
> > the AS state is concerned because the SG does not know the state of the AS
> > itself: the AS could be active with other SGs.
> [TOLGA]So? This is always possible. What is wrong that SGs have different view
> of AS state? (Although I don't believe multiple SG scenario is well supported
> with M3UA, I believe n+k does not bring any disadvantage)

Yes, what is wrong with this?  You are the one that said that the reason for
your proposal was so that the SGP and the ASP will have the same view of the
AS-state.  Well they cannot.  What other reason do you have for your proposal?

> > one SGP cannot know the total state of the AS (only its partition).  There
> > is no requirement to synchronize AS state across SGP (on the SGP side,
> > AS-state is per-SGP), and there is certainly no requirement to synchronize
> > AS-state across SGs.
> > 
> [TOLGA]For n=2 -I speak from IG 3.15 point view-, this is the expected and
> desired behaviour. Nothing wrong with this.

Err, there is plenty wrong with requiring or recommending such an unnecessary and
prolonged 100% failure.

> This can be avoided with n=1.

With n=1 the k'th ASP is not notified when one of the two 'n' ASPs fails.  Also,
the SG is then unaware that the number of active ASPs is beneath the engineered
capacity.

> And from your point of view, there is no way SG can know anything about the
> situation either. In fact this is an example for my point at the beginning of
> the message: SG can only statically decide to activate AS (and this might be
> forced always to happen with the first ACTIVE ASP or with a configurable
> number of ACTIVE ASPs, which certainly allows that number also to be 1) BTW,
> it is also very unlikely that two ASPs have different IP connectivity to the
> network and that a network isolation happens. 
> > 
> > Because the number of active ASPs with each SGP is < 2, the system will
> > never start.
> [TOLGA] IMO, this is definitly a configuration problem. Either let both ASPs
> form association to both SGPs, or use n=1.

n=1 does not function correctly.  There is no requirement in the RFC to form
full mess associations.

> > RFC.  Yet, in each situation it is clear that one cannot recommend that the
> > SG wait.  The result would be a non-functional system.  There are many more
> > examples.
> > 
> > n+k is a model for redundancy (not for congestion and flow control).  A
> > system with an SG that waits for n is, in general, not a fully redundant
> > system at all, but is, rather, prone to these failure syndromes.
> [TOLGA]Because transition from AS-ACTIVE to AS-PENDING has been changed, I
> think n+k increases redundancy of the system. 

But because transition from AS-INACTIVE to AS-ACTIVE has not in your proposal,
the reliability of the system is reduced from that of the RFC.  That is what
is unacceptable about both section 3.15 and your proposal.

> [TOLGA] Then just using n=1 should be fine.

No, because n is not chose arbitrarily.  Setting n=1 arbitrarily does no have
the same dynamics with respect to the detection at the SGP and notification
from the SGP of insufficient ASPs active in the AS.

Perhaps the reason that you think that n can be set arbitrarily in this fashion
is because you do not understand the relationship of 'n' to 'k' in the n+k
redundancy model as it is normally applied in telecommunications engineering
practice.   Otherwise, I cannot see why you would think so falsely that n
can be set arbitrarily.  'n' and 'k' are engineered figures considering traffic
loading and reliability requirements.  They are outside the M3UA protocol.
They are not numbers that can be set willy nilly to extreme values such as 1
in an attempt to fudge one's way around the unreasonable requirement in your
proposal.

> > 
> > Why wait for 'n' anyway?  Because the ASP cannot handle some level of
> > traffic?  Any ASP that conforms to MTP-User standards, must have the
> > standardized MTP-User (ISUP/SCCP) congestion and flow controls and must have
> > the SCTP congestion controls and is therefore able to accept any amount of
> > traffic overload.
> [TOLGA]This is just another level of operation. If the operator knows that n
> ASPs are required for a healthy operation, what is wrong by giving the
> operator the choice of configuring n, where n=1 is also possible?

Because n is not 1.

What is the problem with the operator configuring the SG to wait for 'n' when
they known that the ASPs are so poorly designed that they do not conform to the
flow and congestion control requirements of the SS7 standards?  Nothing.  And
that is what the RFC permits.

But it also permits the SG to function without lost reliability with ASPs that
correctly conform to SS7 flow and congestion controls, without the poor hack
of setting n to 1.

The RFC already provides for both behaviors, and accommodates your broken ASPs,
without requiring properly functioning ASPs to behave like they are one big
broken ASP.

Who is there that has implemented an ASP with complete neglect for ISUP/SCCP
congestion and flow controls that needs the SG to wait?  Are you speaking of
your ASPs?

Comments please: Who is it that has an ASP that does not conform to SS7
ISUP and SCCP specifications and is so brittle that it needs the SG to wait?

(Nobody I think.)

But the option is there in the RFC in case some SG finds itself faced with
malfunctioning ASPs in the field.

--brian

> > 
> > So there is no real reason for the SG to wait for 'n'.  Nevertheless, the
> > RFC allows this as an OPTION.  Requiring (MUST) or recommending it (SHOULD)
> > for which they are active.  They have access to the total state of the AS
> > that they collectively represent, that the SG/SGP does not.  Therefore is it
> > themselves the number of active ASPs and not start traffic until a
> > sufficient number of them are active is sound.  This is not a MUST,
> > permitting ASPs that know that they are capable of handling any overload, to
> > start traffic immediately, or at some earlier point.
> > 
> > The provisions in the RFC are both sound, where the proposal and section
> > 3.15 is clearly not.
> > 
> > the state machine at the SGP because is not required to know, and often
> > cannot know, how many ASPs are active for the AS via other SGPs and SGs, or
> > even via direct connection to the SS7 network.
> > 
> > Some SGs might have special knowledge, or sophisticated algorithms that
> > allow it to determine whether a congestive failure will be the immediate
> > result of starting or restarting traffic.  These SGs are permitted as an
> > OPTION to wait.
> > 
> > expected load, because they must share circuit/transaction state and they
> > must have congestion and flow controls as required by the standards.
> > 

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

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Mon, 30 Jun 2003 09:44:01 -0500 (CDT)

Brian,

> number of ASPs is < n, the SG will not restart traffic for some time.

Your example leads to the following figure.

         SG1                            AS1
     
 SS7 MSG +------+----------------------- ASP (1)
---------| SGP1 |----------------------- ASP (2)
         |      |----------------------- ....
         +------+----------------------- ASP (256)
            |
            | 
            +---------------------------ASP(k)

1. First of all craft will not configure 1 ASP as backup for 256 Active
   ASPs, if he does, it means to be a poor network configuration.

2. Consider ASP as an MGC, your example leads to 256 MGCs and they are 
   controlled by a single SGP.A good network will have multiple SGPs to
   share the POTENTIAL traffic across ASPs.

3. BASIC INTENTION OF 'n+k' is,just to make sure that incoming messages
   ARE EFFICIENTLY TRANSMITTED TO DESTINATION ASPs WITH THE HELP OF
   MINIMUM NUMBER OF ASSOCIATIONS.

   Say for example

   Inefficient configuration -just an example
   ------------------------------------------
  
            SLS         DEST
            =================
             0           ASP1
             1           ASP1
             2           ASP1
             3           ASP1
             4           ASP1
             5           ASP1
             6           ASP1
             .            .
             .            .
             15          ASP1

               SG                            AS1
sls(0,1..15 )+----+  sls(0,1..15)         +------+
-------------|SGP1|-----------------------| ASP1 |
             |    |              ASSOC-1  +------+
             +----+                     

                      Fig - 1

In this figure, all incoming messages are transmitted over ASSOC-1 towards
ASP1.Here there are two potential problems 

       1. Total incoming traffic is dependent on a single ASP
       2. ASP1 is always overloaded, messages are processed one by one
          from the transmission buffer which ultimately introduces time
          delay(example last arrived msg will be processed at the end).

Efficient configuration
-----------------------  

             SLS         DEST
            =================
             0           ASP1
             1           ASP1
             2           ASP1
             3           ASP1
             4           ASP1
             5           ASP1
             6           ASP1
             7           ASP1
             8           ASP2
             9           ASP2
             .            .
             .            .
             15          ASP2

                       
              SG                             AS1
sls(0,1..15 )+----+   sls(0,1,..7)ASSOC-1 +------+
-------------|SGP1|-----------------------| ASP1 |
             |    |--------+              +------+
             +----+        | sls(8,9..15) +------+
                           +--------------| ASP2 |
                                 ASSOC-2  +------+
                        
                   fig - 2

In this example incoming traffic is distributed between ASP1 and ASP2.

IN ORDER TO HANDLE THE HEAVY INCOMING TRAFFIC, SGP1 NEEDS MINIMUM OF
2 ACTIVE ASPs BY SETTING n=2.

Your example with n=256 is completely a wrong interpretaion of 'n+k'
redundancy case.

> So again, the RFC is adequate in this regard.  The current proposal and
RFC is inadequate so we need section 3.15 to explain 'n+k' case.

--Samuel