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

Haresign,

Haresign Lincoln wrote:                                                           (Thu, 06 Oct 2005 09:48:07)
> Brian/Tolga,
> 
> I appreciate your feedback.  Some of your points are valid, but I have
> some questions relating to some of the other points.  Here is my
> feedback relating specifically to some of the points that you responded
> to:
> 
> > 
> >    1) why the inconsistency?
> 
> [brian] What inconsistency?  The passages are supplemental not
> contradictory.  Would you prefer that they be overlapping and redundant?
>  
> [lincoln]: I would prefer that the specification was clear.  Apparently
> Tolga had a different interpretation and some of my colleagues also had
> different interpretations.  I would have to surmise that perhaps there
> is a shortcoming in the specification.  In our reading of the
> specification, it is not clear on this point as MOST of the discussions
> about SCON talk about SG->ASP and not the other way around.  Therefore,
> the fact that it is not mentioned in 3.4.4 makes me wonder about the
> inconsistency.  In all the other sections that describe messages, it
> describes them in full.  In 3.4.4, it seems that we only have 1/2 a
> description.  I don't mind a little overlap.  There is certainly overlap
> in other sections, why skimp on this section?

Talk to the editors.  I cannot help with stylistic changes.  Please
propose new text.

> 
>  
> >    2)  The  RFC  indicates for the SCON that the "affected point code"
> is
> >    mandatory.   But  if the ASP is sending it to the SG, there may not
> be
> >    an affected point code?
> 
> [brian] I don't think so.  There is always an affected point code.
> There are no disembodied subsystems in SCCP.  So, for example, if your
> HLR is an ASP and you are indicating congestion in subsystem 5, then the
> affected point
> code(s) are the point code(s) of the HLR.
> 
> [lincoln]: There may be an affected point code, but the ASP in SUA may
> not be aware of it.  Therefore it should not be a mandatory requirement.
> SUA does not require the ASP to be aware of any point codes.  An ASP
> needs to be aware of it's SCCP address which could be a global title.  

It is optional to send the message.  If the ASP cannot complete its
parameters it cannot send it.

> 
> [brian] The problem that I have always had with ASP to SG SCON, whether
> it be SUA or M3UA is that the SG has at its disposal all of the
> mechanisms necessary to determine congestion towards the ASP without
> ever having to receive a SCON from an ASP.  
> 
> [lincoln]: There could be congestion at the application layer and we
> want to reduce traffic to the ASP.  So the ASP needs to send an SCON to
> the SG telling the SG to reduce or elimate new traffic.  

That is not the purpose of ASP->SG SCON.  ASP->SG SCON indicates congestion
of the SMH function in MTP for a point code and congestion towards an SCCP
Subsystem in SCCP.  As Tolga indicated, it is needed to support SS7 interworking
only in the multiple SG as STP scenarios.  It is not intended for indicating
SCCP User application internal congestion.  The SCCP User (e.g. TCAP) should
use its own congestion methods for that (e.g. ACG for INAP).  These messages
as their SS7 counterparts are for managing congestion in the SS7 network,
not for application flow control.

> 
> 
> [brian] the SG does not need to monitor congestion status send as SCON
> from ASP to SG.  Such things just trigger a congestion message (TFC in
> M3UA's case).
> 
> [lincoln]: My concern here is that if the ASP indicates that it is
> congested (SCON:ASP->SG).  And then after some time it indicates that it
> is not congested, but the SCON is lost (and this is possible if an
> assocation fails between an ASP and an SG that is implemented with
> several SGP), then we have a case of permanent congestion.  I would
> propose that the SG keeps a timer towards the ASP just like it keeps a
> timer towards the SS7 network when a TFC is received.

You missed the rest of my response: the SS7 endpoint will monitor, the
other ASPs will use DAUD, and IPSPs will use DAUD.  Monitoring is done
by the endpoint, not by the SG.  There is no need to place this requirement
on the SG, because the endpoint must monitor.  Also, endpoints use dual
timer methods, so they do not even send special messages.

> 
> 
> [lincoln]: with regards to M3UA, you are saying that if an ASP is
> congested, the entire Point Code is congested.  I guess we have to live
> with this due to the fact that there is no User Part Congested in the
> SS7 standards.  
> 
> 1) The SS7 standards don't have a User Part Congested.  So what should
> the SG do in this case?   
> 
> [TOLGA]SCON from ASP to SG does not correspond to indicating user part
> congestion to MTP3. It is there to support the case where SG and ASP
> have different PCs and M3UA layer of ASP gets congested. In that case,
> because M3UA layer of ASP is performing routing-like function for ASPs
> PC while selecting an outgoing SG, its congestion is considered as
> signaling point congestion and to support Q.704 11.2.6 and ANSI
> procedures, SCON from ASP to SG is sent.
> 
> [lincoln] If is is there to only support the case where ASP and SG are
> different PCs, this should be documented.  And I don't know why you say
> the M3UA layer gets congested.  Why not the application layer?

Because it corresponds to SS7 network congestion, not user application
flow control.  It is not described in great detail because its use is
optional.  RFCs describe mandatory requirements in greater detail and
optional ones less so.

> 
> 2) If the DPC of the ASP and the DPC of the SG are the same, does the SG
> take any action?  
> 
> [TOLGA]SCON from ASP to SG is not allowed for this case
> 
> [lincoln]: Where is this documented?

The SG is not required (by the specification) to take any action whatsoever.
It may or may not as it choses.  Tolga's preference here is to not take
any action.  My preference is to determine locally at the SG whether the
endpoint (subsystem) is congested and act accordingly.  You can see from his
document that Kamesh wants to go much farther.

When your application is congested, please use application level flow
control and leave SCCP/SUA congestion to SCCP/SUA.

Again, the SG can monitor its send buffer depth or message lifetimes towards
the ASP.  This can be used by the SG for congestion control.  Use of the
SCON from ASP->SG could be useful for indicating a MTP/M3UA or SCCP/SUA
congestion condition toward the ASP but its use is completely OPTIONAL and
responding to it at an SG is completely OPTIONAL.

--brian

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