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

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 19 Jun 2003 15:29:42 +0200

Hi Brian, 

I think Tolga had a good point. Maybe it is important to note the difference between max engineered load and peak load. I would leave to the operator how to solve the peak load. They may decide to turn to active more than "n" ASPs to solve this isolated cases.

Cheers // Javier.

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: jueves, 19 de junio de 2003 14:27
> To: [email-masked]
> Subject: Re: [Sigtran] Re: M3UA Notify message
> 
> 
> Brian,
> --- "Brian F. G. Bidulock" <[email-masked]>
> wrote:
> > Samuel,
> > 
> > 'n' (as agreed by concensus, and included in the new
> > IG text as well) is the
> > number of ASP required to handle the "maximum
> > engineered load", not the normal
> > load, or event the expected load.  So, for an ISUP
> > bearing system, if it is
> > not Christmas or Mother's day, and there is not a
> > significant backlog of
> > reattempt traffic (extended outage), the system can
> > come up with less than 'n'
> > processors, as 'n' is defined.  Therefore, refusing
> > to start or restart an
> > AS with less than 'n' active ASPs is foolish.
> > 
> > Setting n to 1, as you suggest, would be incorrect. 
> > 1 ASP cannot handle the
> > "maximum engineered load".  In the example, it takes
> > 256 ASPs to handle the
> > "maximum engineered load" (e.g. busy-hour on
> > Mother's Day).  But for the other
> > 340 some days of the year, some lesser number of
> > ASPs is sufficient, and 255
> > ASPs is surely sufficient.
> [TOLGA]For this case, IMO n=1 (or whatever is the
> number of ASPs, which should be ACTIVE at minimum)is
> correct. I don't interprete n as number of maximum
> ASPs, which can be ACTIVE at any given time. n is the
> number of ASPs, which should be ACTIVE, so that AS
> switches to ACTIVE state. For example, if n=3, this
> IMO does not mean that I can't have 256 ASPs ACTIVE at
> any given time. So, for your example, you set
> n=sufficient number of ASPs(something less than 256). 
> Maybe using the term n+k for this kind of operation is
> what you don't like?
> > 
> > Not permitting the SG to start or restart with less
> > than 'n' ASPs active
> > is a bad thing for carrier class systems.
> > 
> > I cannot agree with the change on these grounds.
> > 
> > --brian
> > 
> > 
> > Samuel Dur D. Jeyaseelan wrote:                     
> >                                (Thu, 19 Jun 2003
> > 00:42:05)
> > > 
> > > Brian,
> > > 
> > > 
> > > On Wed, 18 Jun 2003, Brian F. G. Bidulock wrote:
> > > 
> > > > Samuel,
> > > > 
> > > > Samuel Dur D. Jeyaseelan wrote:                 
> >                                    (Wed, 18 Jun 2003
> > 22:48:23)
> > > > > > > > 
> > > > > > > > I agree.   That is what is provided for
> > in the RFC.  However, section 3.15 of
> > > > > > > > the IG would require the SG to stop
> > traffic when n < 2.  So, it must be
> > > > > > > > struck.
> > > > > > > > 
> > > > > > > > --brian
> > > > > > > [Samuel] Does new IG stop the traffic when
> > n < 2 ?
> > > > > > 
> > > > > > Yes, it does.  On restart.
> > > > > > 
> > > > > Yes thats what everybody agrees that on start
> > and restart case 'n' number
> > > > > of ASPs to be in ACTIVE state.
> > > > 
> > > > Disagree wholeheartedly.  And this was never
> > agreed.
> > > > 
> > > > What was agreed (except for Tolga) was that the
> > RFC allowed the SG to either
> > > > activate on one ASP or wait for 'n' and withhold
> > NTFY(AS-ACTIVE) which was
> > > > sufficient for both start and restart cases.
> > > > 
> > > section 5.4.1 says that minimum 'n' number of ASPs
> > are required to handle 
> > > total traffic load.Here my understanding is, craft
> > person knows the
> > > incoming traffic capacity based on some kind of
> > 'traffic measurement
> > > analysis',
> > > and the same time craft person knows, to handle
> > this incoming traffic an
> > > SGP requires 'n' ASPs.Here the point is craft
> > person can not maintain 'n'
> > > ASPs to be in ACTIVE state throughout the traffic
> > period but at least he
> > > can make sure 'n' ASPs are ACTIVE when (initally)
> > SG comes up.
> > > 
> > > > If an outage has been for a brief period and was
> > not congestion related, there
> > > > is no reason why traffic cannot be started on
> > the first active ASP, or under
> > > > emergency conditions for that matter.
> > > This may happen while SGP is processing the load
> > but it may not happen in
> > > the beginning and a good network configuration
> > should not allow these
> > > kinds of problems to happen in the beginning.
> > > 
> > > > The start, restart and shutdown decisions were
> > discussed in detail on the
> > > > list.  Whether the SG waits for 1 or 'n' is an
> > IMPLEMENTATION and OPERATIONAL
> > > > decision.  The existing RFC provides for this in
> > saying that the AS-ACTIVE
> > > > state implies that "at least one" ASP is in the
> > ASP-ACTIVE state for the AS.
> > > > Also the RFC states that the SGP should withhold
> > the NTFY(AS-ACTIVE) until 'n'
> > > > ASPs are active if it is going to wait for 'n'
> > ASPs (as it MAY do).  And it
> > > > also says that the ASPs should coordinate
> > amoungst themselves to ensure that
> > > > 'n' are active.
> > > This is left to the decision of the craft person,
> > this case he can
> > > configure n=1.
> > > > 
> > > > Let me give you an example of the negative
> > effect of this change:  An SG is
> > > > configured with n=256.  There are 257 ASPs.  2
> > are dead.  The AS will never
> > > > activate.  Some carrier class system...
> > > > 
> > > If n=256, it is the responsibility of the operator
> > to make sure and bring
> > > up 256 ASPs to ACTIVE state at least in the
> > beginning.
> > > 
> > > > Contrast this where, soley at the SG
> > implementer's discretion, the SG
> > > > implementor sets a timer when the first ASP goes
> > ASP-ACTIVE for the AS.  If
> > > > the other 255 are not active by the time this
> > timer expires, it sends
> > > > NTFY(AS-ACTIVE) and starts traffic.  This system
> > will always come up in
> > > > contrast to the above that will not.  The RFC
> > allows for this system, the
> > > > new IG text does not.
> > > > 
> > > > The new IG text would have you implement the
> > system that will never come up
> > > > with 2 ASPs out of service.  The RFC does not.
> > > 
> > > section 5.1.4
> > >    n+k case
> > >    --------
> > >    This scenario shows the example M3UA message
> > flows for the
> > >    establishment of traffic between an SGP and
> > three ASPs in the same
> > >    Application Server, where two of the ASPs are
> > brought to the state
> > >    ASP-ACTIVE and subsequently share the load.  In
> > this case, a minimum
> > >    of two ASPs are required to handle the total
> > traffic load (2+1
> > >    sparing).
> > > 
> > > still RFC says '... a minimum of two ASPs are
> > required to handle the total
> > > traffic load ....'
> > > 
> > > > 
> > > > I you wan to explain things in the IG, go ahead,
> > but the proposed text does
> > > > not do that.  The proposed text makes changes to
> > the normal and correct
> > > > operation as laid out in the RFC and starts
> > making implementation and
> > > > operational decisions for the SG designer that
> > it must not.
> > > > 
> > > > --brian
> > > > 
> > > 
> > > I have conveyed my understanding to all. Otherwise
> > in order to conclude 
> > > this issue we can go for polling.
> > > 
> > > --Samuel
> > > > -- 
> > > > 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/
> > 
> === message truncated ===
> 
> 
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
> 
> _______________________________________________
> 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: Thu, 19 Jun 2003 13:19:12 -0600

Javier,

Telephone networks are engineered to meet high day busy hour peak load.  What
else did you think that "maximum engineered load" means?

--brian

Javier Pastor-Balbas (ECE) wrote:                                                   (Thu, 19 Jun 2003 15:29:42)
> Hi Brian, 
> 
> I think Tolga had a good point. Maybe it is important to note the difference
> between max engineered load and peak load. I would leave to the operator how
> to solve the peak load. They may decide to turn to active more than "n" ASPs
> to solve this isolated cases.
> 
> Cheers // Javier.
> 

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