Subject: RE: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2

From: Tolga Asveren <[email-masked]>
Date: Thu, 7 Nov 2002 14:31:34 -0500

> Tolga,
> 
> It makes little difference if the ASP sends SCON in response to the
> very message which causes the congestion, or in response to every
> message which encounters congestion.  The SG can still perform its
> function.
> 
> --brian

Consider the following configuration:

 AS1:1-1-1  AS1:1-1-1           AS1:1-1-1
   +------+ +------+           +------+
   | ASP1 | |ASP2  |           |ASPn  |
   |      | |      |           |      |
   +---+--+ +-----++ . . . . . +--+---+
       |          |               |
       |          |               |
       |          |               |
       |          |               |
       |          |               |
       |          |               |
       |          |               |
       |          |               |
       |       +--+---+           |
       |       | SG1  |           |
       +-------+      +-----------+
               +------+ 

SG is loadsharing for AS1 between n ASPs. Now let's consider only ASP2 is
congested. It will reply with SCON for an incoming message but in fact SPMC
is not congested. The correct behavior I would expect is, ASP2 informs that
it is congetsed to SGP, when it gets congested and SG does not send messages
to it but continues to loadshare to the remaining ASPs. Like SG combines
SPMC view for availability/unavailability, IMO the same should apply for
congestion. This can be achieved only, if ASPs informs congestion when it
happens. 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 7 Nov 2002 12:48:01 -0700

Tolga,

Without a changeover/changeback or controlled rerouting procedure it would be
very foolish for an SG to change its loadsharing based on a received SCON.
Frankly, even *with* a rerouting procedure it would be very foolish for an SG
to change its loadsharing based on congestion whatsoever.  The possibilities
for thrashing and scattering messages within an SLS is boundless.

ANSI T1.111.4/Q.704 only allow use of the transfer restricted procedure in
response to congestion in very narrowly defined situations (congestion on
C-links and nodal congestion at an STP); and this is not one of them.

The situation you describe is analogous to signalling links in a link set.
When a signalling link in a link set is congested, the SS7 approach is to use
the transfer controlled procedure and to discard messages with a priority
lower than the congestion discard level.  Changeover between signalling links
is not triggered by congestion until the signalling link fails.

The "nodal" TFC procedures that SCON was intended to parallel do not permit
transfer-restricted or change in routing procedures as a result of "nodal" TFC
when routing to a SEP.

Therefore IMO it is rather moot whether the ASP's use of SCON permits this or
not.

--brian

Tolga Asveren wrote:                                  (Thu, 07 Nov 2002 14:31:34)

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