Subject: Re: [Sigtran] Another Congestion/SCON Question

From: Tolga Asveren <[email-masked]>
Date: Wed, 4 Dec 2002 13:52:14 -0800 (PST)

Hi Mark,

The story acording to me is inlined below.

   Tolga
--- [email-masked] wrote:
> 
> 
> Tolga:
> 
> The case is this:
> 
> +--------+       SS7       +-------+    IP     
> +--------+
> |  Dest | -----------------| SGP|------------|  ASP 
> |
> |  1-1-1 |        link         | 2-2-2|    link    
> |  3-3-3 |
> +--------+                      +-------+           
>    +--------+
> 
> 
> *)  The ASP at 3-3-3 sends a MSU to 1-1-1, causing
> congestion at 1-1-1
> *)  The destination responds with a TFC.  The SGP at
> 2-2-2 is not keeping
[TOLGA] When 1-1-1 gets congested, it responds with
TFC, so I assume this is an ANSI network.
>      congestion status for 1-1-1 (i.e., not abating
> congestion - not
> sending RCTs
>      to 3-3-3).  The SGP receives the TFC, simply
> converts it into a SCON
> and
>      sends the SCON to the ASP at 3-3-3.
[TOLGA] At this moment SGP should also start route set
congestion set procedures, apart from sending SCON.
MTP3 also for SPMC (in the example for 3-3-3) is
terminated at SGP, i.e. relevant MTP3 procedures are
executed there. For non-backhaul case (for example for
the example you gave, where ASP and SGP have different
PC) this is not a good way of modelling IMO. That is
one of the reason, why I prefer a M3PA like protocol
for non-backhaul cases, which defines the peer-to-peer
relationship between two layer3 entities (that is
basically what SG-SG draft is about)
> *)  The ASP begins to audit the SGP at 2-2-2 for the
> congestion status of
> 1-1-1.
>      The SGP responds with only a DAVA/DRST/DUNA
> (the current availability
>      of the destination).
[TOLGA] As far as I understand -correct me if I am
wrong- you try to implement congestion test procedure
on ASP side. IMO that is not, what should be done,
this procedure should be implemented on SGP side.
> 
> If/when the congestion at 1-1-1 abates, how is the
> ASP notified (unless a
> procedure is implemented at the SG) other than a
> magic DAVA in response to
> an audit?  If the SG isn't maintaining congestion
> status of the 1-1-1
> destination, when it abates, if the ASP is auditing,
> it could keep on
> auditing until the cows come home since it has
> received no update to the
> congestion status of the concerned destination
> (1-1-1)..
[TOLGA] Like you have said, a procedure (congestion
test procedure as defined for MTP3) should be
implemented on SG, to test congestion status. When
congestion abates based on that procedure, SG will
send SCON(0) to ASP. In fact even if this procedure is
implemented on ASP (which IMO is not the correct
choice), based on the timer congestion level will be
decreased and eventually reach 0. But of course, this
migth lead to possible false abatements, because there
is no RCT counterpart from ASP to SGP (which is
totally correct IMO), so there is no chance to get
SCON as reply to an RCT like message, indicating that
congestion continues.
> 
> The upshot is that if the ASP receives a SCON
> indicating congestion for a
> concerned point code, it will need a SCON indicating
> the congestion has
> abated.  So the IG's statement about not requiring a
> SCON if the SG is not
> maintaining congestion status doesn't seem in order.
> 
> Regards,
> Mark Erickson
> 
> 

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Dec 2002 17:55:35 -0700

Tolga,

Tolga Asveren wrote:                (Wed, 04 Dec 2002 13:52:14)

<snip>
> send SCON(0) to ASP.
<snip>

Assuming that the SG could even generate it, what will
the ASP do with SCON(0)?  There is no primitive to send
this information to the MTP-User at the AS (see Q.701
primitive definitions and Q.704 SDLs).  The ASP has no
other procedure for which to use SCON(0).  What is the
point of sending it at all?  Certainly sending SCON(0)
must be completely OPTIONAL.

--brian

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

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 4 Dec 2002 18:00:28 -0800 (PST)

Brian,
--- "Brian F. G. Bidulock" <[email-masked]>
> Tolga Asveren wrote:                (Wed, 04 Dec
[TOLGA] Q.704 11.2.4 says
"In the case when the congestion status of a
signalling route set changes as a result of either the
receipt of a transfer controlled message relating to a
particular destination or an indication of local
signalling link congestion, or due to the signalling
route-set-congestion-test procedure an indication is
given from the Message Transfer Part to the local
level 4 informing it about the current congestion
status of the signalling route set."
Based on that paragraph, I would expect MTP3 to inform
user parts, when congestion status changes, so also
when congestion abates.
For ANSI case, otherwise how can user parts now about
abatement of the congestion?

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Dec 2002 20:07:11 -0700

Tolga,

Tolga Asveren wrote:                                                               (Wed, 04 Dec 2002 18:00:28)
> > Assuming that the SG could even generate it, what will the ASP do with
> > SCON(0)?  There is no primitive to send this information to the MTP-User
> > at the AS (see Q.701 primitive definitions and Q.704 SDLs).  The ASP has
> > no other procedure for which to use SCON(0).  What is the point of sending
> > it at all?  Certainly sending SCON(0) must be completely OPTIONAL.
>
> [TOLGA] Q.704 11.2.4 says "In the case when the congestion status of a
> signalling route set changes as a result of either the receipt of a transfer
> controlled message relating to a particular destination or an indication of
> local signalling link congestion, or due to the signalling
> route-set-congestion-test procedure an indication is given from the Message
> Transfer Part to the local level 4 informing it about the current congestion
> status of the signalling route set." Based on that paragraph, I would expect
> MTP3 to inform user parts, when congestion status changes, so also when
> congestion abates.

> abatement of the congestion?

In fact it does not.  Q.701 indicates that MTP-STATUS is only used to
indicated "congestion".  Also, in the Q.704 SDLs, there is never a case for
abatement: MTP-STATUS is only issued to user parts when congestion occurs.

This is for several reason, not the least being that the HMCG (link based
congestion) is never used to determine abatement, only congestion on a
selected link (statistical) basis.

When an MTP-User receives an MTP-STATUS congestion indication, it is expected
to withdraw traffic.  The MTP-User must, within the context of the MTP-User
application, determine the appropriate action or duration to withdraw traffic.
Reapplication of traffic upon an indication of abatement could easily result
in oscillations if the MTP-User did nothing to quench the simulus of the
traffic.  Also, the statistical nature of SS7 congestion procedures
stochastically determines the source of the overload and indicates overload to
that sender.

The RCT procedures just set the minimum standoff interval that an MTP user
will be kept from sending traffic; however, you should realize that the RCT
procedure are not applicable to local link congestion (see HMCG).

So, what did you expect the ASP to do with the SCON(0)?  Send MTP-STATUS
with "no congestion" indication to the MTP User?  There is no such
MTP-STATUS indication: just "congested" with an optional level.  So why
send SCON(0)?

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Dec 2002 21:46:44 -0700

Tolga,

I suggest you look at Q.714 Section 5.2.4 and Q.764 section 2.13 to see how
SCCP and ISUP deal with MTP-STATUS primitives.  SCCP uses a time-controlled
procedure to determine abatement (as abatement is not indicated by MTP) and
ISUP ignores MTP-STATUS(congested) altogether (relying on call timers to do
their job).

If you look at ANSI T1.113.4 Section 2.10A, you will see that ANSI ISUP also
ignores MTP-STATUS(congested) primitives.  ANSI T1.112.4 Section 5.3.6.6
says that MTP-STATUS(congested) is simply broadcast as N-PCSTATE to all local
concerned subsystems.

So, even if your MTP does send abatement indications against the SS7
specifications, there is not a user part that can do anything with the
indication, because they are not expecting it.  So, sending SCON(0) is
effectively useless for ASP/SG operation and cannot be required of an SG.

--brian

Brian F. G. Bidulock wrote:                  (Wed, 04 Dec 2002 20:07:11)