Subject: [Sigtran] Re: When would ASP send SCON

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 2 Jun 2005 00:47:23 -0600

Jarek,

The ASP may send SCON.  The SGP is not required to do anything
with the message.  As you put, the SGP is fully capable of
determining congestion from its side and acting in an
appropriate manner toward the SS7 network or other ASPs.

The ASP being permitted to send SCON was viewed by some as a
possible way to support a mechanism similar to nodal TFC in SS7,
which is, of course, optional and implementation dependent even in
SS7.  Also, not all national variants permit it.

I made numerous attempts at having it removed from the RFC, but
to no avail.  Perhaps someone who actually believed it was
important could offer some justification for it.  I doubt that
anyone can.

Unfortunately the document has no authors: perhaps you could ask
one of the numerous editors of the document why it could
possibly be necessary.  You will find their contact information
toward the end of the document.

--brian

Jarek Mazur wrote:                                    (Thu, 02 Jun 2005 15:47:52)
> 
>    Hi Brian,
> 
>    A  while  ago  you  have  kindly  provided me with the responses which
>    enhanced my understanding about IPSP.
>    I include them here because they relate to a new concern/question that
>    I have.
> 
>    Since the IPSP is not supposed to send either DAUD or SCON, and relies
>    on  the  status directly from the underlying SCTP, then why could this
>    behavior be different for the ASP in ASP-SGP communication in the case
>    when  ASP  gets  congested.  The  SGP  can  detect ASP's congestion in
>    exactly  the  same  manner as the IPSP its peer's, and also the SGP in
>    the  similar  fashion  to the IPSP is not supposed to send DAUD to its
>    peer.
> 
>    Hence  under  what  circumstances  would an ASP send the SCON message?
>    (the spec says ASP may send SCON)
> 
>    Once again I would appreciate your expert opinion,
>    Regards,
>    Jarek
> 

-- 
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: Sun, 5 Jun 2005 05:48:37 -0600

Jarek,

Regardless of why it is generated, what does the SG do with it when it
receives it?  Discard it?  (That is one valid option.)

It cannot be relied upon to illicit any behavior, so sending it is pointless.

--brian

Jarek Mazur wrote:                               (Sun, 05 Jun 2005 20:20:56)
> 
>    Hi Brian,
> 
>    After  seeing some replies (that did not spell it clearly though), and
>    having  some  thoughts,  I think that I could think of some situations
>    where  SCON  sent  from  ASP could have some merit. Please validate my
>    thread of thoughts (especially the #3).
> 
>    1. SGP can detect congestion of ASP using directly SCTP.
>    2.  SCON  is actually related to congestion of AS not ASP, e.g. if ASP
>    serves  multiple  ASs,  then  by  sending SCON, the ASP could indicate
>    which AS is congested.
> 
>    3.  If  AS  can  get  congested  independently  from  its ASPs getting
>    congested,  then  it  is  only  possible if an AS consists of a set of
>    processes,   where   only   subset   thereof   are  ASPs.  A  possible
>    configuration could be: AS consists of a front-end ASP process running
>    on  a  one  processor  and a back-end process that knows nothing about
>    SIGTRAN and runs on another processor. The communication between these
>    two is using non-SIGTRAN protocol.
> 
>    4.  When back-end gets congested, the AS is deemed congested, although
>    the ASP is not and there could be some merit in sending SCON to inform
>    AS's peer about that.
> 
>    Regards,
>    Jarek
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Jun 2005 02:09:25 -0600

Jarek,

That would be the nodal TFC.  The SG has all the information it needs at
its disposal to properly perform the (optional in SS7) nodal TFC
procedures without the AS ever sending SCON.  It is not, therefore,
useful for the AS to send it.  In fact it is counterproductive for the
SG to honour SCON from the AS, because it has no means to verify if the
AS is sending it in the correct manner except to fall back on the same
mechanisms that it can use itself to generate nodal TFC.  As the SG is
mostly responsible for SS7 conformance, it might be foolish for an SG
implementation to rely upon a plethora of AS implementations to act
correctly for it to gain conformance.  Rather, by using only local
information, it can ensure conformance with regards to nodal TFC
(hysteresis, congestion levels, onset and abatement, congestion test
procedures) without being reliant upon any given AS implementation.  For
this reason, IMHO, the SG is best advised to discard SCON received from
an AS and use only local information (e.g. SCTP send buffer occupancy)
if the optional nodal TFC procedure is to be used at all.

This is also fully consistent with MTP: it is congestion of the SMH
(Signalling Message Handling) function in the MTP that determines when
to send nodal TFC.  Nodal TFC is neither determined by the MTP User, nor
a component of the MTP User interface.  As M3UA exports that MTP-to-MTP
User interface, the SMH resides within the MTP layer on the SG and it is
there that congestion should be detected according to SS7.  No part of
the SMH is implemented on the AS in the typical arrangement and SCON
from the AS should not be used under the typical arrangement.

There is only one case where it could be viewed that the SMH is
implemented at the AS: that is the corner case where the SG is acting as
an STP and the AS has its own point code and is acting as an SEP and the
AS may be connected to multiple SGs acting as STPs.  In that case, local
congestion at the AS of the SMH function delivering messages to users
might cause a SCON to be generated to one SG/STP that is not exhibiting
SCTP transmit buffer occupancy because of congestion generated by
messages arriving from another SG/STP.  Or, the SCTP transmit buffer
occupancy onset might be slowed because the congestion derives from a
low traffic rate from a number of SG/STPs.  But these are unlikely
arrangements and the same procedures that the SG can use in the main
case will converge to a solution in these cases as well because the SS7
specifications do not describe what constitutes SMH congestion
(implementation dependent).  The only requirements on the algorithm is
that it exhibit onset/abatement hysteresis.

So, here we are back again: SCON from the AS is unnecessary.

--brian

Jarek Mazur wrote:                               (Tue, 07 Jun 2005 16:00:30)
> 
>    Hi Brian,
> 
>    One of the options that comes to my mind is that the SG could initiate
>    TFC procedure on behalf of the AS. One problem that I can see already,
>    is  that  when signalling-route-set-congestion-test message arrives at
>    the  SG, it would have to propagate is as DAUD to the AS, which is not
>    supported.
> 
>    I  am probably missing some other aspects that make the support of the
>    TFC for the AS hard/impossible?
> 
>    Regards,
>    Jarek
> 
>    -----Original Message-----
>    From: Brian F. G. Bidulock [[1]mailto:[email-masked]]
>    Sent: Sunday, 5 June 2005 9:49 PM
>    To: Mazur, Jarek [WOLL:5500:EXCH]
>    Cc: [email-masked]
>    Subject: Re: [Sigtran] Re: When would ASP send SCON
> 
>    Jarek,
> 
>    [2]http://www.openss7.org/
> 
> References
> 
>    1. mailto:[email-masked]
>    2. http://www.openss7.org/

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