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

From: [email-masked]
Date: Fri, 24 Aug 2001 15:11:14 +0300

Hi all,

I think Brian's comments are correct.  I have changed:

 	"SCCP-STATUS primitive"
 	
in the text simply be replaced with
 
 	"appropriate SCCP primitive (e.g. N-INFORM, N-NOTICE)"

The section is explanatory, and does not set implementation
requirements.

best regards,
John

> -----Original Message-----
> From: ext Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 16 August, 2001 21:36
> To: sigtran
> Subject: Re: [SUA issue 22] Flow Control and Congestion Management
> 
> 
> John, Amish,
> 
> Please see comments below...
> 
> John Loughney wrote:                                         
> (Thu, 16 Aug 2001 20:34:23)
> > 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].
> > ============================
> 
> 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.
> 
> > 
> > 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.
> > ============================
> > 
> 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/
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

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