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

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 6 Oct 2005 10:21:48 -0400

Tolga,

[TOLGA]:Does anybody know the rationale behind sending SCON from ASP to
SG when ASP -not the M3UA layer of ASP but something else- is congested?

The rationale would be that the ASP is congested at the layer above M3UA
and you want to reduce or eliminate new traffic.  I can give you several
more concrete examples if you want them.  There are many reasons why an
ASP would want to indicate congestion.

> [lincoln]: Where is this documented?
[TOLGA]Probably nowhere in official documents, I happen to know about it
just because I could remember -hopefully correctly- the discussions
about whether SCON from ASP to SG should be allowed or not. Could be an
idea to mention about it somewhere.

And if the specs don't specify something, then it's not in the specs.
Period.  I don't think there is any getting around that one.  

Regards,
Lincoln

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tolga Asveren
Sent: Thursday, October 06, 2005 9:50 AM
To: [email-masked]
Subject: RE: [Sigtran] Congestion in M3UA/SUA and the use of the SCON

Lincoln,

> 1) The SS7 standards don't have a User Part Congested.  So what should

> the SG do in this case?
>
> [TOLGA]SCON from ASP to SG does not correspond to indicating user part

> congestion to MTP3. It is there to support the case where SG and ASP 
> have different PCs and M3UA layer of ASP gets congested. In that case,

> because M3UA layer of ASP is performing routing-like function for ASPs

> PC while selecting an outgoing SG, its congestion is considered as 
> signaling point congestion and to support Q.704 11.2.6 and ANSI 
> procedures, SCON from ASP to SG is sent.
>
> [lincoln] If is is there to only support the case where ASP and SG are

> different PCs, this should be documented.  And I don't know why you 
> say the M3UA layer gets congested.  Why not the application layer?
[TOLGA]It also could be the case that at the same time user parts are
congested as well, but from M3UA point of view we don't do anything
related with it (probably the rationale is following Q.704 11.2.8 User
Part Congestion, which states "There are no specific User Part
congestion control procedures defined in the MTP.") BTW, I just
rechecked RFC3332 and it talks about sending SCON from ASP to SG is
allowed if M3UA layer at ASP or ASP itself is congested. As far as I
remember the goal was to cover just the M3UA congestion at ASP -because
it performs certain MTP3 functionality when ASP and SG PCs are
different-.
Basically, I am a bit confused myself right now. Does anybody know the
rationale behind sending SCON from ASP to SG when ASP -not the M3UA
layer of ASP but something else- is congested?
>
> 2) If the DPC of the ASP and the DPC of the SG are the same, does the 
> SG take any action?
>
> [TOLGA]SCON from ASP to SG is not allowed for this case
>
> [lincoln]: Where is this documented?
[TOLGA]Probably nowhere in official documents, I happen to know about it
just because I could remember -hopefully correctly- the discussions
about whether SCON from ASP to SG should be allowed or not. Could be an
idea to mention about it somewhere.
>
> Regards,
> Lincoln
>
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, October 05, 2005 8:48 PM
> To: Haresign Lincoln
> Cc: [email-masked]
> Subject: Re: [Sigtran] Congestion in M3UA/SUA and the use of the SCON
>
> Haresign,
>
> Haresign Lincoln wrote:
> (Wed, 05 Oct 2005 15:08:30)
> >
> >    To whom it may concern:
> >
> >    Sorry for the long post:
> >
> >    There  seems  to  be some differences between M3UA and SUA 
> > relating
> to
> >    use of the SCON.  And the RFCs themselves are somewhat
> inconsistent.
> >
> >    Here is the SUA spec:
> >
> >    "1.5.6.  Congestion Management
> >    ....
> >    The  SUA  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."
> >
> >    But later we have:
> >
> >    "3.4.4.  Signalling Congestion (SCON)
> >
> >    The  SCON  message  can  be  sent  from  the  SG  or relay node 
> > to
> all
> >    concerned  ASPs  to  indicate  that  the  congestion  level in 
> > the
> SS7
> >    network to a specified destination has changed."
> >
> >    No mention that the SCON can be sent TO the SG from a concerned
> ASP.
> >
> >    Questions:
> >
> >    1) why the inconsistency?
>
> What inconsistency?  The passages are supplemental not contradictory.
> Would you prefer that they be overlapping and redundant?
>
> >
> >    2)  The  RFC  indicates for the SCON that the "affected point
code"
> is
> >    mandatory.   But  if the ASP is sending it to the SG, there may
not
> be
> >    an affected point code?
>
> I don't think so.  There is always an affected point code.  There are 
> no disembodied subsystems in SCCP.  So, for example, if your HLR is an

> ASP and you are indicating congestion in subsystem 5, then the 
> affected point
> code(s) are the point code(s) of the HLR.
>
> >
> >    3)  If the SG receives an SCON from an ASP, is the assumption 
> > that
> the
> >    whole SSN is congested, or just a single ASP with the AS?
>
> No, there is no assumption.  It is the responsibility of the SG to 
> determine how to correlate indications from the various ASPs in an AS 
> and to determine what SS7 messages, if any, need to be sent to the SS7

> network.  Specific behaviours might be mandated by National or 
> Regional standards bodies, bilateral agreement, or operator 
> requirements.  (Note that TTC SCCP for the longest time did not 
> support SCCP management messages at all.)
>
> If you check the ETSI SUA modifications, they might have provided more

> direction in this regard.  They did for M3UA.
>
> >
> >    4)  Should  we only assume that the entire AS is congested (the
> entire
> >    SSN is congested) if all ASPs are congested?
>
> Up to you.  For a load-shared AS, it would be the normal case that a 
> single ASP indicating congestion is shortly ahead of all the others 
> indicating congestion as well.  Unless, perhaps, you have one of your 
> "stuck" ASPs.
>
> The problem that I have always had with ASP to SG SCON, whether it be 
> SUA or M3UA is that the SG has at its disposal all of the mechanisms 
> necessary to determine congestion towards the ASP without ever having 
> to receive a SCON from an ASP.  Another problem is that there is no 
> primitive interface described for SCCP that permits one of its users 
> (the AS) to indicate congestion to the SCCP provider (the SG).  SCCP 
> (the SG) monitors congestion on its own using (of course) 
> implementation dependent methods.
>
> >
> >    5)  What  actions should the SG take if a single ASP is congested
> in a
> >    set of ASPs?
>
> The RFC does not place any requirements on SG design in this regard.
> ETSI TS 102 443 says that Q.714 congestion procedures are followed if 
> the SG determines that the endpoint is congested.
>
> Well, if a significant portion of the AS's traffic handling capacity 
> is congested, the whole AS is certainly congested.  At some point it 
> is necessary to indicate congestion to originators of traffic so that 
> they can take appropriate actions and not send messages unlikely to be

> processed, possibly further congesting the SS7 network, or possibly 
> further impairing the endpoint's ability to process messages.
>
> Any method chosen should include the hysteresis-loss concept whereby 
> the abatement level for congestion is placed lower than the level for 
> onset within each congestion band.
>
> >
> >    6)  Should  the  SG  somehow monitor or time the congestion so 
> > that
> we
> >    don't get in a permanent congested state?  This is what is done 
> > in
> SS7
> >    SCCP Congestion Management.
>
> An SS7 node does monitor (dual timer approach).  Other ASPs can 
> monitor with DAUD.  IPSPs can monitor with DAUD.  At least in M3UA's 
> case, and probably SUA too, the SG does not need to monitor congestion

> status send as SCON from ASP to SG.  Such things just trigger a 
> congestion message (TFC in M3UA's case).
>
> >
> >    Then when reviewing M3UA (the latest Bis document):
> >
> >    "1.3.2.3 Interworking with MTP3 Network Management Functions
> >
> >    ...
> >    The  M3UA  layer  at  an ASP may also indicate to the SG that the
> M3UA
> >    layer itself or the ASP or the ASP's Host is congested."
> >
> >    "1.4.6 Congestion Management
> >
> >    ...
> >    The  M3UA  layer at an ASP or IPSP MAY indicate local congestion 
> > to
> an
> >    M3UA  peer  with  an  SCON  message.  When an SG receives a
> congestion
> >    message  (SCON) from an ASP, and the SG determines that an SPMC 
> > is
> now
> >    encountering  congestion,  it MAY trigger SS7 MTP3 Transfer
> Controlled
> >    management   messages  to  concerned  SS7  destinations
according
> to
> >    congestion procedures of the relevant MTP3 standard."
> >
> >    Questions:
> >
> >    1) The SS7 standards don't have a User Part Congested.  So what
> should
> >    the SG do in this case?
>
> The SCON message does not have an affected user part in it.  It has 
> affected point codes.  When an ASP sends a SCON to the SG it is 
> indicating that the each entire affected point code is congested.
>
> >
> >    2)  If the DPC of the ASP and the DPC of the SG are the same, 
> > does
> the
> >    SG take any action?
>
> ASP point codes are always "hosted" at an SG (or at two or more SGs).
>
> The SG deterimnes whether a signalling point is congested and issues 
> the appropriate SS7 messages according to whichever SS7 standard it 
> must conform to.
>
> >
> >    3) Should the SG monitor congestion of ASPs as mentioned above.
>
> The SG does not monitor or maintain congestion state for local 
> congestion at an ASP that triggered the SCON in the ASP ot SG
direction.
> A TFC may be issued for each affected point code in the SCON and sent 
> to the concerned point code, if the SG determines that the endpoint is

> congested and wishes to send TFC.  Note that in ANSI networks when the

> SG is an STP, TFR is also an apporpriate response, given that the SG 
> determines that there is "danger of congestion".
>
> >
> >    And now a general set of questions/comments
> >
> >    1)  This  is  one of the areas that I would include as a 
> > deficiency
> in
> >    the  current  RFCs that needs to be addressed (see previous
> threads: "
> >    Message loss in SIGTRAN networks"; "recommendations for M3UA/SUA
> BEATs
> >    when running overSCTP")
>
> Really?  This is one of the few areas that I think is not deficient.
> All the protocol mechanisms (even ones of questionable utility) are 
> available to the SG implementation to meet a wide range of varying 
> requirements imposed by numerous national SS7 standards upon a 
> deployment.
>
> One particularly reason for avoiding to place requirements on the SG 
> visa vi its interaction with the SS7 network, is that SS7 conformance 
> and compliance is definitely outside the scope of the specifications.
> Certainly there is enough industry experience to properly implement 
> SS7 stacks on the SG without the M3UA or SUA specifications presuming 
> to place requirements on SS7 stacks.  The scope of the M3UA and SUA 
> specifications are the IP network interactions.  The only reason that 
> the SS7 network is mentioned at all in these passages was because Greg

> thought that it would improve understanding while not restricting SS7 
> implementation.
>
> >
> >    2) It might be possible to implement some advanced congestion
> handling
> >    in  the SG.  Some of the following is only relevant to M3UA or
SUA.
> I
> >    leave  it  up  to  you  to  figure  that out.  For example, based
> upon
> >    congestion  level  we  could  reduce  traffic as indicated in the
> SCCP
> >    Congestion  procedures.   We  could  only route high priority
> messages
> >    (priority  in  ANSI  messages), we could discard new dialogs
> (although
> >    this  would require peaking in SCCP data) or only route new 
> > dialogs
> to
> >    non-congested  ASPs.   Given a few more moments, I could probably
> come
> >    up  with  a  few  more.   Anyway,  I'm  not  sure  if we would
want
> to
> >    standardize  this,  or  leave  it up to implementors to make 
> > their
> SGs
> >    more feature rich then the competitors.
>
> The ETSI documents (TS 101 142, TS 101 143) require that such 
> congestion handling procedure be implemented and in accordance with 
> Q.704 and Q.714
> (modified) specifications.  A detail that we could not require in the 
> UA specifications and yet keep the specification independent of SS7 
> protocol variant.
>
> For example, if you look the BT PNOC documents, you will see a 
> completely different perspective on congestion control, particularly 
> for ISUP and MTP.
>
> --brian
>
>
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
>

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

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

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 6 Oct 2005 10:15:26 -0400

Lincoln,

> From: Haresign Lincoln [mailto:[email-masked]]
> Sent: Thursday, October 06, 2005 10:22 AM
> To: Tolga Asveren; [email-masked]
[TOLGA]I am not saying, congestion status of ASPs is useless on SGs for
reasons other than following MTP3 proceure, but till now the strategy was to
keep SGP-ASP interface as much as possible similar to MTP3/MTP3-User
interface, which does not have congestion indications downstream. It is
foreseen that SCTP congestion indications need to be used to detect that
type of ASP congestion, i.e. congestion of ASP as MTP3 User Part. There are
points I don't agree with that strategy -relaying on SCTP congestion
indications for this purpose- but this is another discussion.
> Period.  I don't think there is any getting around that one.
[TOLGA]There is a difference between that something is forgotten to be
mentioned on the specifications or that it was not meant to be there. To my
knowledge, here we have the first case but I hope somebody else can confirm
that as well.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Oct 2005 11:53:56 -0600

Haresign,

Haresign Lincoln wrote:                                                           (Thu, 06 Oct 2005 10:21:48)
> ASP would want to indicate congestion.

User part (and subsystem) applications must use their own measures for
flow control within the user part (and subsystem).  These things are for
SS7 network and protocol congestion, not application congestion.

> Period.  I don't think there is any getting around that one.  

ANSI T1.111.4/2000 specifies the conditions under which an SS7
signalling point can send a "nodal TFC" as a result of the congestion of
the Signalling Message Handling function.  The SS7 documents are
Normative.  SCON in the ASP->SG direction was intended to provide a
protocol mechanism to allow "nodal TFC", primarily in the multiple SG as
STP case (similar to DRST which is also only used in the mutliple SG as
STP scenario).

It has no other use.  As "nodal TFC" itself is optional to send in SS7,
SCON ASP->SG must obviously be optional in M3UA/SUA.  Also, because the
SG is responsible for policy towards the SS7 network (and other MTP- or
SCCP-Users), the SG does not need to respond to it or take any action on
it whatsoever, unless it wishes to.

If you cannnot figure out how to use it don't.  Nobody is requiring you
to use it.

If you would like someone to design your SG for you, do no expect the
specification to do so.

--brian

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