Subject: [SUA issue 22] Flow Control and Congestion Management

From: [email-masked]
Date: Thu, 16 Aug 2001 20:34:23 +0300

Here's a new issue.  I'm on a few days vacation, so forgive my
delay in getting these out.

John

-----Original Message-----
From: ext Amish Chana [mailto:[email-masked]]
Sent: 16 August, 2001 19:04
To: Loughney John (NRC/Helsinki); [email-masked]
Subject: RE: SUAv7: Flow Control and Congestion Management

Hi John,

I suggest replacing the following paragraph with the subsequent two 
paragraphs. SCCP does not have a SCCP-STATUS primitive and Q.715 is very 
open on the specific actions to be taken.

The text in those paragraphs is similar to the text I proposed for M3UA - 
refer to the "Routeset congestion" thread around the end of July. I have 
made reference to Q.715 in this text, so could you please also modify the 
text in the references section from "Q.711-714" to "Q.711-715".

============================
>At an ASP or IPSP, the SUA layer indicates congestion to local SCCP-Users 
>by
>means of an SCCP-STATUS primitive, as per current SCCP procedures, to 
>invoke
>appropriate upper layer responses.  When an SG determines that the 
>transport
>of SS7 messages is encountering congestion, the SG MAY trigger SS7 SCCP
>Congestion messages to originating SS7 nodes, per the congestion procedures
>of the relevant SCCP standard. The triggering of SS7 SCCP Management
>messages from an SG is an implementation-dependent function.
>
---------------------------------
Due to the shared nature of the bandwidth in an IP environment, network 
congestion does not necessarily imply that the ASP is responsible for the 
congestion. When more than one association is present between an ASP and 
SGP, as illustrated Figures 1 and 2, and congestion is detected on only some

of the associations an ASP (or IPSP) may attempt to distribute some or all 
of the traffic from the congested associations onto alternative associations

where no congestion is present. SUA should later attempt to restore traffic 
on the affected associations after congestion has abated. The congestion 
change-over and change-back procedures are implementation dependant. These 
procedures should be implemented in a time-controlled manner to avoid the 
loss of messages, mis-sequencing of messages, excessive delays in message 
delivery and rapid oscillatory change-over and change-back procedures.

If congestion is detected across all or a majority of the associations
within a fixed period of time SUA SHOULD should take the appropriate SCCP 
congestion handling actions [ITU-T Q.715].
============================

For the following paragraph, I suggest replacing it with the subsequent text

- a small extension with wording equivalent to M3UA.
============================
>The SCCP layer at an ASP or IPSP MAY indicate local congestion to an SUA
>peer with an SCON message.  When an SG receives a congestion message (SCON)
>from an ASP, and the SG determines that an endpoint is now encountering
>congestion, it MAY trigger congestion procedures of the relevant SCCP
>standard.
----------------------------
The SCCP layer at an ASP or IPSP MAY indicate local congestion to an SUA 
peer with an SCON message.  When an SG receives a congestion message 
(SCON)from an ASP, and the SG determines that an endpoint is now 
encountering congestion, it MAY trigger Subsystem Congested messages to 
concerned destinations according to congestion procedures of the relevant 
SCCP standard.
============================

Regards,
Amish

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 16 Aug 2001 13:35:52 -0500

John, Amish,

Please see comments below...

John Loughney wrote:                                         (Thu, 16 Aug 2001 20:34:23)
> >At an ASP or IPSP, the SUA layer indicates congestion to local
> >SCCP-Users by means of an SCCP-STATUS primitive, as per current
> >SCCP procedures, to invoke appropriate upper layer responses.
> >When an SG determines that the transport of SS7 messages is
> >encountering congestion, the SG MAY trigger SS7 SCCP Congestion
> >messages to originating SS7 nodes, per the congestion procedures
> >of the relevant SCCP standard. The triggering of SS7 SCCP
> >Management messages from an SG is an implementation-dependent
> >function.
> >

While I agree that the quoted text is a little off (SCCP-STATUS
should be N-STATE?, and it is sent to SCCP management, not to
Users? N-INFORM is sent to CO SCCP users to signal congestion on
a connection section and N-NOTICE is sent to CL SCCP users to
signal congestion encountered by unidata when the return option
is set), I disagree with placing all this implementation dependent
text in the spec.  The current paragraph states "The triggering
of SS7 SCCP Management messages from an SG is an implementation-
dependent function." and that should be sufficient.

How an ASP deals with SCTP congestion is a purely implementation
dependent matter.  The procedures which Amish recommends can easily
cause problems in some configurations.  As neither SCTP nor SUA
address IP network congestion (out of scope), the recommendations
on a procedure to take in the event of IP network congestion are
also out of scope.

As a minor point, SCCP congestion handling is not the only procedure
that one might want to invoke in the event of IP congestion, because
SCCP is an MTP-User, the SG might also wish to invoke the Transfer
Controlled procedures and issue TFC for the point code for the
corresponding SCTP associations.  These are purely implementation
dependent matters given the current SIGTRAN scoping.

I suggest that

	"SCCP-STATUS primitive"
	
in the text simply be replaced with

	"appropriate SCCP primitive (e.g. N-INFORM, N-NOTICE)"

The text should be left explanatory, not make a recommendation.

> - a small extension with wording equivalent to M3UA.
Also in this case, subsystem congested messages are not the only
congestion message that the SG may wish to issue.  The SG may wish
to issue TFC.

I believe the text is better left as it is with the general
"congestion procedures".

--brian

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

---