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

From: "Richard Adams" <[email-masked]>
Date: Thu, 5 Dec 2002 11:52:22 +0100

Hello,
I agree with Kakual, and partially with Brian.  I agree with Brian about
the MTP behaviour for the international method. For this method, and
national ones without congestion priority, the only instance of the MTP
that retains information about congestion is the one that has its level
2 transmission/retransmission buffer congested. 
An MTP receiving TFC merely tells its local users about it, and they
start timers etc. to determine abatement. There is no primitive from the
MTP to users at nodes remote to the congestion to say when congestion
ends. There is also no need for the MTP to tell its local users when its
level 2 buffers become uncongested (although I need to look through the
SDL to be absolutely sure - but for the international method, the level
value isn't included in the MTP STATUS, so it at least can't tell the
users).
For the national option of congestion priority, where RCT can be used to
and through the node reporting congestion, the MTP at the node doing the
test knows when to reduce or stop the discard of messages. It does tell
its users when remote congestion abates
(Q.704 section 11.2.4 is
"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 (see 13.7) or an indication
of local signalling link congestion, or due to the signalling
route-set-congestion-test procedure (see 13.9) 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. Each user
then takes appropriate actions in order to stop generation of signalling
messages destined for the affected signalling point with congestion
priorities lower than the specified congestion status. Messages received
from the local level 4 with congestion priorities lower than the current
signalling route set congestion status are discarded by the Message
Transfer Part." 
And in the SDLS, TRCC tells TSFC in Fig.29a/Q.704 sheet 3 when
congestion status reaches 0, TSFC tells L4 about it being 0 in
Fig.34a/Q.704 sheet 2.

and Q.701 MTP-STATUS has 2 parameters, Affected DPC and Cause
The Cause parameter has, at present, four values:
i) Signalling network congested (plus optional level)
   The level value is included if national options with congestion
priorities or multiple
   signalling link states without congestion priorities as in
Recommendation Q.704 are
   implemented.	
ii) User Part Unavailability: unknown., etc.

And level can be 0.	
The text in Q.704 is definitive and takes precedence over SDL (and
Q.701).
My conclusion is that M3UA could send SCON(0), but it must be optional. 
Incidentally, in Q.701 there isn't an MTP-STATUS indication for
"restricted"!
Kind regards,
Dick Adams.
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 05 December 2002 05:50
To: [email-masked]
Subject: Re: [Sigtran] Another Congestion/SCON Question

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
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

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

Richard,

Pease see comments below.

Richard Adams wrote:                       (Thu, 05 Dec 2002 11:52:22)
> value isn't included in the MTP STATUS, so it at least can't tell the

Link congestion status is contained to HMCG in Figure 26a/T1.111.4 (or
Q.704).  The link congestions status is only checked in HMCG and action
is taken in RTCC which only either sends TFC or informs the user that
the congestion status *exceeds* the message priority.  Link abatement
is never indicated in the SDLs.

>> Each user then takes appropriate actions in order to stop generation of
>> signalling messages destined for the affected signalling point with
>> congestion priorities lower than the specified congestion status.

This excludes 0.  Also, Figure 34/T1.111.4 says "Stop signalling traffic to
conerned destination with message priority less than congestion status.
L3->L4" L4 cannot possibly stop traffic with message priority less than 0,
so no indication need be given.

What the text does NOT say is:

  Each user then takes action to restart traffic with congestion
  priorities equal to or greater than the specified congestion
  status.

regardless whether the congestion status is zero or not.  MTP-STATUS
signals congestion and not abatement.

> Incidentally, in Q.701 there isn't an MTP-STATUS indication for

DRST is only used in the dual SG as STP case where the ASP must perform
the HMRT function.  This is not pure backhaul.  In the pure backhaul
scenario, (and for MTP users), a restricted MTP-STATUS is never required
(because the MTP user does not do MTP routing).

At least we agree that SCON(0) delivered by the SG must be completely
optional.

--brian