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

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

Brian/Tolga,

I appreciate your feedback.  Some of your points are valid, but I have
some questions relating to some of the other points.  Here is my
feedback relating specifically to some of the points that you responded
to:

> 
>    1) why the inconsistency?

[brian] What inconsistency?  The passages are supplemental not
contradictory.  Would you prefer that they be overlapping and redundant?
 
[lincoln]: I would prefer that the specification was clear.  Apparently
Tolga had a different interpretation and some of my colleagues also had
different interpretations.  I would have to surmise that perhaps there
is a shortcoming in the specification.  In our reading of the
specification, it is not clear on this point as MOST of the discussions
about SCON talk about SG->ASP and not the other way around.  Therefore,
the fact that it is not mentioned in 3.4.4 makes me wonder about the
inconsistency.  In all the other sections that describe messages, it
describes them in full.  In 3.4.4, it seems that we only have 1/2 a
description.  I don't mind a little overlap.  There is certainly overlap
in other sections, why skimp on this section?

>    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?

[brian] 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.

[lincoln]: There may be an affected point code, but the ASP in SUA may
not be aware of it.  Therefore it should not be a mandatory requirement.
SUA does not require the ASP to be aware of any point codes.  An ASP
needs to be aware of it's SCCP address which could be a global title.  

[brian] 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.  

[lincoln]: There could be congestion at the application layer and we
want to reduce traffic to the ASP.  So the ASP needs to send an SCON to
the SG telling the SG to reduce or elimate new traffic.  

[brian] 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).

[lincoln]: My concern here is that if the ASP indicates that it is
congested (SCON:ASP->SG).  And then after some time it indicates that it
is not congested, but the SCON is lost (and this is possible if an
assocation fails between an ASP and an SG that is implemented with
several SGP), then we have a case of permanent congestion.  I would
propose that the SG keeps a timer towards the ASP just like it keeps a
timer towards the SS7 network when a TFC is received.

[lincoln]: with regards to M3UA, you are saying that if an ASP is
congested, the entire Point Code is congested.  I guess we have to live
with this due to the fact that there is no User Part Congested in the
SS7 standards.  

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?

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?

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 6 Oct 2005 09:50:19 -0400

Lincoln,

> 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?
> [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.

---

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

Haresign,

Haresign Lincoln wrote:                                                           (Thu, 06 Oct 2005 09:48:07)
> in other sections, why skimp on this section?

Talk to the editors.  I cannot help with stylistic changes.  Please
propose new text.

> needs to be aware of it's SCCP address which could be a global title.  

It is optional to send the message.  If the ASP cannot complete its
parameters it cannot send it.

> the SG telling the SG to reduce or elimate new traffic.  

That is not the purpose of ASP->SG SCON.  ASP->SG SCON indicates congestion
of the SMH function in MTP for a point code and congestion towards an SCCP
Subsystem in SCCP.  As Tolga indicated, it is needed to support SS7 interworking
only in the multiple SG as STP scenarios.  It is not intended for indicating
SCCP User application internal congestion.  The SCCP User (e.g. TCAP) should
use its own congestion methods for that (e.g. ACG for INAP).  These messages
as their SS7 counterparts are for managing congestion in the SS7 network,
not for application flow control.

> timer towards the SS7 network when a TFC is received.

You missed the rest of my response: the SS7 endpoint will monitor, the
other ASPs will use DAUD, and IPSPs will use DAUD.  Monitoring is done
by the endpoint, not by the SG.  There is no need to place this requirement
on the SG, because the endpoint must monitor.  Also, endpoints use dual
timer methods, so they do not even send special messages.

> the M3UA layer gets congested.  Why not the application layer?

Because it corresponds to SS7 network congestion, not user application
flow control.  It is not described in great detail because its use is
optional.  RFCs describe mandatory requirements in greater detail and
optional ones less so.

> [lincoln]: Where is this documented?

The SG is not required (by the specification) to take any action whatsoever.
It may or may not as it choses.  Tolga's preference here is to not take
any action.  My preference is to determine locally at the SG whether the
endpoint (subsystem) is congested and act accordingly.  You can see from his
document that Kamesh wants to go much farther.

When your application is congested, please use application level flow
control and leave SCCP/SUA congestion to SCCP/SUA.

Again, the SG can monitor its send buffer depth or message lifetimes towards
the ASP.  This can be used by the SG for congestion control.  Use of the
SCON from ASP->SG could be useful for indicating a MTP/M3UA or SCCP/SUA
congestion condition toward the ASP but its use is completely OPTIONAL and
responding to it at an SG is completely OPTIONAL.

--brian

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

---

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

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 06 Oct 2005 09:50:19)
> ASP but something else- is congested?

To be precise, it should be as a result of "congestion of the Signalling Message
Handling function within M3UA at the ASP": congestion of the SMH function being
the only reason for sending so-called "nodal TFC".

--brian

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