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

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 18 Feb 2003 15:00:50 +0100

Brian, 

I agree 

RFC simply says: 

	"n ASPs is the minimum number of redundant ASPs required to handle traffic"

As this is the minimum number, it can be inferred that for #ASPs < n no traffic can be handled. Nothing is mentioned in the RFC about engineered load although it may be thought that n value calculation is based on that.  

I would say that the current model does not support the use of extra ASPs for loads bigger than the engineered nor the use of less than n for smaller loads... The message is clear saying that #ASPs<n implies no traffic, i.e. whenever you can not support the engineered load, stop the system. This last sentence is not in the RFC but it can be deduced as the engineered load for n can... 

Cheers // Javier. 

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, February 18, 2003 12:49 PM
> To: Javier Pastor-Balbas (ECE)
> Cc: [email-masked]
> Subject: Re: [Sigtran] Re: M3UA Notify message
> 
> 
> Javier,
> 
> Javier Pastor-Balbas (ECE) wrote:             (Tue, 18 Feb 
> 2003 12:17:54)
> > > Javier Pastor-Balbas (ECE) wrote:             (Tue, 18 
> Feb 2003 07:57:23)
> > > > 
> > > > Hi Brian, 
> > > > 
> > > > According to the RFC "n" is required to handle traffic 
> with minimum
> > > > losses, what is expected from the SS7 point of view in 
> an interworking
> > > > scenario.
> 
> Please cite this passage, because I cannot find it.  I find 
> no mention of
> minimum number of ASPs and "message loss".  The only 
> reference to message loss
> that I know of is unrelated.
> 

> > > 
> > > That would be the numbe required to handle maximum 
> engineered load, which
> > > is the same thing.
> > > 
> > 
> > If you refer to the compromise load engineered to be 
> available 99% (aprox.)
> > of the time, then I agree. But this is a statically value fed at
> > configuration time. And the system won't work till n number 
> is reach since
> > the system will likely have quality contrains.
> 
> The maximum engineered load is a figure established at 
> configuration time.
> 
> Carrier-grade systems must always work with 1 processor.  The 
> system will just
> not necessarily be able to handle the offered load.  (But it might:
> particularly during quiet periods, off-peak, normal-day, etc.)
> 
> The offered load cannot be established at configuration time 
> and varies widely
> for telephony systems.
> 
> You must also realized that the system might, at any time,  
> be offered a load
> greater than the maximum engineered load (mass calling, busy 
> periods, etc.):
> so for carrier-grade systems even "n" processors must 
> implement overload
> controls (and they could not claim SS7 compliance if they didn't).
> 
> Look back in this thread and you will see the factors 
> contributing to the
> anticipated offered load for the start, restart and stop decision.
> 
> The decisions are not based on less than "n" processors not 
> allowing the
> system to work (where n > 1).  They are based on the negative 
> effects of
> delivering pent up traffic to processors that will likely 
> just congest.
> 
> --brian
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 18 Feb 2003 07:30:37 -0700

Javier,

Javier Pastor-Balbas (ECE) wrote:                                                   (Tue, 18 Feb 2003 15:00:50)
> As this is the minimum number, it can be inferred that for #ASPs < n no
> traffic can be handled. Nothing is mentioned in the RFC about engineered
> load although it may be thought that n value calculation is based on that.  
> 
> I would say that the current model does not support the use of extra ASPs
> for loads bigger than the engineered nor the use of less than n for smaller
> loads... The message is clear saying that #ASPs<n implies no traffic, i.e.
> whenever you can not support the engineered load, stop the system. This last
> sentence is not in the RFC but it can be deduced as the engineered load for
> n can... 

It does not say that.

It says:

   The failover model supports an "n+k" redundancy model, where "n" ASPs
   is the minimum number of redundant ASPs required to handle traffic
   and "k" ASPs are available to take over for a failed or unavailable
   ASP.  A "1+1" active/backup redundancy is a subset of this model. A
   simplex "1+0" model is also supported as a subset, with no ASP
   redundancy.

And quite frankly this passage was written when we still had "n+k" active/
standby in the document.

Directly with respect to loadsharing modes, 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.

   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.

   All ASPs within a loadsharing mode AS must be able to process any
   Data message received for the AS, to accommodate any potential
   failover or rebalancing of the offered load.

Note especially the passages "sufficient resources to handle the expected
load" and "to accomodate any potential failover or rebalancing of the offered
load".  Note also, the "must" on being able to process any Data message
received for the AS.

Similar statements are made for broadcast mode.

It is clear from the later that "traffic" in section 1.4.4.1 for the
case of loadshare and broadcast AS relates to "expected load" and
"offered load", the only configurable figure of which is "engineered load".

This is particularly true as the interpretation of IG 3.15 has no
practical use.

--brian

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Wed, 19 Feb 2003 03:30:32 -0600 (CST)

Hi,

I beleive 'n' is minimum number of ASPs to handle the 'best traffic T'.
To handle the 'worst traffic T+1', SG may require 'n+1' ASPs.

'n'is the derived value based on the traffic report given by Traffic
Metering and Measurement.

So 'n' is fed during configuration of stack.When traffic increases from
'T' to 'T+1' or # APSs < n - this case SG is required to send NOTIFY to
'k' ASP.

And one more thing when # APSs < n, SG still can handle the traffic with
single ASP.

When 'n' ASPs are active
------------------------

SLS-X  ---->ASP1
SLS-Y  ---->ASP2

When ASP1 goes down
-------------------

SLS-(Y,X)  ----->ASP2

Instead of banning the complete traffic ,it can be handled (not 100%) by
ASP2.

--Samuel

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

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Wed, 26 Feb 2003 04:17:31 -0600 (CST)

Hi,

Why there is no discussion when traffic reaches from 'T' to 'T+1'?
(as mail below).
Is it not possible to have 'T+1' taffic?

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 26 Feb 2003 04:54:40 -0700

Samuel,

The RFC says that the ASPs should coordinate between themselves the number
of active ASPs.  A k ASP is welcome to activate whenever it wants.  The
SGP cannot invoke the activation of an ASP.

--brian

Samuel Dur D. Jeyaseelan wrote:                                                     (Wed, 26 Feb 2003 04:17:31)

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Wed, 26 Feb 2003 06:06:29 -0600 (CST)

Brian,
I understood the same.But there may be a time where SG can request k ASP
to become active in order to handle the heavy traffic.
Because configured 'n' ASPs are sufficient to handle the normal traffic
but when traffic increases than 'normal traffic' from SS7 network towards
SG- this case SG may request k ASP to become active.

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 26 Feb 2003 05:13:01 -0700

Samuel,

Samuel Dur D. Jeyaseelan wrote:                                                     (Wed, 26 Feb 2003 06:06:29)
> SG- this case SG may request k ASP to become active.

The SG has no understanding of the traffic handling capability of the ASPs.

The only thing it has in the number "n".

"n" is the numer of ASPs required to handle the maximum engineered (expected)
load, (not the "normal" load).

The SG does not (and cannot be required to) monitor any traffic load and even
if it did, it cannot translate this into ASP handling capacity.

The ASPs should coordinate how many of them are active with consideration for
their own process loading.

The RFC is fine as it is.

--brian

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Wed, 26 Feb 2003 22:13:57 -0600 (CST)

Brian,

> The SG has no understanding of the traffic handling capability of the ASPs.
I beleive SGP uses a single transmission buffer and re-transmission buffer
towards 'n' ASPs.
SGP measures these buffers to understand 100% traffic handling
capability of 'n' ASPS .When these bufers are overflowing, SGP can send
NTFY to 'k' ASP.

From ASP point of view, ASP sends SCON when congestion occurs, assume at
SGP transmission buffer and re-transmission buffers are overflowing, in
this case Should SGP stop traffic towards 'n' ASPs ? or Can SGP send NTFY 
to 'k' ASP to become active. Sending NTFY to 'k' ASP is the best
approach-this is my understanding.

--Samuel

---

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

Samuel,

Samuel Dur D. Jeyaseelan wrote:                                                     (Wed, 26 Feb 2003 22:13:57)
> capability of 'n' ASPS .When these bufers are overflowing, SGP can send

By monitoring its send buffer depth (which is difficult on socket based
SCTP APIs in the first place) the SGP cannot distinguish between queueing
due to IP network congestion, retransmission, inter-stream blocking,
undetected outage, or peer congestion.

Regardless, the SGP cannot and should not activate an ASP.  The ASPs should
coordinate activation between themselves in the n+k scenario.

> approach-this is my understanding.

The ASP is not required to send SCON at any time.  Nor is the SGP required
to do anthing with SCON received from the ASP.

The SG is responsible for translating its view of SCTP congestion events into
any necessary SS7 events.

--brian