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

Brian,

For now, I'm willing to accept what you say regarding SCON and M3UA.  My
initial concern over SCON was mainly relating to SUA.  

Are you saying that SCON for SUA towards the SG is not a valid
procedure?  I'm a little confused because I seem to be reading different
things from your email.

If SCON ASP->SG is valid, then we should remove the mandatory affected
PC and make it optional for the following reason:

1) An ASP is only required to know it's calling address.

2) It's calling address could be a global title.

3) If GTT is being done in the SG as discussed in the RFC, then the SG
is capable of converting the GT to a DPC/SSN.  

Therefore, the SG can generate the SSC which is a valid procedure in the
SS7 networks.  I think in the case of ASP->SG, the source address might
be a more appropriate mandatory field.

The RFC states this is a valid procedure.  It is possible for the SUA
layer to experience congestion _towards_ the application (the
application is not experiencing congestion...the SUA layer is
experiencing a queueing problem towards the application).

The RFC states that the SUA layer may indicate local congestion to an
SUA peer through the use of an SCON.  So if I want to utilize this
feature, I would like the affected DPC to be optional because the ASP
may not know it's DPC.  And the SG has the knowledge to convert the
source address to a DPC/SSN and send an SSC as an optional procedure.

Regards,
Lincoln



-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Friday, October 07, 2005 6:15 AM
To: Haresign Lincoln
Cc: Tolga Asveren; [email protected]
Subject: Re: [Sigtran] 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/

______________________________________________________________________
  This email message has been scanned by PineApp Mail-Secure and has
been found clean.