Re: Congestion in M3UA/SUA and the use of the SCON

Haresign,

Haresign Lincoln wrote:                                                            (Tue, 11 Oct 2005 14:09:51)
> Brian,
> 
> For some applications (e.g., SMS) it is not necessary to process a
> received SCON.  If the ASP is simply responding to a query from the SS7
> network, PCSTATE and N-PCSTATE have no meaning.

In this situation they have plenty of meaning.  Response NSDUs
are typically much larger than query NSDUs (small query, big
response).  The traffic is asymmetric and the remote end can
possibly be congested (receive) at SCCP even though it is not
congested in the transmit direction.  So any assumption that
just because a node is receiving messages from a remote SCCP
that its not congested is foolish.  Also, querying subsystems
tend to be switches that have many subsystems active.  SCCP does
not detect transmit congestion, only receive congestion.  It is
easy for the switch to be congested for receive by other
subsystems.

In fitting with the standard congestion avoidance procedures at
SCCP, the SCCP-User is required to avoid sending messages below
the restricted importance level and the if the SCCP-User does
not do so, the SCCP is required to send additional N-PCSTATE
indications.

Also, it would also be foolish to hinge the design of SUA (and
SCCP for that matter) around only restricted SCCP Protocol Class
0, TCAP Operation Class 3 applications with a simple query
response pair.

I suggest reading the SS7 standards with regard to the required
response of SCCP-Users to the receipt of N-STATE and N-PCSTATE
primitives.

> However, it may be
> desirable for the SG to not route new traffic to a congested ASP.
> Therefore, we want to implement SCON from ASP to SG.  I see no need to
> burden the ASP with the affected PC if it is not necessary.  Let's make
> it optional just like so many other things are in the specification.
> 
> Congestion is detected WITHIN SCCP.  I'm not saying the application is
> detecting congestion.  I'm saying the SUA layer in the ASP is detecting
> congestion (implementation dependent) and sending an SCON to the SG (as
> specified in the SG).  I'm simply restating what is in the RFC.

If the ASP is going to implement an SCCP procedure, it must meet
the requirements of the SCCP layer, not simply an SCCP-User.  To
perfrom SCCP Management, the SCCP layer must know the SCCP-SAPs
(each including an MTP-SAP which includes a point code) of all
its users, as well as the SCCP-SAPs (including MTP-SAP including
point codes) of all of the concerned remote subsystems for each
local subsystem.  Otherwise it cannot perform simply management
far less congestion mangement.

So, if the ASP is going to send SCON to the SG, the ASP must
contain enought of the SCCP management layer at the ASP to
effect this SS7 management procedure, and therefore must also
known what point code it is signalling congestion for.  It is
fortunate that we made the Affected Point Code Mandatory in the
SCON message from ASP to SG to preclude an ASP from violating
its responsibilities with regard to congestion detection in the
same way that your SCCP-Users are violating their responsibility
in performing congestion avoidance in response to received
N-PCSTATE.

> 
> I don't know why you are equating an SCON ASP->SG with an N-PCSTATE
> request to the SCCP.  N-PCSTATE is an SCCP->User message.  

Because the AS is an SCCP-User.

--brian

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