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

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

Brian and Tolga,

I don't think that there is a  problem when the congestion is locally 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. 

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.

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. 

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. 

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.

Francois Zannin.

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

Francois,

Zannin, Francois wrote:                    (Tue, 12 Feb 2002 18:11:08)
> Tolga,
> 
> In M3UA 1.4.6, it is said That a SG on receipt of a SCON can trig 
> a TFC to the ss7 concerned DPC.

Well, it doesn't really say that.  It says:

 The M3UA layer is informed of local and IP network congestion by means 
 of an implementation-dependent function (e.g., an implementation-
 dependent indication from the SCTP of IP network congestion). 
 At an ASP or IPSP, the M3UA layer indicates congestion to local MTP3-
 Users by means of an MTP-STATUS primitive, as per current MTP3 
 procedures, to invoke appropriate upper layer responses.  

 The M3UA layer at an ASP or IPSP MAY indicate local congestion to an 
 M3UA peer with an SCON message.  When an SG receives a congestion 
 message (SCON) from an ASP, and the SG determines that an SPMC is now 
 encountering congestion, it MAY trigger SS7 MTP3 Transfer Controlled 
 management messages to concerned SS7 destinations according to 
 congestion procedures of the relevant MTP3 standard.

The SG only need send TFC when it determines that the SPMC is
encountering congestion (entire point code).  This is not the
AS.  This is the group of ASPs which an SG is represents as a
unique signalling point to the SS7 network for the purposes of
signalling network management.  SCON from an AS or ASP is only
one factor that "MAY" be used.

DAUD would be useless from SG to AS to audit congestion.  It
is also useless from AS to SG to audit congestion.  Congestion
states are neither maintained for local SPMC nor for remote
destinations (routesets).  TFC is sent purely responsive.
Just because an SS7 node has received TFC for a destination
does not mean that its MTP will stop sending messages at that
priority level.  MTP-Users are informed, however, MTP will
continue to transfer messages and the user will get repeated
MTP-STATUS indications indicating congestion.  MTP does not
keep congestion states.

As there is no congestion state to audit, a DAUD from SG to AS
would be pointless.  Sending DAUD from ASP to SG to audit
congestion state is also pointless as this state is not
maintained for SS7.

The SCON message from AS to SG is all but useless.  The SG has
other means at its disposal to determine congestion towards an
AS (e.g, SCTP congestion).  Flow control is best performed at
the MTP-User (e.g, SCCP flow control, ISUP congestion levels).
I requested that it be removed, and the resolution was to
place "MAY" and "could, for example", and a bunch of weak
words around it.

There is certainly no need to start putting more useless
protocol around this useless message.

It works like this: the SG determines whether an SPMC is
congestsed using implementation dependent functions.  It is on
this basis that the SG determines how to respond to RCT.  RCT
is not propagated in any way to AS.  An ASP "MAY" send SCON if
it wants, that might trigger TFC if the SG implementation
wishes to do so.  The SG is responsible for the MTP management
view towards the SS7 network with regard to the SPMC, not the
AS.

This is identical to SEP generated TFC in SS7.  Nothing more
is required.

--brian

> This ss7 DPC in national option then trig a RCT procedure (Q704 13.9). 
> What must be the behavior of the SG when it receive a RCT... must it 
> discard it (this is not compliant with the national option). If the 
> SG decide to reply to this RCT by a TFC, it must always be aware of 
> the state of congestion of the AS which is not local to the SG.
> 
> In the ss7 recommendation, it is possible to specify as implementation 
> dependant some behavior internal to a stack, but with M3UA, the AS and 
> the SG are separated by an IP network where M3UA is supposed to define 
> ALL messages exchanged between the entities.
> 
> Again in on my first remark, if the "end of congestion" SCON level 0 
> message is lost between the SG and the as, how can the SG request 
> "after a long time" if the AS is still congested, In order to answer 
> to the received RCT?
> 
> Francois.
> 
> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Tuesday, February 12, 2002 6:00 PM
> To: Zannin, Francois; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sigtran] M3UA congestion monitoring between a SG and an AS
> 
> 
> Francois,
> 
> m3uav12 3.4.4 says:
> "The SCON message MAY also be sent from the M3UA layer of an ASP to an M3UA
> peer indicating that the M3UA layer or the ASP is congested."
> In my opinion, M3UA layer congestion corresponds to Signalling
> point/signalling transfer point congestion(Q.704 11.2.6) and ASP congestion
> corresponds to User Part congestion(Q.704 11.2.8). No specific procedure is
> defined for those cases as can be seen in Q.704.
> So as pointed out by Brian, no RCT is necessary.
> 
>     Tolga
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Zannin, Francois
> > Sent: Tuesday, February 12, 2002 11:38 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [Sigtran] M3UA congestion monitoring between a SG and an AS
> >
> >
> > Brian,
> >
> > In the ss7 network, the RCT is used to test a possible route for
> > a SP specified in the RCT header message. If the route is not congested,
> > the final SP itself (The AS or the SG for the AS) discards the RCT.
> >
> > Now, if we consider (or not) the SG as a STP, when it receive a RCT for
> > a SP played by an AS, this SG must be able to reply by another TFC if
> > the AS is still congested (the SG has receive a SCON from this AS).
> >
> > If the SG is not able to have information about the AS congestion state,
> > how can it handle the RCT received from the ss7 network?
> >
> > My opinion is if a message is used to send the congestion information
> > from an AS to a SG, we must have a message to test from the SG if the
> > congestion problem still exists on the AS.At least if we need to be
> > compliant with the ss7 "national option with priority" congestion mode.
> >
> > Francois.
> >
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Tuesday, February 12, 2002 5:00 PM
> > To: Zannin, Francois
> > Cc: [email-masked]
> > Subject: Re: [Sigtran] M3UA congestion monitoring between a SG and an AS
> >
> >
> > Francois,
> >
> > The ANSI/ITU specs do not describe RCT in conjunction
> > with SP generated TFC, only in conjunction with routeset
> > congestion.
> >
> > --brian
> >
> > Zannin, Francois wrote:                    (Tue, 12 Feb 2002 16:42:05)
> > > Brian,
> > >
> > > The mechanism of congestion handling can (and is) implementation
> > > dependent but when some platform external messages must be exchanged
> > > between the nodes, these messages MUST be specified by the protocol.
> > > For the ss7 protocol, these messages are the TFC matching the SCON
> > > and the RCT that does not have any equivalent for M3UA.
> > >
> > > When the SG and the Asp are not developed by the same stack M3UA
> > > provider, we must be sure have a reference message to exchange in
> > > order to give the possibility to the SG to have information about
> > > the Asp congestion level. The same kind of stuff allowed by the
> > > DAUD message from the Asp to the SGp.
> > >
> > > Francois.
> > >
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Tuesday, February 12, 2002 4:08 PM
> > > To: Zannin, Francois
> > > Cc: [email-masked]
> > > Subject: Re: [Sigtran] M3UA congestion monitoring between a SG and an AS
> > >
> > >
> > > Francois,
> > >
> > > This mechanism is implementation dependent even in ANSI/ITU specs
> > > and optional.
> > >
> > > --brian
> > >
> > >
> > > Zannin, Francois wrote:                    (Tue, 12 Feb 2002 10:17:33)
> > > > Hi,
> > > >
> > > > I have an issue about the congestion handling in M3ua between
> > the ASp and
> > > > the SGp when congestion occurs on the AS(p).
> > >
> > > > It is said that an ASP can send a SCON to a SGP or another
> > IPSP when a local
> > > > congestion occurs.
> > >
> > > > If we use the multi level of congestion between the ASp and
> > the SGp, what
> > > > message can be used to monitor the level of congestion in the
> > ASp from the
> > > > SGp or remote IPSp. An ASp can send the DAUD SSMN to a SGp
> > but there is no
> > > > matching message from the SGp to the ASP.
> > >
> > > >
> > > > If a multi level congestion (National option) is detected in
> > an ASp, a SCON
> > > > is sent from the Asp to a SGp that sends a TFC to the ss7
> > Concerned SP. This
> > > > SP trigs the RCT procedure to monitor the state of the
> > affected DPC, but
> > > > because the SGP cannot send this message to the ASP, it must
> > keep locally
> > > > the state of congestion of the AS, state that can only be
> > updated by the
> > > > ASp. If the SCON indicating "No Congestion" is lost between
> > the ASp and the
> > > > SGP, the AS will stay congested forever in the SG!
> > >
> > > >
> > > > Is there a procedure that can be used from a SGp to monitor
> > the state of
> > > > congestion of an AS, something equivalent to the DAUD that
> > can only be used
> > > > from ASp to SGp?
> > >
> > > >
> > > > Francois Zannin.
> > > >
> > > >
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > > --
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> > --
> > 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

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

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 13 Feb 2002 10:51:55 -0500

Francois,

Please see comments/questions below.

  Tolga

> From: Zannin, Francois [mailto:[email-masked]]
> Sent: Wednesday, February 13, 2002 5:02 AM
> To: [email-masked]
[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.
> In that case, the remote AS will stay congested and the
[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.
> If an association is blocked, it is blocked for all AS served by
[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?
> to report the congestion for a specific AS to the SGP, and this
[TOLGA] So, we are reporting congestion of user parts, for which no MTP
procedures are defined.
> 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
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.
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.
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.
> > > From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> > > Zannin, Francois

---

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

Francois,

You still misunderstand how TFC works in the SS7 network.  TFC is sent
responsive only: that is, in response to a user-part message with a
priority less than the congestion encountered by the message.

Zannin, Francois wrote:                                   (Wed, 13 Feb 2002 11:02:27)
> reported by SCON), it must be sure that it is always has up to date information 

The SG does not maintain congestion states.

> In that case, the remote AS will stay congested and the consolidation at the 

SS7 procedures compensate for lost TFC.  TFC is always sent responsive.

> in order to base  congestion handling on the SCTP congestion reported to the 

It is the obligation of ASP to coordinate such things between themselves and
not involved the SG.  If one ASP is congested, it should arrange with other
ASPs to offload traffic to them.  This is accomplished with normal ASP
traffic mangement messages to the SG.

If the AS is in congestion, congestion flow controls should be applied at the
user level first: SCCP flow control, ISUP congestion controls.  If the
origination of the congestion does not respond to SCCP or ISUP congestion
control, then the AS is fully within its rights to ignore messages from that
destination point code.  There is never a need to send SP-based TFC (or the
equivalent SCON) unless the MTP (or in this case M3UA) for the SPMC is
congested.  Application congestion is handled by application primitives.

> If an association is blocked, it is blocked for all AS served by this ASP. 

So?

> to report the congestion for a specific AS to the SGP, and this is the role 

It is OPTIONAL.  (Both in M3UA and in MTP).  There is no must about it.

> of congestion in order to be able to handle the RCT.

That is incorrect.  The congestion state (level) is only maintained if the
"national option with message priorities and congestion states" is used.  But
nobody uses that option at the national level.  ANSI uses "national option
with message priorities (without congestion states)".  RCT messages only
retrigger TFC if a normal user message of the same priority level would also
trigger TFC.  This deos not require the node to maintain any routeset
congestion state whatsoever.

> known problematic behavior of the M3UA transport layer! But that's the way it is...

SCTP is a reliable transport.  It doesn't lose messages.

> internal M3AU stack can create local congestion other than at SCTP level.

ULP flow control is handled by SCTP with the a_rwnd.  If the ULP is congested
on the receive, this translates to congestion at the peer.  SCTP congestion
also indicates congestion at the peer ULP.

You seem to misunderstand many things.  Perhaps it would be better to ask
questions rather than making assertions.

--brian

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

---

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

Brian,

I don't understand why SCON from ASP to SGP should trigger TFC. Shouldn't
this be considered as user part congestion, which has no procedures defined
for MTP3?

    Tolga

> Sent: Wednesday, February 13, 2002 11:06 AM
> To: Zannin, Francois

---

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

Tolga,

Look back a the thread from last April and May: "SCON from ASP"

It was a ladder back then too.

There is only one case in which TFC is sent from an SEP (ANSI).
That is what SCON from ASP is for.

--brian

Tolga Asveren wrote:                                        (Wed, 13 Feb 2002 11:43:00)

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