Subject: RE: [Sigtran] Congestion in M3UA/SUA and the use of the SCON

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 11 Oct 2005 14:01:58 -0400

Brian,

I'm not sure what your point is. Detection of congestion is generally
considered to be "implementation dependent".  One of the functions of
SubSystem Management is to manage the state of the local subsystem.  One
of these states is congested.  The detection of congestion towards a
particular subsystem is implementation dependent.  I didn't say it was
in the SCCP user.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Tuesday, October 11, 2005 12:39 PM
To: Haresign Lincoln
Cc: Tolga Asveren; [email-masked]
Subject: Re: [Sigtran] Congestion in M3UA/SUA and the use of the SCON

Haresign,

Haresign Lincoln wrote:                       (Tue, 11 Oct 2005
08:35:44)
> Brian,
> 
> I was under the impression that we were trying to make the layers 
> about SUA unaware that they are running over IP.

SCCP and Subsystem congestion are below the SCCP/SCCP-User interface,
not above.

--brian

> My ASP today does not
> require knowledge of point codes.  And if SCON supported "source 
> address", the SG could properly implement the SSC procedures according

> to the ITU specifications.  The ASP only needs to know it's calling 
> address (which may not contain a PC).  Because of your requirement 
> below, it is putting an additional and completely unneccessary 
> requirement on the ASP.
> 
> Clearly you and I either disagree on this issue or we are failing to 
> be able to get our point across to each other. I will propose 
> alternate text for SUA relating to the SCON messsage.  I realize that 
> you don't feel this is necessary however it may be that others in the 
> SIGTRAN list feel otherwise.
> 
> Regards,
> Lincoln
> 

--
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, 11 Oct 2005 16:44:36 -0600

Haresign,

Haresign Lincoln wrote:                                                            (Tue, 11 Oct 2005 14:01:58)
> particular subsystem is implementation dependent.  I didn't say it was

But you keep saying that the ASP (SCCP-User) does not know its point code.
(Even though according to Q.711, an SCCP-SAP contains an MTP-SAP (point
code).)

Do you wish to place SCCP congestion detection at the SCCP user (yours
of which it appears doesn't not know its own point code) or with the
SCCP (that must not only know its point code, but must be able to
determine all other "concerned" point codes)?

By allowing an ASP to send SCON at all, we are allowing part of the SCCP
to be dragged across the line from SG to ASP.  This is already necessary
to some degree in the multiple SG as STP scenarios.  However, if the ASP
design wishes to drag some of the SCCP procedures accross into the ASP,
it must also be able to perform those SCCP procedures and is no longer a
strict SCCP-User.  Nevertheless, it is abuse of those procedures at the
ASP that makes it unwise to require the SG to do anything with SCON
received from an ASP.

BTW, the mechanism for detection of congestion within the SCCP
implementation is, of course, dependent upon the internal particulars of
that SCCP implementation.  However, "implementation specific" and
"implementation dependent" in the SCCP specifications does not affect
functional placement of the congestion functions (they are clearly
within the SCCP), nor does it allow one to avoid following the
congestion procedures (which include sending a message that includes
both point codes).

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 11 Oct 2005 18:50:06 -0400

Brian,

As far as I understand Lincoln wants congestion detection for subsystem to
happen at SG but
a)Wants ASPs to help SG in that decision through SCON messages
b)Wants to use ASP congestion information communicated with SCON from ASP to
SG, while distributing messages from SG to ASP.

I would think -although implementation dependent for most of the part- a)
and b) could be usefull for certain configurations.

I believe you are approaching the issue from another angle, where you
foresee a scenario where ASP detects subsystem congestion and communicates
it with SCON.

    Thanks,
    Tolga

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Brian F. G. Bidulock
> Sent: Tuesday, October 11, 2005 6:45 PM
> To: Haresign Lincoln
> Cc: [email-masked]; Tolga Asveren

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Oct 2005 17:18:55 -0600

Tolga,

Actually, I am not even speaking of subsystem congestion yet (N-STATE)
(which is only detected and signalled by some variants of SS7).  I am
speaking of SCCP congestion (N-PCSTATE).  For heaven's sake, the N-PCSTATE
primitive has PC in the acronym.

I don't really have a problem with a fancy, non-SS7 congestion mechanism.
Just don't use the SCON message.  SCON is a message reserved for SS7 network
interworking.  If you look at the ETSI modified documents, ETSI decided
(whether prudently or not) that if the SG receives a SCON from the ASP that
it MUST send the equivalent SS7 message.  To populate such a message's MTP
header requires the presence of the point code.

We discussed this at great length before.  Leave SCON for SS7 management.  If
you want to signal ASP congestion outside of the mechanisms of SCTP, we need
to define some ASPTM messages to do so.  And that is where we left it.  Nobody
proposed ASPTM messages for congestion indication, and nothing more was done
about it.

Now, again, there is this tendency to try to drag the SCON message to do
things other than SS7 network management, and instead bend it to ASP Traffic
Management.

If SCTP congestion management (peer receive window, send buffer occupancy) is
insufficient, define an ASP Congestion and ASP Congestion Ack message.  Add
an ASP Status and ASP Status Ack message for testing or probing congestion.
But please leave SCON alone.

--brian

Tolga Asveren wrote:                                                                  (Tue, 11 Oct 2005 18:50:06)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 12 Oct 2005 08:29:02 -0400

Brian,

> Sent: Tuesday, October 11, 2005 7:19 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA]Yes, I also recall that we touched this issue and barely decided on
how SCON should behave :-), and yes there was no progress made on an ASPTM
serving that purpose. IMHO, lack of such a message causes sometimes people
to try using SCON for that purpose. I personally am in favor of a new ASPTM,
because I also saw some real-life deployments where congestion status of
ASPs was desirable for message routing from SG to ASPs.