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

Lincoln,

Haresign Lincoln wrote:                                                           (Thu, 06 Oct 2005 14:38:35)
> 
> [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. 

Don't use ASP->SG SCON for application flow control.

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

When used properly (for M3UA or SUA congestion), the SCON is only sent
in response to a received M3UA or SUA data message triggering the
congestion threshold.  These triggering messages always have both an
originating address and a terminating address that is available to
M3UA/SUA and the ASP.  These addresses are copied to the SCON when the
message triggers congestion.  The addresses are mandatory, and when the
SCON is used properly, the addresses are always available as the ASP,
regardless of configuration.

The addresses listed as mandatory in the SCON should not be made
optional because, if they are absent, the SG does not necessarily have
the information to interwork with the SS7 network (i.e. generate TFC,
SSC), leaving it only the option to discard the message in the event
that it is missing necessary addresses.

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

Yes, the SG is ultimately responsible for signalling congestion to the
SS7 network.  IMO ASP->SG SCON cannot help in that responsibility and is
not only optional, but largely purposeless.

Nodal TFC is necessary because SS7 links have no flow control built into
them.  Messages can be sent on SS7 signalling links at a rate faster
than the signalling message handling capacity of the signalling end
point.  Sending nodal TFC is the only option at the signalling end
point's disposal for end-to-end flow control when local signalling
message handling becomes overwhelmed.

SCTP, in stark contrast, has application flow control built into it.
The SCTP sender can send no more data that room is available in the
receiver's advertised receive window.  In this way, the message handling
capacity of the peer is constantly monitored and not exceeded.  Whereas
SS7 normally signals congestion when the signalling link capacity has
been exceeded (Q.704), SCTP signals congestion (send buffer occupancy)
when the handling capacity of the peer is exceeded.

This makes the M3UA and SUA SG capable of determining on its own when
the message handling capacity of any ASP is exceeded and permits it to
take actions toward the SS7 network on behalf of the ASPs and the AS
without ever needing to receive SCON from the ASP.  Nor does it even
need to audit an ASP.  (It strikes me as strange that any SG would want
to send DAUD to an ASP that isn't receiving messages due to congestion
anyway.)

All these things have been discussed a number of times both for M3UA and
SUA.  There are long ladders in the WG mail archives both before and
after release of the RFCs.  We always come back to the same points.

So ASP->SG SCON is OPTIONAL to send, the SG can ignore (or not) it if it
wishes, and it has questionable utility.

But if ASPs start sending it for application flow control, all SGs will
eventually ignore it.

--brian

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