Subject: RE: [Sigtran] m3ua-implementors-guidev00 n+k traffic mode

From: "Vats, Umesh" <[email-masked]>
Date: Mon, 8 Apr 2002 15:15:11 -0700

Hi  Ken

Different persons have different understanding of what
AS status should be if less than n ASPs in it are ACTIVE
(where AS has n+k redundancy).

This is clear from what Tolga and you have proposed.

Appropriate behaviour  should be clearly documented
in the implementor's guide. This will avoid multiple 
different interpretations of this by different persons.

Umesh

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Monday, April 08, 2002 1:06 PM
To: Vats, Umesh
Cc: 'Tolga Asveren'; [email-masked]; 'Ken Morneault'
Subject: Re: [Sigtran] m3ua-implementors-guidev00 n+k traffic mode

Umesh,

Tolga suggested that it be removed except for
NTFY("Insufficient ASPs active in AS").  I think
we agree that this NTFY message should stay.
When to send it is clear in the RFC.  The option
to withhold NTFY("AS Active") is  also clear.

Please see comments below...

--brian

Vats, Umesh wrote:                           (Mon, 08 Apr 2002 09:27:59)
> Hi  Ken/Tolga
> 
> I agree with one of Tolga's suggestion that n+k
> redundancy mode can be totally removed. Otherwise,
> many other issues need to be taken care of for which
> nothing is specified in draft e.g. 
> 
> 1. How will ASPs know whether more than n ASPs have
>    become ACTIVE for an AS at SGP (after which, the ASP
>    should start sending traffic to SGP)

By counting active ASPs an comparing the number of
active ASPs to the provisioned number `n'.

> 2. What will be state of AS at SGP if less than n ASPs
>    are ACTIVE

Active, but the NTFY("AS Active") message could be
withheld as stated in the RFC.

> 3. What will be the state of AS at SGP if an ASP
>    for an AS becomes INACTIVE and the total number of ASPs
>    ACTIVE for an AS become n-1 

Active, but the SGP immediately sends
NTFY("Insufficient ASPs active in AS").

> 
> Either, all the above cases should be clearly specified
> or n+k redundancy mode should be modified to 1+k redundancy
> mode.

All of the above cases are clearly specified in the RFC.

--brian

> 
> I think this can be covered in implementor's guide.

What additional clarifications beyond what already exists
in the RFC would you like to see?

--brian

> 
> Umesh
> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Monday, April 08, 2002 9:02 AM
> To: [email-masked]
> Subject: RE: [Sigtran] m3ua-implementors-guidev00 n+k traffic mode
> 
> 
> Another issue related with n+k redundancy, if n is interpreted as
> "required", I think there should be a way to tell in the traffic mode
> parameter, what is the value of n.
> 
>    Tolga
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Tolga Asveren
> > Sent: Monday, April 08, 2002 11:57 AM
> > To: [email-masked]
> > Subject: RE: [Sigtran] m3ua-implementors-guidev00 n+k traffic mode
> >
> >
> > Here are some ideas about n+k traffic mode issue:
> >
> > The source of the problem is, how n should be interpreted in n+k case.
It
> > seems the initial idea was, 1 ACTIVE ASP is always enough and n shows
the
> > preferred number of ACTIVE ASPs. Then there was a shift to the opinion,
to
> > interprete n as the required number of ACTIVe ASPs. Currently there are
> > conflicting statements in the draft about this issue.
> >
> > I don't know whether there is an agreement , but I favor the
> > approach where
> > n is interpreted as the required number of ACTIVE ASPs to consider AS in
> > ACTIVE state. In my opinion, the main argument for this is, if we think
1
> > ACTIVE ASP always enough to consider AS as ACTIVE, there is no need to
> > define something special in the protocol to cover n+k redundancy case.
How
> > many ACTIVE ASPs are preferred depends totally on the SGP in such
> > a case. In
> > fact, maybe this also could be an option, to delete everyhting
> > related with
> > n+k redundacy from the draft (ecxept NTFY("Insufficient ASPs are active
in
> > AS", which will have the meaning "I want more ASPs ACTIVE for this AS" )
> >
> > Now, necessary changes to interprete n as the required number of ACTIVE
> > ASPs(no guarantee that thi sis the full list)
> >
> > 1) Figure  5 :AS State Transition Diagram
> >
> > New Figure 5:
> >
> >                  Figure 5: AS State Transition Diagram
> >
> >                    one ASP trans to ACTIVE
> >                    causing number of ACTIVE ASPs
> >      +----------+  to be n                    +-------------+
> >      |    AS-   |---------------------------->|     AS-     |
> >      | INACTIVE |                             |   ACTIVE    |
> >      |          |<---                         |             |
> >      +----------+    \                        +-------------+
> >         ^   |         \ Tr Expiry,                ^    |
> >         |   |          \ at least one             |    |
> >         |   |           \ ASP in ASP-INACTIVE     |    |
> >         |   |            \                        |    |
> >         |   |             \                       |    |
> >         |   |              \                      |    |
> > one ASP |   | all ASP       \           one ASP   |    | one ACTIVE
> > trans   |   | trans to       \          trans to  |    | ASP trans to
> > to      |   | ASP-DOWN        -------\   ASP-     |    | ASP-INACTIVE
> > ASP-    |   |                         \  ACTIVE   |    | or
> > ASP-DOWN causing
> > INACTIVE|   |                    causing number   |    | number of
ACTIVE
> > ASPs
> >         |   |                    of ACTIVE ASPs   |    | drop below n
> >         |   |                    to be n \        |    |  (start Tr)
> >         |   v                             \       |    v
> >      +----------+                          \  +-------------+
> >      |          |                           --|             |
> >      | AS-DOWN  |                             | AS-PENDING  |
> >      |          |                             |  (queueing) |
> >      |          |<----------------------------|             |
> >      +----------+    Tr Expiry and no ASP     +-------------+
> >                      in ASP-INACTIVE state)
> >
> >     Tr = Recovery Timer
> >
> >
> > I didn't touch transitions to AS-DOWN and AS-INACTIVE state. I am
> > not sure,
> > whether also for those states we should care about n or not (for
> > example if
> > n-1 ASPs are in INACTIVE state and 1 ASP is in DOWN state, is AS DOWN or
> > INACTIVE in n+k redundancy case?)
> >
> >
> >
> > 2)4.3.4.3 ASP Active Procedures
> >
> > Old Text:
> > An SGP or IPSP, upon reception of an ASP Active message for the first
> > ASP in a Loadshare 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).  In this case, the SGP or IPSP SHOULD withhold the
> > Notify (AS-ACTIVE) until there are sufficient resources.
> >
> > New Text:
> > An SGP or IPSP, upon reception of an ASP Active message for the first
> > ASP in a Loadshare AS, MUST not 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).  In
> > this case, the SGP or IPSP SHOULD withhold the Notify (AS-ACTIVE) until
> > there are sufficient resources.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Old Text:
> > 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.
> >
> >
> > New Text:
> > 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 MUST not start
> > sending traffic related with that AS, unless n ASPs are active for it.
> >
> >
> >
> >
> >
> >
> > As I said above, another alternative is to get rid of n+k redundancy, to
> > consider any AS in ACTIVE state when there is one ASP ACTIVE for it.
This
> > just will require some sentences to be deleted from the draft and
> > interpretating NTFY("Insufficient ASP resources active in AS") in a
> > different way.
> >
> >    Tolga
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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

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

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 8 Apr 2002 18:38:56 -0400

Umesh,

It is true there are two different approaches (not just by different people,
even in the draft itself). I put both of them to my original message and
also the necessary changes, in case one of them is choosen.

My answers to your question was assuming n is interpreted as "required",
Brian's answers were for the case n is interpreted as "preferred". So, that
is the reason why our answers were different. If n is interpreted as
"preferred" I agree with Brian's answers -with a minor addition that I think
it makes more sense to remove the sentence "An SGP or IPSP, upon reception
of an ASP Active message for the first ASP in a Loadshare 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" from the draft, because
this would mean to interprete n as required-.

    Tolga

> From: Vats, Umesh [mailto:[email-masked]]
> Sent: Monday, April 08, 2002 6:15 PM
> To: 'Ken Morneault'
> Cc: 'Tolga Asveren'; [email-masked]; [email-masked]'
> > > From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> > > Tolga Asveren

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 8 Apr 2002 17:59:43 -0500

Tolga,

Tolga Asveren wrote:                                        (Mon, 08 Apr 2002 18:38:56)
> this would mean to interprete n as required-.

"MAY" does not imply "required".

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 8 Apr 2002 19:17:27 -0400

Brian,

Yes, but this is in my opinion the worst case. Because it is a "MAY"

a) SGP can decide to withhold traffic. In such a case, already ACTIVE ASPs
should also withhold traffic.
b) SGP can decide to start routing traffic. In such a case, already ACTIVE
ASPs should also start sending/receiving traffic.

How can ASPs know, what the SGP is going to decide? That was my point, when
I said, this sentence should be either removed (if n is interpreted as
"preferred") or MAY should change to MUST (if n is interpreted as
"required").

  Tolga

> Sent: Monday, April 08, 2002 7:00 PM
> To: Tolga Asveren
> Cc: [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 8 Apr 2002 18:25:53 -0500

Tolga,

Tolga Asveren wrote:                                        (Mon, 08 Apr 2002 19:17:27)
> should also withhold traffic.

Should?  I don't think that it matters if ASPs withhold traffic.  The
danger here is really that the SGP might overload the ASPs.

> "preferred") or MAY should change to MUST (if n is interpreted as

The ASP can know the difference by whether it has received
a NTFY("AS Active").  If the SGP is witholding traffic it
should withhold the NTFY("AS Active") as well.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 8 Apr 2002 19:42:04 -0400

Brian,

Please see comments below.

  Tolga

> Sent: Monday, April 08, 2002 7:26 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] But is it really usefull that ASPs send messages but the answers are
not coming back to ASPs?
> should withhold the NTFY("AS Active") as well.
[TOLGA] Probably you remember that I proposed this but there wasn't support
for it. So, still it is ASPAC-ACK, which will make ASPs decide to start
traffic (+ number of other ACTIVE ASPs, if n is interpreted as "required")

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 8 Apr 2002 20:03:04 -0500

Tolga,

Tolga Asveren wrote:                                        (Mon, 08 Apr 2002 19:42:04)
> traffic (+ number of other ACTIVE ASPs, if n is interpreted as "required")

Not true.  In Section 4.3.4.3 ASP Active Procedures (towards the bottom of
page 75), it says:

" An SGP or IPSP, upon reception of an ASP Active message for the first 
" ASP in a Loadshare 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).  In this case, the SGP or IPSP SHOULD withhold the 
" Notify (AS-ACTIVE) until there are sufficient resources.

I think the SHOULD is very explicit here and is fully in line with the
discussion we had on n+k before the RFC was finalized.

Also, Example 5.1.4 in the RFC shows the SGP waiting until `n' ASPs are
active before sending NTFY("AS-ACTIVE") to any ASP which is consistent
with this SHOULD.

This coupled with:

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

Which is state in several places, IMO make things crystal clear on all
these points.  It is clear that ASPs should not start traffic until they
know that there are `n' ASPs active (by whatever means) and that the SGP
MAY withhold traffic until `n' ASPs are active and should not send
NTFY("AS-ACTIVE") until there are `n' ASPs active.

There is no need to clarify what is there in plain English in the RFC.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 9 Apr 2002 09:01:41 -0400

Brian,

I also would like to interprete it the way you described but in my opinion
other interpretations are possible with the current draft.
For example in 4.3.4.3 ASP Active Procedures
"By sending an ASP Active Ack message, the SGP or IPSP is now ready to
receive and send traffic for the related Routing Context(s)." This tells ,
when ASP receives ASPAC-ACK, it will consider SGP ready to send and receive
traffic.
As I said, "MAY" kind of things are quite dangerous, if it is going to
affect the behaviour of the remote peer. How can ASP can know what SGP is
going to do? In such a case counting ACTIVE ASPs won't always work (because
SGP might decide to start traffic even after the first ACTIVE SGP) Relying
on NTFY might work, but then this should be stated clearly.
So, in my opinion, either withholding traffic till n ASPs are ACTIVE should
be a "MUST" in n+k redundancy case (so ASPs can count number of ACTIVE ASPs
and decide based on this) or with necessary changes, ASPs should rely on
NTFY("AS Active") to decide when to start send/receive traffic.
Please also see for further comments below.

    Tolga

> Sent: Monday, April 08, 2002 9:03 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] As I stated above, I don't think it is a good idead to make this a
"MAY". Also please note, "SHOULD" is only if "MAY" happens, so it is not
stronger than "MAY" -because it is said "In this case", and that we are "in
this case" is just a "MAY".
> > > > > > > > > interprete n as the required number of ACTIVe
> ASPs. Currently
> > > > > > > there are
> > > > > > > > > ACTIVE state. In my opinion, the main argument
> for this is,
> > > > > > > if we think
> > > > > > > 1
> > > > > > > > > n+k redundacy from the draft (ecxept
> NTFY("Insufficient ASPs
> > > > > > > are active
> > > > > > > in
> > > > > > > > > AS", which will have the meaning "I want more
> ASPs ACTIVE for
> > > > > > > this AS" )
> > > > > > > > >
> > > > > > > > > Now, necessary changes to interprete n as the
> required number
> > > > > > > of ACTIVE
> > > > > > > > >      | INACTIVE |                             |
> ACTIVE    |
> > > > > > > > >      |          |<---                         |
>           |
> > > > > > > > > ASP-    |   |                         \  ACTIVE
> |    | or
> > > > > > > > >      |          |                           --|
>           |
> > > > > > > > >      |          |                             |
> (queueing) |
> > > > > > > > > n-1 ASPs are in INACTIVE state and 1 ASP is in
> DOWN state, is
> > > > > > > AS DOWN or
> > > > > > > > > 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).  In
> > > > > > > > > For the n+k redundancy case, ASPs which are in
> that AS should
> > > > > > > coordinate
> > > > > > > > > For the n+k redundancy case, ASPs which are in
> that AS should
> > > > > > > coordinate

---

From: Ken Morneault <[email-masked]>
Date: Tue, 09 Apr 2002 11:05:05 -0400

I agree with Brian that the text is clear.  Both sides (ASP and SGP)
are free to treat 'n' as the preferred number of ASPs, but SHOULD
treat 'n' as the mandatory number.  

However, I also agree with Tolga that this might cause problems.  If 
one side treats 'n' as the preferred number, it may begin sending data 
before the other side.  This is particularly true if the other side
treats 'n' as a mandatory number of ASPs.  

Ken

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 9 Apr 2002 11:00:33 -0500

Ken,

Ken Morneault wrote:                                          (Tue, 09 Apr 2002 11:05:05)
> treats 'n' as a mandatory number of ASPs.  

Well, that would only be true if the SG (which must meet capacity) prefers
to start traffic and overloads ASPs which treat `n' as mandatory.  I would
suggest that the ASPs are in control of this situation: there is no need
for any of them to activate until they coordinate between themselves that
`n' (or even `n'+1) are available to activate.  I can see raising the MAY
to a SHOULD.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 9 Apr 2002 10:56:09 -0500

Tolga,

Tolga Asveren wrote:                                        (Tue, 09 Apr 2002 09:01:41)
> this case" is just a "MAY".

It does not say "SHOULD only if MAY".  It says "SHOULD in this case".

We used MAY because there are cases where an SGP does not need or does
not want to withhold traffic: low traffic periods, knowledge of the handling
capacity of the ASPs from configuration data, partial throttling, congestion
indicated towards the SS7 network, and on, and on...  A MUST is inappropriate
here.  I can see upgrading the MAY to a SHOULD: would that do?

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 9 Apr 2002 13:43:24 -0400

Brian,

Your explanation with low traffic periods makes sense to me. But this just
shows, the actual "required" n might change with time. So, now in my opinion
the only clean solution is to start sending/receving traffic on ASP side
after receiving NTFY("AS Active") from SGP, because even if "MAY" is changed
to "SHOULD" it still not a "MUST" and as you pointed out "MUST" might be too
restrictive based on the traffic load.

  Tolga

> Sent: Tuesday, April 09, 2002 11:56 AM
> To: Tolga Asveren
> Cc: [email-masked]
> > > > > > > Tolga Asveren wrote:
>       (Mon,
> > > > > > > 08 Apr 2002 18:38:56)
> > > > > > > > "preferred" I agree with Brian's answers -with a
> minor addition
> > > > > > > that I think
> > > > > > > > of an ASP Active message for the first ASP in a
> Loadshare AS,
> > > > > > > MAY choose not
> > > > > > > > > > > The source of the problem is, how n should be
> interpreted
> > > > > > > in n+k case.
> > > > > > > > > It
> > > > > > > > > > > seems the initial idea was, 1 ACTIVE ASP is
> always enough
> > > > > > > and n shows
> > > > > > > > > the
> > > > > > > > > > > preferred number of ACTIVE ASPs. Then there
> was a shift to
> > > > > > > > > the opinion,
> > > > > > > > > to
> > > > > > > > > > > n is interpreted as the required number of
> ACTIVE ASPs to
> > > > > > > > > consider AS in
> > > > > > > > > > > ACTIVE ASP always enough to consider AS as
> ACTIVE, there
> > > > > > > is no need to
> > > > > > > > > > >         ^   |         \ Tr Expiry,
>     ^    |
> > > > > > > > > > >         |   |          \ at least one
>     |    |
> > > > > > > > > > >         |   |            \
>     |    |
> > > > > > > > > > >         |   |             \
>     |    |
> > > > > > > > > > >         |   |              \
>     |    |
> > > > > > > > > > > one ASP |   | all ASP       \           one
> ASP   |    |
> > > > > > > one ACTIVE
> > > > > > > > > > > trans   |   | trans to       \          trans
> to  |    |
> > > > > > > ASP trans to
> > > > > > > > > > > to      |   | ASP-DOWN        -------\   ASP-
>     |    |
> > > > > > > ASP-INACTIVE
> > > > > > > > > > > ASP-    |   |                         \  ACTIVE
> > > |    | or
> > > > > > > > > > > ASP-DOWN causing
> > > > > > > > > > >         |   |                    of ACTIVE
> ASPs   |    |
> > > > > > > drop below n
> > > > > > > > > > >         |   |                    to be n \
>     |    |
> > > > > > > (start Tr)
> > > > > > > > > > >         |   v                             \
>     |    v
> > > > > > > > > > > An SGP or IPSP, upon reception of an ASP
> Active message
> > > > > > > for the first
> > > > > > > > > > > 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).  In this case, the SGP or
> IPSP SHOULD
> > > > > > > withhold the
> > > > > > > > > > > An SGP or IPSP, upon reception of an ASP
> Active message
> > > > > > > for the first
> > > > > > > > > > > ASP in a Loadshare AS, MUST not direct
> traffic to a newly
> > > > > > > active ASP
> > > > > > > > > until
> > > > > > > > > > > among themselves the number of active ASPs in
> the AS, and
> > > > > > > should start
> > > > > > > > > > > among themselves the number of active ASPs in
> the AS, and
> > > > > > > > > MUST not start
> > > > > > > > > > > sending traffic related with that AS, unless
> n ASPs are
> > > > > > > active for it.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > As I said above, another alternative is to
> get rid of n+k
> > > > > > > > > redundancy, to
> > > > > > > > > > > interpretating NTFY("Insufficient ASP
> resources active in
> > > > > > > AS") in a
> > > > > > > > > > > different way.
> > > > > > > > > > >
> > > > > > > > > > >    Tolga
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 9 Apr 2002 13:55:09 -0400

Brian,

  Tolga

> Sent: Tuesday, April 09, 2002 12:01 PM
> To: Ken Morneault
> Cc: Tolga Asveren; [email-masked]
[TOLGA] But what would happen in such a case, if the traffic load is low and
SGP decides to start sending traffic when less than n ASPs are ACTIVE (even
if we switch "MAY" to "SHOULD" it is still not a "MUST"? ASPs won't accept
traffic, because for them it is permanenetly mandatory that n of them are
ACTIVE.
> > >> > > > > > > > "required", I think there should be a way to
> tell in the
> > >> > > > > traffic mode
> > >> > > > > > > > > The source of the problem is, how n should
> be interpreted
> > >> > > > > in n+k case.
> > >> > > > > > > It
> > >> > > > > > > > > trans   |   | trans to       \
> trans to  |    |
> > >> > > > > > > > > to      |   | ASP-DOWN        -------\
> ASP-     |    |
> > >> > > > > > > > > active ASP until it determines that there
> are sufficient
> > >> > > > > resources to
> > >> > > > > > > > > among themselves the number of active ASPs
> in the AS, and
> > >> > > > > should start
> > >> > > > > > > > > among themselves the number of active ASPs
> in the AS, and
> > >> > > > > > > MUST not start