Subject: RE: [Sigtran] M3UA congestion monitoring between a SG and an AS

From: "Zannin, Francois" <[email-masked]>
Date: Wed, 13 Feb 2002 17:39:11 +0100

Tolga,

My comments in the text.

Francois ZANNIN.

>
> Brian and Tolga,
>
> I don't think that there is a  problem when the congestion islocally detected
> by a lower level, like SCTP. In that configuration, the implementation can
> execute an action like sending MTP_STATUS to the user in the AS or consolidate
> the state of all members of a SPMC to send a TFC in the SG part.
>
> The problem I'm trying to evoke is when the congestion is remotely detected in
> the SG by the means of SCON messages received from the ASP. If the SG has to
> consolidate the state of congestion of all the members of the SPMC (congestion
> reported by SCON), it must be sure that it is always has up to date information
> about congestion states.
-[TOLGA] In my opinion even this case corresponds that the user parts of that
-SPMC are congested. For user part congestion, there are no MTP procedures
-defined. I don't think, SCON can be interpreted that ASP-M3UA is congested
-for the PC specified in Concerned DPC field. It does not make sense to me
-that ASP-M3UA itself is congested just for some part of traffic.
[ZANNIN]
My comments apply to a distributed platform made of several 
processes playing the role of ASP and SGP and communicating 
together by internal media.

A platform can host several AS playing different SP, SI... if one 
of these application is enter in congestion we cannot consider 
that the ASP are congested for all AS, so this mean that the ASP 
are "congested" just for one AS but not the others. The SCON can 
be sent from the ASP to the SGP for the concerned SP.

If the SG is considered as STP and an AS playing one SP is 
congested, the role of the SG is to send the TFC for the concerned 
SP but NO action the other AS (played SP)

>
> My issue is about an eventual lost of a SCON "level 0 in national option".
> In that case, the remote AS will stay congested and the consolidation at the
> SG may be erroneous.
>
-[TOLGA] More and more I think SCON from ASP to SGP is really not usefull.
-The only thing I can think of is, ASPs are working in override mode for an
-AS, and when SGP receives SCON for a specific AS from the active ASP, then
-it can activate the standby ASP. But in the draft, SCON is meant as a
-response for an incoming message. My opinion is to handle this case as user
-part congestion.
[ZANNIN]ASP working on override mode only, and one ASP per AS? if the 
congestion is due to the AS, changing of ASP will not change anything!

> We cannot rely on the SCTP congestion indication to handle congestion in a group
> of ASPs. If several ASPs serve several AS, in case of local congestion between
> ASP and ONE AS in the group of ASP, we cannot stop reading the SCTP connection
> in order to base  congestion handling on the SCTP congestion reported to the
> remote SGP.
> If an association is blocked, it is blocked for all AS served by this ASP.
-[TOLGA] I couldn't understand clearly what you mean exactly with "in case of
-local congestion between ASP and ONE AS in the group of ASP". Do you mean
-congestion of user part for traffic belonging to a specific AS?
[ZANNIN]Yes, Because of the process distribution, ASPs and ASs can have 
internal communication problem that cause temporary congestion for a specific AS

>
> For a configuration where several AS are served by several ASPs, we must be able
> to report the congestion for a specific AS to the SGP, and this
> is the role of the SCON.
-[TOLGA] So, we are reporting congestion of user parts, for which no MTP
-procedures are defined.
[ZANNIN]if the SG is playing the STP role, the procedure is to send the TFC.
The other solution is to omit these SCON and no congestion in national mode with congestion.

>
> The Role of TFC is purely informative in international or national options
> without congestion. In national with congestion mode, MTP must keep the state
> of congestion in order to be able to handle the RCT.
>
> A possible answer to this problem is to consider the lower transport layer (SCTP)
> reliable at 100% and SCON messages "ARE NEVER LOST"... in that case, this is a
> known problematic behavior of the M3UA transport layer! But that's the way it is...
>
> M3UA 1.4.6 also talks about the local congestion (not only SCTP but also other
> levels). Some implementations are more complicated than just two process and the
> internal M3AU stack can create local congestion other than at SCTP level.
-[TOLGA] Yes. When the user parts are congested, we don't have any problem,
-because there is no MTP3 procedure defined for this case. And apart from the
[ZANNIN]Unless the SG is considered as STP

-scenario I mentioned above (switching from congested active ASP to standby
-ASP) I don't think it is usefull to report user part congestion from ASP to
-SGP.
[ZANNIN]Maybe this is the solution?

-If ASP-M3UA itself is congested, then putting Concerned DPC field -or any
-other parameter- to SCON message seems useless. If M3UA is congested, it
-will be congested for all incoming/outgoing traffic.
[ZANNIN] An ASP and an AS congestion cannot be considered as the same thing.

-When ASP-M3UA congestion is reported (congestion of M3UA stack itself),
-important point is whether one is going to interpret is as user part
-congestion or signalling point congestion. Because the combined view of SPMC
-is managed on SGP, I would think MTP3 functionality for this SPMC is
-residing there and so I would say even ASP-M3UA congestion should be treated
-as user part congestion.
[ZANNIN]if the SG is playing a STP, the AS (SP consolidation) the congestion 
must be treated as SP congestion, and then send a TFC.

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 13 Feb 2002 14:05:04 -0500

Francois,

Please see comments below.

  Tolga

> -----Original Message-----
> From: Zannin, Francois [mailto:[email-masked]]
> Sent: Wednesday, February 13, 2002 11:39 AM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: RE: [Sigtran] M3UA congestion monitoring between a SG and an AS
>
>
> Tolga,
>
> My comments in the text.
>
> Francois ZANNIN.
>
> >
> > Brian and Tolga,
> >
[TOLGA] I agree that one can have different entities for user part handling
of traffic belonging to different ASs. But this just make the argument that
their congestion should be considered as user part congestion more valid.
What does not make sense to me is that M3UA stack itself on ASP side is
congested just for some part of traffic.
> congestion is due to the AS, changing of ASP will not change anything!
[TOLGA] No. Two ASPs for AS, one is active. But even for this scenario, the
more appropriate behaviour would be active ASP sends ASPIAC to SGP, then SGP
can send NTFY(AS pending) etc... If you have one distributed user part
entity over two M3UA stacks(two ASPs), and if your user part entity is
congested, of course changing ASP won't help too much. Otherwise it will
help.
> internal communication problem that cause temporary congestion
[TOLGA] There is no communication between ASPs and ASs. ASP is a physical
entity, AS is only a logical abstraction. It seems you think ASP as M3UA
stack and AS as user parts(?)
> national mode with congestion.
[TOLGA] In my opinion SCON from ASP to SGP shouldn't trigger TFC. Because it
corresponds to user part congestion. I am still looking to ANSI to figure
out the case (unfortunately mail archive of May2001 -which probably should
have discussions about this topic - is empty on ftp.ietf.org) which causes a
SEP to send TFC (which Brian has mentioned as the reason why SCON from ASP
to SGP was added)
> [ZANNIN]Unless the SG is considered as STP
[TOLGA] Still not. SPMC combined state is maintained on SGP (even if it acts
as STP), according to me it is better to think MTP3 functionality of SPMC
residing there, for cases related with management messages to be sent to SS7
network. So, for whatever reason SCON is sent from ASP to SGP, I would
interprete it as user part congestion.
> [ZANNIN]Maybe this is the solution?
[TOLGA] I tend to think so, but it is too late now to discuss and decide for
such changes.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 13 Feb 2002 13:11:44 -0600

Tolga,

This is the T1 reference if your looking for it.

> The T1.111.4 (ANSI MTP Level 3) states that a signaling end point may send
> TFC:
> 
> "13.7.1	The transfer-controlled procedure is performed at a signalling
> transfer point, and optionally at a signalling point, when it must notify
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> one or more originating signalling points that they should no longer send to
> the concerned destination messages with a given priority or lower."

All other specs only say that TFC is generated at an STP.

--brian

Tolga Asveren wrote:                                        (Wed, 13 Feb 2002 14:05:04)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 13 Feb 2002 14:43:19 -0500

Brian,

I checked ANSI92 it was not htere, but then I realized that it is added in
ANSI96. Thanks. In fact probably this corresponds to "Signalling
point/signalling transfer point congestion 11.2.6" in Q.704. But my point
was that any congestion on ASP side would be better interpreted as user part
congestion, instead of signalling point congestion. In such a case, I think
no TFC is necessary.

      Tolga

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, February 13, 2002 2:12 PM
> To: Tolga Asveren
> Cc: Zannin, Francois; [email-masked]
> Subject: Re: [Sigtran] M3UA congestion monitoring between a SG and an AS
>
>
> Tolga,
>

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 13 Feb 2002 16:06:06 -0500

Brian,

I think when SGs are functioning as STPs (regardless of the type of the
RKs), it is hard to decide where the MTP3 functionality of the point codes
of ASs is residing. If one thinks that MTP3 functionality for the ASs is on
the SGP -because it manages the combined view of the SPMC and for example
decides when to send TFA or TFP for it to SS7 network, even when the RK is
on PC granularity-one can think that any congestion on ASP is above MTP3 so
it is no more signalling point congestion. But I agree that this point is
open to discussion and current draft is satisfactory.

    Tolga

> Sent: Wednesday, February 13, 2002 3:35 PM
> To: Tolga Asveren
> There is still the corner case of SGs as STPs with full point-code
> routing key.  In this case, for ANSI96 one might want to allow the
> ASP to send SCON and use it to trigger TFC under ANSI96; but it is
> a corner case and even questionable in ANSI96.  Some operators do
> not allow it.  I do not think that M3UA needs any further explanation
> of the matter because it has mostly to do with ANSI SS7 a not IP
> and is fully out of scope (part of the NIF).
>
> --brian
>
> Tolga Asveren wrote:                                        (Wed,
> 13 Feb 2002 14:43:19)
> > Brian,
> >

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 13 Feb 2002 14:35:10 -0600

Tolga,

--brian

Tolga Asveren wrote:                                        (Wed, 13 Feb 2002 14:43:19)
> > 13 Feb 2002 14:05:04)

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