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

From: "Zannin, Francois" <[email-masked]>
Date: Mon, 19 Jan 2004 15:44:23 +0100

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/

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Jan 2004 13:37:50 -0700

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 F. G. Bidulock
[email-masked]
http://www.openss7.org/