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

From: [email-masked]
Date: Thu, 5 Dec 2002 10:20:08 +0530

Hi
     SCON(0) is meaningful only when concerned SG is behaving as SEP that too
only in national option with priority. In that case SG maintains routeset
congestion status, and provisions congestion by RCT procedures defined in MTP3
Q.704. So whenever routeset congestion status reaches 0 SCON(0) can be send to
concerned AS's. If SG is behaving as STP local congestion status is maintained
at link level only and SCON in this case will be send if received MSU selects
the congested link, so SCON(0) makes no sense here.

Regards
Kamesh

"Brian F. G. Bidulock" <[email-masked]> on 12/05/2002 08:52:11 AM

Please respond to [email-masked]

To:   Tolga Asveren <[email-masked]>
cc:   [email-masked] (bcc: Kamesh Kaul/HSS)

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

Tolga,

Tolga Asveren wrote:
(Wed, 04 Dec 2002 18:00:28)
> Brian,
> --- "Brian F. G. Bidulock" <[email-masked]>
> wrote:
> > Tolga,
> >
> > Tolga Asveren wrote:                (Wed, 04 Dec
> > 2002 13:52:14)
> >
> > <snip>
> > > [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.
> > <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.
>
> [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?

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

--
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
_______________________________________________
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: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 5 Dec 2002 00:53:24 -0700

Kamesh,

Wrong on both points.  Both SEPs and STPs keep congestion status
on both links and route sets (but links only on a per-link basis).
In both SEPs and STPs, RCT procedure is used for abatement on
route set congestion, and in neither SEPs nor STPs does the MTP
signal abatement to its users, nor can MTP Users do anthing with
an abatement signal even if an AS was to signal abatement.

Therefore, SCON(0) is never necessary and makes no sense in either
SEP or STP SGs.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 5 Dec 2002 01:26:26 -0700

Kamesh,

Q.704 13.9.1 says: "The signalling-route-set-congestion-test procedure
is used at an originating signalling point to update..."

Both SEPs and STPs can be "originating signalling points".  In fact,
all signalling points are originating signalling points.  This just means
that the recipient of the TFC is responsible for the RCT procedure (as
reflected in Figure 46a/Q.704, Figure 26a/Q.704 and Figure 46b/Q.704).

So your statement that STPs do not perform RCT or keep congestion status
of routesets (below) is incorrect.

> > If SG is behaving as STP local congestion status is maintained

On the other hand, SEP's also keep congestion status on a link basis,
for which abatement is not determined (see HMCG state machine in Q.704).

Also, below which users are this that your say does not provision congestion
timers (or rely on MTP responsive MTP-STATUS) to determine abatement?
Not Q.714 SCCP, not Q.764 ISUP, not T1.112 SCCP, nor T1.113 ISUP.  Which
users are you talking about?

--brian

On Thu, 05 Dec 2002, [email-masked] wrote:

> 
> 
> Hi
>      Brian check section 13.9 of Q.704 to see were RCT procedure is
> applicable.Also for STP behaviour under congestion check section 3.8.4 of Q.704.
> SCON(0) i feel may be meaningful for MTP3 users which do not provision
> congestion by using timers that too only in national networks with priority, to
> let user know that it can now send MSU's of any priority.
> 
> Regards
> Kamesh
> 
> 
> 
> 
> "Brian F. G. Bidulock" <[email-masked]> on 12/05/2002 01:19:31 PM
> 
> To:   Kamesh Kaul/HSS@HSS
> cc:   [email-masked]
>