Subject: RE: [Sigtran] SUA v14 doubt in SCON

From: "Zannin, Francois" <[email-masked]>
Date: Tue, 20 Jan 2004 09:37:52 +0100

Brian,

I think that "simple ASP s no knowledge of the congestion of an AS" is
your implementation.
Some other can have a more task distributed implementation of the ASP.

My concern is about International mode only.

What can make a SG decide to discard a message for a specific AS? The
solution to allow a SG to fully handle congestion for an AS is to block
the read on SCTP association, action that block read for all AS served
by the ASP. If the SCTP stack API is not stream oriented, then you block
ALL messages (ASPTM, SSNM ...).
The congestion implementation is to inform the messages originators that
the "SCCP user" is congested (the number of messages buffered
increased), NOT that messages are systematically discarded. 

DO we have to create SG that discards ALL messages as soon as an AS
sends a SCON? Maybe some people want to handle congestion in a different
way; this other solution needs a "concerned PC" in the SCON.
If some other doesn't need the SCON, they just can ignore it and force
the ASP implementation to block associations as soon as one AS on an ASP
enters in congestion!

Francois,

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Monday, January 19, 2004 9:38 PM
To: Zannin, Francois
Cc: [email-masked]
Subject: Re: [Sigtran] SUA v14 doubt in SCON

Francois,

No.  The single ASP has no knowledge of the congestion of an AS (which
comprises multiple ASP).  The SG and SG alone is responsible for the
status of the SPMC/Subsystem as reflected to the SS7 network.  In both
the national and international mode, messages are discarded/retrned
*before* delivery to the SCCP user (AS).  Therefore, only the SG
determines to which destinations congestion messages are sent.  The ASP
does not even see the message.

I certainliy disagree with making an SUA message mimic a useless M3UA
one.

--brian

Zannin, Francois wrote:
(Mon, 19 Jan 2004 15:44:23)
> Brian,
> 
> Your view of the problem is that all SG connected to ASP must locally 
> handle the congestion for national and international mode.
> 
> For national Congestion with level, the good approach is to handle the

> congestion action (messages discard, TFC) in the SG in order to 
> minimize useless traffic (because discarded) on the IP network. Then, 
> the ASP notify all the SG(p) of it's current congestion level per AS. 
> A timer procedure can be used on the SG in addition to the last SCON 
> received.
> 
> But for international congestion with no systematic discard, isn't the

> relay of the SCON enough to inform the originator of the message of 
> the congestion of the AS. There is no need to keep the congestion in 
> the SG!
> 
> 
>  
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, January 19, 2004 11:53 AM
> To: Zannin, Francois
> Cc: Tolga Asveren; [email-masked]
> Subject: Re: [Sigtran] SUA v14 doubt in SCON
> 
> 
> Francois,
> 
> I did not say that SCON was not needed for SUA.  Concerned destination

> is not needed.  When an SCCP user (subsystem) becomes congested, it 
> SCCP management signals same to the SCCP with the N-STATE request 
> primitive. This is the SCON message from ASP to SG.
> 
> What it does not require is a concerned destination.  N-STATE request 
> primitives and SUA SCON do only contain the affected node.  It is 
> SCCP's responsibility to send SSC every Pth message and only in 
> response to the necessary messages.  SCCP messages that encounter 
> congestion are not delivered to the SCCP user.
> 
> This is, in fact, also the situation for M3UA, and the SG is permitted

> to ignore SCON sent from ASP to SG, and is permitted to also ignore 
> the concerned destination in the SCON send from ASP to SG.  That is 
> why the field (and message from ASP to SG) is of questionable utility 
> in M3UA.
> 
> Do you understand now?
> 
> --brian
> 
> 
> Zannin, Francois wrote:
> (Mon, 19 Jan 2004 11:34:49)
> > Brian,
> > 
> > When a SUA End point is connected to two or more SG and the ASP is
> > congestionned for only one AS served by the ASP (this case exist),
how
> 
> > can the ASP inform the originator of the message that the AS (SCCP
> > user) is congestioned?
> > 
> > When you think that SCON is not needed for SUA, how can you replace
> > this functionnality?
> > 
> > Francois,
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Monday, January 19, 2004 11:21 AM
> > To: Zannin, Francois
> > Cc: Tolga Asveren; [email-masked]
> > Subject: Re: [Sigtran] SUA v14 doubt in SCON
> > 
> > 
> > Francois,
> > 
> > SUA does not support this (nor does it need to).  We only put it in
> > M3UA for so-called "nodal" congestion, and it has questionable
utility
> 
> > there.
> > 
> > --brian
> > 
> > Zannin, Francois wrote:
> > (Mon, 19 Jan 2004 10:08:58)
> > > Hi,
> > > 
> > > In the SUA network, I was wondering what could be the message send
> > > by
> > > an ASP congested for one (and only one) of it's hosted AS.
> > > 
> > > The SCON sent by an ASP to the originator of the message (like # 
> > > ss7 TFC or SSC) could be a solution, But this SCON do not include 
> > > any affected PC like in M3UA.
> > > 
> > > When an ASP receive a message for a congested AS, it can return a 
> > > congestion indication to the originator of the message (Ref: Q714 
> > > 5.2.7.1). Then, the ASP sends a SCON to the SG for the "originator
> of
> > > the message". But with no concerned PC in the SCON, the SG cannot
> > > identify the addressee of the SCON.
> > > 
> > > If we are handling the congestion in "International mode", no 
> > > congestion state must be kept in the message path, so the SG do 
> > > not need any processing other then forwarding the SCON as a TFC.
> > > 
> > > Could we add a concerned DPC in the SCON as it exist in the M3UA
> > > SCON?
> > > 
> > > Francois,
> > > 
> > > 
> > > -----Original Message-----
> > > From: Tolga Asveren [mailto:[email-masked]]
> > > Sent: Friday, September 13, 2002 5:58 PM
> > > To: [email-masked]
> > > Subject: RE: [Sigtran] SUA v14 doubt in SCON
> > > 
> > > 
> > > Brian,
> > > 
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: Friday, September 13, 2002 11:10 AM
> > > > To: [email-masked]
> > > > Cc: [email-masked]; [email-masked];
> > > > [email-masked]
> > > > Subject: Re: [Sigtran] SUA v14 doubt in SCON
> > > >
> > > >
> > > > Yogesh,
> > > >
> > > > SCON is used to indicate SS7 network congestion only.  It is not
> > > > useful in the IPSP case.  In the IPSP case, IETF mechanisms are 
> > > > more
> > 
> > > > applicable: such as ECN.
> > > [TOLGA] For SUA-IPSP case, aren't we allowed to use SCON to inform
> > > the
> > 
> > > peer about local subsystem congestion? Because there is no 1:1:1 
> > > relationship between AS,SCTP associations and an IP address, I 
> > > wouldn't think ECN or SCTP congestion mechanisms can do, what SCON
> is
> > > intended to do.
> > > 
> > > _______________________________________________
> > > 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/

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Jan 2004 02:53:39 -0700

Francois,

The decision is made within SCCP, that resides at the SG.   The decision
is made by the SCCP by comparing the importance of the message with the
restricted importance level of the subsystem.  The SCCP also counts the
Pth message.   Although SCCP Management (distinct from the SCCP User) can
indicate its congestion to SCCP using the N-STATE request primitive, the
N-STATE request primitive (defined in Q.711), does not contain a concerned
point code, only an affected user.  Thus SCON sent from ASP to SG, does
not contain a concerned point code.

SUA transport the SCCP/SCCP-User and SCCP/SCCP Management interface from
the SG to the ASP.  The decision being within the SCCP layer, without
requiring concerned destinations from SCCP management, means that there
is no purpose to including it in the SCON, because the SCCP conforming
SG implementation has no use for it, because it has at its disposal the
OPC of the Pth message used to trigger SSC and does not send the message
that triggered the sending of SSC to the AS.  SCCP Management either at
the SG or at the AS may indicate via N-STATE request the congestion level
of the subsystem.  This congestion level is for all received messages and
does not pertain to a specific triggering message.  SCCP at the SG determines
which is the Pth message to trigger sending of SSC given the current RIL
communicated by SCCP management, and the origin or relay of that messsage
determines the concern SCCP node(s) for the SSC.

Note also that the node to which the SSC is sent is not necessarily the
originating SCCP.  The SCCP uses the OPC of the MTP portion of the message
to determine the concerned node for the SSC.  This can be an STP or other
relay point.  The point code of the relay is NOT communciated to the AS
in CL or CO messages.  Note that the Source Address in the CLDT and the
CORE messages is the originating SCCP node.  For proper congestion, the
SSC must also be sent to messages arriving from relay nodes that is only
contained in the OPC of the MTP-TRANSFER Indication primitive which is at
SCCP's disposal at the SG, and is NOT communicated by SCCP to the AS.
Therefore, for proper congestion operation, the AS cannot know the correct
target of the SSC, only the SG can.

SSC is distincly different from TFC.  TFC is always address to the originator
of the MTP message.  SSC is sent for every Pth message to the originator of
the MTP portion of the message (not the same as the SCCP originator) and is
either the originating SCCP node or a relay SCCP node (when an STP or relay
node relays a message it recreates the MTP envelope because the message
passes up to SCCP in MTP-TRANSFER Ind and then back down to MTP in a new
and, as far as MTP knows, unrelated, MTP-TRANSFER Request primitive.

In the case where the SUA ASP is connected to multiple SGs acting as STPs,
the SG itself might be the concerned relay point (or might not, depending on
whether the specific message was relayed at SCCP or transferred at MTP).

Therefore, I say again, there is no purpose or use to adding concerned
destination to SCON.  The ASP cannot properly populate the parameter, and
the SG does not require any information from the ASP to perform proper
SCCP congestion procedures within the SCCP layer.  The SCON message as
defined in the draft that was advanced to IESG, which contains the
affected user and is analogous to the N-STATE request, N-STATE indication
and N-PCSTATE indication primitives are both necessary and sufficient.

Do you now understand SCCP congestion procedures?  If not, I suggest that
you read the pertinent passages of the Q.71x series of specifications.

Perhaps you are making the mistake often made on this list of confusing
user-level flow controls with protocol layer flow controls.  Do not attempt
to make an SG perform flow control at the SCCP layer when it is more properly
addressed by flow controls within the SCCP-user.  For example, some TCAP
user parts perform Automatic Code Gapping to throttle overload.  SCP overload
controls are available for most TCAP protocols.  Non-TCAP SCCP users have
similar mechanisms.

Ultimately if the SCCP-user is not servicing its read queue for the SCTP
association, the SG needs to invoke SCCP congestion procedures independent
of receiving even N-STATE Request from the ASP for proper congestion
operation.  It cannot even rely on the ASP to be able to send a message when
either the ASP or the intervening network is suffering congestion.

Either way, there is no need for concerned DPC in the ASP->SG SCON for SUA.

If you choose to persist in along these lines, perhaps you can point to a
procedure that the SG, having a fully functional SCCP, is incapable of
performing without such a parameter.

--brian

Zannin, Francois wrote:                                                            (Tue, 20 Jan 2004 09:37:52)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 20 Jan 2004 08:50:51 -0500

[..snip..]
> Either way, there is no need for concerned DPC in the ASP->SG
[TOLGA]I agree. Lets' keep it similar to SCCP/SCCP-User interface -as it is
right now-.