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

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

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

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

Lincoln,

> -----Original Message-----
> From: Haresign Lincoln [mailto:[email-masked]]
> Sent: Thursday, October 06, 2005 10:22 AM
> To: Tolga Asveren; [email-masked]
> Subject: RE: [Sigtran] Congestion in M3UA/SUA and the use of the SCON
>
>
> 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.
[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.
>
> > [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.
[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.
>
> 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

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

---

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

Lincoln,

> Sent: Thursday, October 06, 2005 10:51 AM
[TOLGA]Agreed. As I said below, I am also not happy to rely on SCTP
congestion for such cases because one can have I/O bound operations above
M3UA -your example- or M3UA and applications running on different CPU cards
etc., which wouldn't manisfest themselves as SCTP congestions -or not fast
enough- I just stated , the current way of operation according to M3UA
specification -using SCON for MTP3 congestion procedures and using SCTP
congestion indications for other needs like message distribution decisions-,
otherwise I agree with you on that issue.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Oct 2005 12:00:05 -0600

Lincoln,

Haresign Lincoln wrote:                                                           (Thu, 06 Oct 2005 10:50:33)
> it doesn't want to receive new transactions.  So it would send an SCON

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/