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

Brian,

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

[lincoln]: The specification says "The SUA layer at an ASP or IPSP MAY
indicate local congestion to an SUA peer with an SCON message."
Obviously, the detection of congestion is implementation dependent.
Whether you want to split hairs on application congestion versus SUA
congestion is a fine point.  It could be that the user informs the SUA
layer.  Or, perhaps there is a queue between the SUA layer and the
Application layer and that queue is being monitored.  It doesn't really
matter.  In any case, we want to reduce traffic towards that particular
case.  I'm just trying to make the point that ASP-SG SCON is a valid
procedure.  Same holds true for M3UA. 

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

[lincoln]: In my opinion, we are shortchanging ourselves.  I would
propose to make the DPC parameter optional in the case of ASP->SG SCON
as it is not always applicable.  Otherwise, only certain network
architectures can take advantage of the congestion feature and others
can't I will propose some alternate language.

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

> [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]: Yes, I read your response.  I'm assuming that if you are
operating in an ITU network with SubSystem Congestion, then the ASP
would generate an SCON and, if appropriate, the SG would generate an
SCCP SubSystem Congestion Message to concerned point codes in the
network.  So SSN Congestion is being "managed" on the SG since it is the
only entity that has knowledge of the congestion of all ASPs.  According
to the ITU specification, SCCP is supposed to generate an SSC message
upon receipt of every Pth message (P=8).  In order to do this, the SG
must manage congestion state of the ASPs and not leave it up to the
remote ends.  And if the SG is managing the congestion state, it is my
recommendation that we put a timer mechanism in the specification to
avoid problems of getting out of sync with the backend.

Another scenario is that we don't have connectivity to a certain remote
point code when we receive the SCON.  By managing the state in the SG,
it will allow us to send an SSC to the remote point code when it comes
back on line and starts sending us data.

I agree with you that ASP-SG SCON is completely optional.  However, if
we are going to specify a procedure for its use, let's see if we can
make it robust and possibly improve on all the good work that has been
done so far by the WGs.  The current RFCs are quite good.  The SIGTRAN
protocols were defined and deployed much faster than many protocols and
it is a credit to all that participated.  Our experience shows that the
SIGTRAN protocols are working well.  I also believe we can improve on
them.

Regards,
Lincoln


-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Thursday, October 06, 2005 1:40 PM
To: Haresign Lincoln
Cc: Tolga Asveren; [email protected]
Subject: Re: [Sigtran] 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/