Subject: RE: [Sigtran] Congestion in M3UA/SUA and the use of the SCON

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 6 Oct 2005 14:51:56 -0400

Brian,

OK, the SUA layer on the ASP detects congestion towards the application
layer.  It should generate a SCON. The SG should take implementation
specific actions.

For example, in our case, we can optionally not direct new traffic to a
congested ASP.  This works quite well in a query/response type of
application.  I suppose we can make our SGs as intelligent as we want
and still operate within the norms of the RFC. 

No matter what, the SCON from the ASP is in the spec as a justified
procedure after years of getting the RFC through acceptance.  I don't
think we should remove it now because it doesn't apply to the way that
some people are implementing their architectures.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Thursday, October 06, 2005 2:00 PM
To: Haresign Lincoln
Cc: Tolga Asveren; [email-masked]
Subject: Re: [Sigtran] Congestion in M3UA/SUA and the use of the SCON

Lincoln,

Haresign Lincoln wrote:
(Thu, 06 Oct 2005 10:50:33)
> Tolga,
> 
> Here is one example of why you have SCON as opposed to detecting it at

> the SCTP level.  An ASP may detect congestion.
> 
> Let's say that we are implementing an SMSC and the ASPs know that they

> can only handle a certain load based upon the speed of accessing their

> database.  And let's say that the ASP detects some congestion while 
> accessing it's database.  It might want to indicate back to the SG 
> that it doesn't want to receive new transactions.  So it would send an

> SCON to the SG.
> Regards,
> Lincoln

In this case, new transactions should be aborted by the application,
with U-abort cause indicating database congestion, not returned with
P-abort cause SCCP network congestion.  The application is perfectly
capable of rejecting new transactions.  It is only when there is
congestion toward the signalling point or subsystem that congestion
should be signalled.

So, for example, when ISUP encounters call congestion, it signals ACC
and releases IAMs.  It does not send SCON to the SG.

--brian

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

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Oct 2005 04:44:01 -0600

Lincoln,

Haresign Lincoln wrote:                       (Thu, 06 Oct 2005 14:51:56)
> layer.  It should generate a SCON. The SG should take implementation

The SUA layer at the ASP also has immediately at its disposal all the
addresses necessary to complete the mandatory address fields in the SCON.

> and still operate within the norms of the RFC. 

You might not be able to redirect traffic if TID labelling is in effect.
Also, unless you are running the entire transaction state machine at the
SG (which would defeat the point of backhauling to an ASP), you cannot
distinguish new from old traffic.  When redirecting anything, the
procedures of the CORID draft are applicable.

> some people are implementing their architectures.

Any optional behaviour not used by more than one implementation will be
dropped when the spec advances from Proposed Standard.  That is why we
don't really worry too much about optional behaviour at this point.  We
are far more interested in required behaviour necessary for
interoperability (also security and protection of the Internet).

--brian

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