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

From: "Zannin, Francois" <[email-masked]>
Date: Wed, 13 Feb 2002 18:04:05 +0100

Brian, 

My comments in the text.

Francois ZANNIN.

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

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.
You are right for the user messages but when the SG receive a RCT, it MUST 
answer by a TFC if the level of congestion is lower then the one tested by the RCT

Zannin, Francois wrote:                                   (Wed, 13 Feb 2002 11:02:27)
> 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. 

-The SG does not maintain congestion states.
If the SG is a STP, it MUST maintain the congestion of the AS in case of national 
congestion with priority.

> 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.

-SS7 procedures compensate for lost TFC.  TFC is always sent responsive.
for ordinary messages OK, for RCT, a TFC must be sent for each RCT receive (if 
still valid)

> 
> 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. 

-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.
The application can handle congestion only if it receive the TFC!

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

-So?
So??? bloking an ASP that serve several AS because only one AS is congested
may be a big problem!

> 
> 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. 

-It is OPTIONAL.  (Both in M3UA and in MTP).  There is no must about it.
And we are talking about this option!

> 
> 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.

-That is incorrect.  The congestion state (level) is only maintained if the
-"national option with message priorities and congestion states" is used. But
right!

-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.
RCT is automatically trigged on receipt of a TFC after T16.

> 
> 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...

-SCTP is a reliable transport.  It doesn't lose messages.
That' s good answer! and the key of the problem!

> 
> 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.

-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.
Exactly what I said!

-You seem to misunderstand many things.  Perhaps it would be better to ask
-questions rather than making assertions.
OK for a training !

--brian

> 
> 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/

-- 
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: Wed, 13 Feb 2002 11:28:30 -0600

Zannin,,

Zannin, Francois wrote:                                   (Wed, 13 Feb 2002 18:04:05)
> congestion with priority.

No.  If the SG is an STP it determines the congestion of routesets
towards the destination and triggers TFC if necessary.  AS have no
involvement in that.

SCON from ASP is only to accomodate the ANSI case where an SEP is
allowed to send TFC.

> for ordinary messages OK, for RCT, a TFC must be sent for each RCT receive (if 

Yes.  TFC is always sent responsive.

> So??? bloking an ASP that serve several AS because only one AS is congested

This can alwyas occur a SCTP level.  Per-stream flow controls were not
provided in SCTP.  SCON cannot be used for per-stream flow controls.
If, however, the SCTP association is the bottleneck, there will always
be a problem.

> And we are talking about this option!

As it is not a core protocol function, it is rather unimportant.

> RCT is automatically trigged on receipt of a TFC after T16.

Not at the STP.  At the SEP receiving the TFC.  The STP does not maintain
congestion state, only the SEP receiving TFC.

> That' s good answer! and the key of the problem!

Yes, it is the solution.

> -also indicates congestion at the peer ULP.

So you see there is no problem.

--brian

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