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

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 9 Apr 2002 19:16:33 +0200

Hi, 

Taking a look to the RFC2119, the meaning of MAY is clear: It is an optinal feature. If we change "MAY" to "SHOULD", we are changing the scope of that feature. 

IMO, I see the text is clear enough in the sense that the normal behavior is having "n" as preferred, but optionally you can require a more stringent behavior and consider it as mandatory. Then it makes sense all the MAY you have talked about. But also the "SHOULD" since it means that if you implement the "mandatory" one, you have to do what "SHOULD" says in general.

I don't agree with withholding the traffic in the SGP: What happens with SS7 nodes ??!!!! Timers expiring, retransmissions, SGP buffers overloading....  (!!!)
This is not a good situation. If the AS decides it can not afford all the traffic, just follow the regular M3UA procedure: change to AS_INACTIVE and send an alarm to the operator to improve the resource planing (he was the one who set the limits). The SGP would inform the SS7 side about the unavailability of IP side. A good network planning is crucial therefore...

Cheers // Javier.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, April 09, 2002 6:01 PM
> To: Ken Morneault
> Cc: Tolga Asveren; [email-masked]
> Subject: Re: [Sigtran] m3ua-implementors-guidev00 n+k traffic mode
> 
> 
> Ken,
> 
> Please see comments below...
> 
> Ken Morneault wrote:                                          
> (Tue, 09 Apr 2002 11:05:05)
> > 
> > 
> > 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.  
> 
> 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
> 
> > 
> > Ken
> > 
> > At 09:01 AM 4/9/2002 -0400, Tolga Asveren wrote:
> > >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
> > >
> > >> -----Original Message-----
> > >> From: Brian F. G. Bidulock [mailto:[email-masked]]
> > >> Sent: Monday, April 08, 2002 9:03 PM
> > >> To: Tolga Asveren
> > >> Cc: [email-masked]
> > >> Subject: Re: [Sigtran] m3ua-implementors-guidev00 n+k 
> traffic mode
> > >>
> > >>
> > >> Tolga,
> > >>
> > >> Please see comments below...
> > >>
> > >> Tolga Asveren wrote:                                        (Mon,
> > >> 08 Apr 2002 19:42:04)
> > >> > Brian,
> > >> >
> > >> > Please see comments below.
> > >> >
> > >> >   Tolga
> > >> >
> > >> > > -----Original Message-----
> > >> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > >> > > Sent: Monday, April 08, 2002 7:26 PM
> > >> > > To: Tolga Asveren
> > >> > > Cc: [email-masked]
> > >> > > Subject: Re: [Sigtran] m3ua-implementors-guidev00 
> n+k traffic mode
> > >> > >
> > >> > >
> > >> > > Tolga,
> > >> > >
> > >> > > Tolga Asveren wrote:                                 
>        (Mon,
> > >> > > 08 Apr 2002 19:17:27)
> > >> > > > 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.
> > >> > >
> > >> > > Should?  I don't think that it matters if ASPs 
> withhold traffic.  The
> > >> > > danger here is really that the SGP might overload the ASPs.
> > >> > [TOLGA] But is it really usefull that ASPs send messages but
> > >> the answers are
> > >> > not coming back to ASPs?
> > >> > >
> > >> > > > 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").
> > >> > >
> > >> > > 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.
> > >> > [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")
> > >>
> > >> 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.
> > >[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".
> > >>
> > >> 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
> > >> > >
> > >> > > >
> > >> > > >   Tolga
> > >> > > >
> > >> > > > > -----Original Message-----
> > >> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > >> > > > > Sent: Monday, April 08, 2002 7:00 PM
> > >> > > > > To: Tolga Asveren
> > >> > > > > Cc: [email-masked]
> > >> > > > > Subject: Re: [Sigtran] 
> m3ua-implementors-guidev00 n+k traffic mode
> > >> > > > >
> > >> > > > >
> > >> > > > > Tolga,
> > >> > > > >
> > >> > > > > Tolga Asveren wrote:                             
>            (Mon,
> > >> > > > > 08 Apr 2002 18:38:56)
> > >> > > > > > 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-.
> > >> > > > >
> > >> > > > > "MAY" does not imply "required".
> > >> > > > >
> > >> > > > > --brian
> > >> > > > >
> > >> > > > > >
> > >> > > > > >     Tolga
> > >> > > > > >
> > >> > > > > > > -----Original Message-----
> > >> > > > > > > From: Vats, Umesh [mailto:[email-masked]]
> > >> > > > > > > Sent: Monday, April 08, 2002 6:15 PM
> > >> > > > > > > To: 'Ken Morneault'
> > >> > > > > > > Cc: 'Tolga Asveren'; [email-masked]; 
> [email-masked]'
> > >> > > > > > > Subject: RE: [Sigtran] m3ua-implementors-guidev00 n+k
> > >> traffic mode
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > > 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
> > >> > > > >
> > >> > > > > --
> > >> > > > > 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
> > >>
> > >> --
> > >> 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
> 
> -- 
> 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: "Tolga Asveren" <[email-masked]>
Date: Tue, 9 Apr 2002 14:12:26 -0400

Javier,

My understanding is that you would like n to be interpreted as "preferred"
and you propose ASPs should not rely on number of already ACTIVE ASPs but
should consider themselves as ACTIVE as soon as they get ASPAC-ACK from SGP?

Please also see below for further comments.

   Tolga

> From: Javier Pastor-Balbas (ECE)
> [mailto:[email-masked]]
> Sent: Tuesday, April 09, 2002 1:17 PM
> To: [email-masked]
> Cc: Tolga Asveren; [email-masked]'; Ken Morneault
> Subject: RE: [Sigtran] m3ua-implementors-guidev00 n+k traffic mode
>
>
> Hi,
>
> Taking a look to the RFC2119, the meaning of MAY is clear: It is
> an optinal feature. If we change "MAY" to "SHOULD", we are
> changing the scope of that feature.
>
> IMO, I see the text is clear enough in the sense that the normal
> behavior is having "n" as preferred, but optionally you can
> require a more stringent behavior and consider it as mandatory.
> Then it makes sense all the MAY you have talked about. But also
> the "SHOULD" since it means that if you implement the "mandatory"
> one, you have to do what "SHOULD" says in general.
>
> I don't agree with withholding the traffic in the SGP: What
> happens with SS7 nodes ??!!!! Timers expiring, retransmissions,
> SGP buffers overloading....  (!!!)
[TOLGA] If n is interpreted as "required" on SGP and if SGP withholds
traffic, the AS state shouldn't be ACTIVE. In such a case either the
Signalling Point or the UserPart (depending on the type of RK) is
inaccessible/unavailable from SS7 point of view. So, SGP won't receive
traffic for them from SS7.
> This is not a good situation. If the AS decides it can not afford
> all the traffic, just follow the regular M3UA procedure: change
> to AS_INACTIVE and send an alarm to the operator to improve the
> resource planing (he was the one who set the limits). The SGP
> would inform the SS7 side about the unavailability of IP side. A
> good network planning is crucial therefore...
[TOLGA] The approach you proposed might crate ping-pong cases. For example
n=2. ASP1 sends ASPAC and receives ASPAC-ACK but the load is too high and it
decides to send ASPIA and receives ASPIA-ACK. Just after it ASP2 sends ASPAC
and the same thing happens with ASP2.

---

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

Tolga,

Tolga Asveren wrote:                                        (Tue, 09 Apr 2002 14:12:26)
> and the same thing happens with ASP2.

I agree, sending ASP Inactive is a litte too drastic: however, there are
other options available to the ASP.  One of them is Nodal SCON.  Another
one is to just not service the SCTP read side any faster than it is able:
this will cause write side SCTP congestion at the SGP (unfortunately for
all streams) and the SGP can employ congestion avoidance measures to keep
from overloading the ASP.

Because the ASP has this do-nothing measure at its disposal, the difference
between "preferred" and "required" is moot: if the SGP attempts to overload
and ASP, it will be faced with congestion at the SCTP send side.  If this
congestion is properly reflected back to the SS7 network by the NIF (or local
users at an IPSP), the SS7 network (user) itself will reduce sending to
the limits that are acceptable by the number an capacity of ASPs active.

On the other hand, an ASP can send all it wants because SGs must be sized
appropriately for capacity.  Nevertheless, the same is true in the reverse
direction: if the ASP attempts to send to the SG too fast, SCTP write-side
congestion will result and the ASP will have to take some action.

I don't think it is of much use to consider local overloads under traffic
stimulus in isolation from IP and SS7 congestion and application flow
controls.

Now I agree with Javier.  Leave the MAY as MAY.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 9 Apr 2002 14:50:53 -0400

Brian,

If we rely on the congestion mechanisms you described -which in my opinion
should work-, I think everything in the draft referring to n+k -that SGP MAY
withhold traffic, that ASPs should coordinate number of ACTIVE ASPs among
themselves etc...- should be deleted (except NTFY("Insufficient ASPs
ACTIVE")) This was one of the options I put to my first message related with
this topic and so now it seems there is a consensus for this approach.

    Tolga

> Sent: Tuesday, April 09, 2002 2:33 PM
> To: Tolga Asveren
> Cc: [email-masked]

---

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

Tolga,

I do not agree with deleting the current text.  The current text
provides an advisory mechanism for handling `n+k'.  This augments
any other lcoal procedures that the SGP and ASP have at their
disposal.  What is the need to remove anything?  The ASP can
reasonably rely on no receiving NTFY("AS-ACTIVE") until `n' ASPs
are available as viewed by the SGP.  The SGP MAY withhold traffic
or do what it likes.  There is nothing the matter with these
statements to cause their removal.

Quite the opposite: the text in the RFC (which *is* the concensus)
can stay as it stands.

--brian

Tolga Asveren wrote:                                        (Tue, 09 Apr 2002 14:50:53)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 9 Apr 2002 15:44:08 -0400

Brian,

Then please see comments below.

  Tolga

> Sent: Tuesday, April 09, 2002 3:06 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] The problem is that the local procedures, which one might choose to
follow or not are affecting the expected behaviour of the peer.
> reasonably rely on no receiving NTFY("AS-ACTIVE") until `n' ASPs
[TOLGA] I already quoted the sentence from draft saying that ASPAC-ACK has
the meaning "SGP is ready to send/receive traffic" . Unless this sentence is
removed -or maybe with some addition saying "except n+k redundancy case"-
ASP will consider SGP as ready to send/receive traffic after receiving
ASPAC-ACK, without waiting for NTFY("AS Active").
> statements to cause their removal.
[TOLGA] Then I have to repeat the same question, what will happen if SGP
withholds traffic but ASP starts traffic(or vice versa)? There should be
either no traffic withholding (removing n+k sentences) or it should be
always withhold unless n ASPs are active (changing MAY to MUST) or there
should be a way SGP tells to ASP that it actually wants to send/receive
traffic (using NTFY("AS Active") instead of ASPAC-ACK on ASP side to decide
to start traffic)
For anything else, I can tell you a scenario, which will create problems.
> > > > > > > >> > > > > > > > >      | INACTIVE |
> > > > > > > >> > > > > > > > >      |          |<---
>    \  ACTIVE
> > > > > > > >> > > > > > > > >      +----------+
>         \
>          --|
> > > > > > > >> > > > > > > > >      | AS-DOWN  |
> |<----------------------------|
> > > > > > > >>           |

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 9 Apr 2002 16:02:03 -0500

Tolga,

Tolga Asveren wrote:                                        (Tue, 09 Apr 2002 15:44:08)
> ASPAC-ACK, without waiting for NTFY("AS Active").
I already quoted the sentence where it says that in `n+k' configuration
the ASP SHOULD wait for NTFY("AS Active").  It is clear.  There is no

> withholds traffic but ASP starts traffic(or vice versa)?

Whether SGP witholds traffic is an OPTION.  Certainly the SGP implementation
must consider the ramifications of withholding traffic.  The RFC does not
require one to do so.  There is no problem.

> There should be

That's too black and white for me.

> For anything else, I can tell you a scenario, which will create problems.

But none of those scenarios are required by the RFC, an would require an
implementation to exercise the MAY.  Would you prefer to chang the MAY to
SHOULD NOT (although it is pretty much the same thing).

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 9 Apr 2002 17:27:42 -0400

Brian,

I think the source of our disagreement is you assume that ASP should wait
for NTFY("AS Active") before starting send/receive traffic. But where is
this stated? The draft just says "In this case, the SGP or IPSP SHOULD
withhold the Notify(AS-ACTIVE) until there are sufficient resources." But it
does not say that ASP SHOULD wait for NTFY("AS Active") to start
send/receive traffic. It only says "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)." So, when ASP receives ASPAC-ACK, it will assume SGP is
ready to process traffic.
If the draft is changed so that ASP decides about the readiness of SGP based
on NTFY("AS Active") instead of ASPAC-ACK, a flexible n+k redundancy model
might work. Personally, I don't see any other flexible alternative, so
unless this change is done either it should be not or "MUST" to withhold the
traffic. Anything else ("MAY", "SHOULD", "SHOULD NOT", "MAY NOT") won't work
properly because as I stated before they are open to implementation
decisions and based on those local decisions, the remote peer should behave
differently, and for sure the remote peer can't know the local decision.
Also my personal opinion is that the scenarios I can create to show problems
in solutions with "MAY","SHOULD" etc... are valid ones, and preferrably
should be addressed by the draft.

    Tolga

> Sent: Tuesday, April 09, 2002 5:02 PM
> To: Tolga Asveren
> Cc: [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 9 Apr 2002 15:58:16 -0500

Tolga,

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 9 Apr 2002 17:42:43 -0500

Tolga,

Tolga Asveren wrote:                                        (Tue, 09 Apr 2002 17:27:42)
> ready to process traffic.

No,
 
" An SGP or IPSP, upon reception of an ASP Active message for the first 
" ASP in a Broadcast 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.
"
" 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.

The above is clear: ASPs should start sending traffic only after `n' ASPs
are active.  Now, whether they coordinate amongst themselves or wait for
NTFY("AS-ACTIVE") what's the difference?  As the SGP withholds
NTFY("AS-ACTIVE") until there are `n' ASPs active in the AS?

There is no problem here.

> might work.

I'm sorry, but in this `n+k' case the RFC says (above) that the ASP "should"
wait until `n' ASPs are active.

> Personally, I don't see any other flexible alternative, so

It is MAY because whether an SGP withholds traffic an any time is
really implementation dependent.  I already provided many examples
and reasons why the SGP need not withhold traffic.  But it MAY.
It is an OPTION.  See the Keywords RFC.

> Anything else ("MAY", "SHOULD", "SHOULD NOT", "MAY NOT") won't work

Behaving differently is not a reason to preclude the option.  As there
are no harmful interoperability issues (the ASP does not have to service
its SCTP read queue) and it is not harmful to the network (SCTP congestion
protects the network), there is no reason to require an SGP to withhold
traffic and there is no reason to require it not to.  Gee, it sounds like
an option.... ;)

> should be addressed by the draft.

Bring 'em on.  Let's see one of these scenarios.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 9 Apr 2002 19:25:19 -0400

Brian,

Please see a further comment below.

  Tolga

> Sent: Tuesday, April 09, 2002 6:43 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] That is the key point. If it is not a "MUST", how can we be sure
that SGP will withhold traffic and NTFY("AS Active")? But because ASPs will
always decide based on the number of ACTIVE ASPs.

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 9 Apr 2002 19:28:18 -0400

Please ignore "because" at the marked place, it is not only an innocent
mistake but makes it really hard to understand the sentence.

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Tolga Asveren
> Sent: Tuesday, April 09, 2002 7:25 PM
> To: [email-masked]
> that SGP will withhold traffic and NTFY("AS Active")? But because
> ASPs will                                                 ^^^^^^^^

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 9 Apr 2002 19:18:30 -0400

Brian,

1) It makes very big difference in my opinion, whether ASPs decide that SGP
is ready to send/receive traffic based on the number of ACTIVE ASPs or based
on NTFY("AS Active"). NTFY("AS Active") is sent directly from SGP and shows
the actual situation at the SGP. If they decide based on the number of
ACTIVE ASPs, then SGP also MUST withhold traffic unless n ASPs are ACTIVE.
If it is something less than "MUST" SGP is free to choose to send or
withhold data for case ACTIVE ASP number < n and if it chooses to send then
I don't think this will create a nice case. For example n = 2 for AS1. ASP1
is ACTIVE but ASP2 is INACTIVE for AS1. Then SGP decides not to withhold
traffic. ASP1 will drop messages it receives for AS1, because number of
ACTIVE ASPs is 1. I think the scenario I described is a valid one and I
don't think it is nice to drop the messages on ASP1.
So, counting number of ACTIVE ASPs will work without problems only if SGP
MUST withhold traffic (unless we rely on NTFY("AS Active")) and relying on
number of ACTIVE ASPs or NTFY("AS Active") makes a difference.

2) I still remember, when I proposed to use NTFY("AS Active") to decide for
readines of SGP instead of ASPAC-ACK, there was no support at all. So, I
don't think the majority is interpreting it like you described in your
message, i.e. I don't think most of the people rely on NTFY("AS Active") on
ASP side to start send/receive traffic. If now there is an agreement to use
NTFY("AS Active") for that purpose, this will work.

3) Relying Congestion mechanism you described (SCON , SCTP congestion) might
work, then we don't need n+k redundancy. This is what I call never
withholding traffic. ASPs won't count number of ACTIVE ASPs and will rely
only on ASPAC-ACK in this case.

   Tolga

---

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

Tolga,

Plesae see comments below...

Tolga Asveren wrote:                                        (Tue, 09 Apr 2002 19:25:19)
> always decide based on the number of ACTIVE ASPs.

You can't be sure but it doesn't matter.
These are recommendations not laws.

--brian

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

---

From: "Vikas" <[email-masked]>
Date: Wed, 10 Apr 2002 09:05:11 +0530

Tolga,

----- Original Message -----
From: "Tolga Asveren" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, April 10, 2002 4:55 AM
Subject: RE: [Sigtran] m3ua-implementors-guidev00 n+k traffic mode

> always decide based on the number of ACTIVE ASPs.
[Vikas] Not only on the number of ACTIVE ASPs, BUT on NTFY("AS-ACTIVE")
also; ASP will start the handling of traffic as soon as any ONE of the two
checks meet. Using NTFY("AS-ACTIVE") will help the ASP when SGP decides to
start traffic on first ASP ACTIVE, although 'n' is greater than one.
Cheers

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 10 Apr 2002 08:57:52 -0400

Vikas,

Could you tell me how you came to the conclusion that either reaching n
ACTIVE ASPs or receiving NTFY("AS Active") will make ASP decide to start
send/receive traffic? Where is it stated that receiving NTFY("AS Active")
will have such an effect?

   Tolga

> From: Vikas [mailto:[email-masked]]
> Sent: Tuesday, April 09, 2002 11:35 PM
> To: Tolga Asveren
> Cc: [email-masked]

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 10 Apr 2002 09:39:35 -0400

Brian,

In my opinion it matters, because this affects how the ASP has to react. I
am not trying to push this or that solution, but I don't think n+k
redundancy will work without problems unless modifications are made on the
current draft. Till now we came up with three different alternatives how the
situation can be handled and it is my impression that most of the people
were already assuming that it is already like one of those alternatives.

    Tolga

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 10 Apr 2002 10:45:05 -0400

Vikas,

My question was, where it is stated that ASP decides for readiness of SGP
based on NTFY("AS Active"). Please show me the sentence, where this is
indicated.
All of the things you quoted from the draft, is already discussed in this
thread, please refer to them for further explanations.

   Tolga

> Sent: Wednesday, April 10, 2002 10:35 AM
> To: Tolga Asveren
> Cc: [email-masked]
> Lets converge following two excerpts from M3UA v12:
> 1. from Section 4.3.4.3 ASP Active Procedures
> "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."
> 2. from Section 4.3.4.5 Notify Procedures
> "A Notify message reflecting a change in the AS state MUST be sent to
> all ASPs in the AS......."
>
> Therefore, No matter SGP waits 'n' ASPs to become ACTIVE or not,
> But It(SGP)
> will MUST send NOTIFY(AS_ACTIVE) to all the ASPs (to whom it has sent ASP
> ACTIVE ACK) WHENEVER it (SGP) will change AS state to AS_ACTIVE (and i see
> no need to say that SGP will start sending/receiving traffic just when it
> changes AS state to AS_ACTIVE). And since sending of NOTIFY(AS
> State Change)
> is MUST for SGP, ASPs can rely on it. And thus ASPs do get to
> know that the
> SGP has chosen which side of 'MAY'.
>
> With best regards,
> Vikas.
> To: "Vikas" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, April 10, 2002 6:27 PM
> ASPs in state
> > > > > The above is clear: ASPs should start sending traffic
> only after `n'
> > > ASPs
> > > > that SGP will withhold traffic and NTFY("AS Active")? But
> because ASPs
> > > will
> > > checks meet. Using NTFY("AS-ACTIVE") will help the ASP when
> SGP decides
> to

---

From: "Vikas" <[email-masked]>
Date: Wed, 10 Apr 2002 20:04:55 +0530

Tolga,

Therefore, No matter SGP waits 'n' ASPs to become ACTIVE or not, But It(SGP)
will MUST send NOTIFY(AS_ACTIVE) to all the ASPs (to whom it has sent ASP
ACTIVE ACK) WHENEVER it (SGP) will change AS state to AS_ACTIVE (and i see
no need to say that SGP will start sending/receiving traffic just when it
changes AS state to AS_ACTIVE). And since sending of NOTIFY(AS State Change)
is MUST for SGP, ASPs can rely on it. And thus ASPs do get to know that the
SGP has chosen which side of 'MAY'.

With best regards,
Vikas.

---

From: "Vikas" <[email-masked]>
Date: Wed, 10 Apr 2002 20:48:03 +0530

Tolga,
Please see inside...
----- Original Message -----
From: "Tolga Asveren" <[email-masked]>
To: "Vikas" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, April 10, 2002 8:15 PM
Subject: RE: [Sigtran] m3ua-implementors-guidev00 n+k traffic mode

> based on NTFY("AS Active"). Please show me the sentence, where this is
[Vikas]Although there is no explicit sentence. But If SGP declares its
readiness by NTFY("AS Active") to ASP then it is quite implicit that ASP
will believe upon it. Why it will disbeleive on SGP?
Anyway if folks like/need that level of explicit documentation, then better
... add some sentence. I will not object either.

> > > > > [TOLGA] That is the key point. If it is not a "MUST", how can we
be
> > sure
> > > > also; ASP will start the handling of traffic as soon as any ONE of
the
> > two

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 10 Apr 2002 11:34:43 -0400

Vikas,

The point is I already proposed to add this sentence (relying on NTFY("AS
Active"))but at that there wasn't support for it. That is the reason, why we
added that ASPs should coordinate among themselves number of active ASPs.
I don't think it is a clever choice to rely on assumptions for cases which
are requering involvement of both peers, afterall the protocol is there to
define the behaviour of peers when they interact to each other. So, the
problem is not "disbelieving SGP" or not but to rely on assumptions or on
clearly defined procedures.

    Tolga

> Sent: Wednesday, April 10, 2002 11:18 AM
> To: Tolga Asveren
> Cc: [email-masked]
> > > > Could you tell me how you came to the conclusion that
> either reaching
> n