Subject: RE: [Sigtran] Recommendation for SUA modifications

From: "Haresign Lincoln" <[email-masked]>
Date: Fri, 14 Oct 2005 08:48:46 -0400

Brian,

Are you saying that an ASP can not congest?  I'm not really sure where
you are going with this.  The RFC says the following:

   The SUA layer at an ASP or IPSP MAY indicate local congestion to an
   SUA peer with an SCON message.  When an SG receives a congestion
   message (SCON) from an ASP, and the SG determines that an endpoint is
   now encountering congestion, it MAY trigger congestion procedures of
   the relevant SCCP standard.

If this is not true, let me know and we will need to amend the RFC and
find another way to handle ASP congestion.  My very first email that
started this thread asked the question of whether SCON was valid from
ASP to SG.  At the time, you indicated that this was valid. Are you now
saying it is valid, but only in limited scenarios?

If this is valid, then there are two scenarios that the RFC does not
handle:

1) ASP shares the same point code as the SG and is not aware of it's
point code.  Meaning the ASP may just be a global title.  Or there could
be multiple AS behind the SG with different subsystems but sharing the
same point code as the SG.

2) ASP is multiple point codes.

In the RFC, the handling of the SCON message by the SG is implementation
dependent.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Friday, October 14, 2005 8:36 AM
To: Haresign Lincoln
Cc: Valerie Gastaud; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Sigtran] Recommendation for SUA modifications

Lincoln,

The RFC does not say otherwise:

3.10.24.  Congestion Level

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = 0x0118          |             Length = 8        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Congestion Level                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Congestion Level field: 8-bits (unsigned integer)

   The Congestion Level field contains the level at which congestion has
   occurred.

   When the Congestion Level parameter is included in a SCON message
   that corresponds to an N-PCSTATE primitive, the Congestion Level
   field indicates the MTP congestion level experienced by the local or
   affected signalling point as indicated by the Affected Point Code(s)
   also in the SCON message.  In this case, valid values for the
   Congestion Level field are as follows:

      0  No Congestion or Undefined
      1  Congestion Level 1
      2  Congestion Level 2
      3  Congestion Level 3

   When the Congestion Level parameter is included in a SCON message
   that corresponds to an N-STATE primitive, the Congestion Level field
   indicates the SCCP restricted importance level experienced by the
   local or affected subsystem as indicated by the Affected Point Code
   and Subsystem Number also in the SCON message. In this case, valid
   values for the Congestion Level field range from 0 to 7, where 0
   indicates the least congested and 7 indicates the most congested
   subsystem.

--brian

Haresign Lincoln wrote:                     (Fri, 14 Oct 2005 08:33:18)
> Brian,
> 
> That's your definition.  The RFC says otherwise.
> 
> An ASP can congest according to the RFC and according to practical 
> matters in networks.  We need a mechanism to support ASP congestion.
> The RFC has specified one.  A minor change to the RFC allows the cases

> that the current RFC has not covered.
> 
> And it has no impact on existing SGs since the handling of an SCON is 
> optional.
> 
> Regards,
> Lincoln
> 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, October 14, 2005 8:28 AM
> To: Haresign Lincoln
> Cc: Valerie Gastaud; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [Sigtran] Recommendation for SUA modifications
> 
> Lincoln,
> 
> The congestion level only applies to a single point code.  SCCP 
> maintains a independent congestion level for each point code.
> 
> --brian
> 
> Haresign Lincoln wrote:                        (Fri, 14 Oct 2005
> 08:19:02)
> > Valerie,
> > 
> > I think this is a good solution.  Using the RC also addresses the 
> > scenario of the ASP supporting multiple point codes (not something 
> > that we do, but the RFC supports it).  Since the current SCON 
> > message doesn't indicate that multiple point codes can be specified 
> > in the SCON, the RC parameter would handle this scenario also.
> > 
> > Regards,
> > Lincoln
> > 
> 
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> ______________________________________________________________________
>   This email message has been scanned by PineApp Mail-Secure and has 
> been found clean.
> 

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

______________________________________________________________________
  This email message has been scanned by PineApp Mail-Secure and has
been found clean.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 14 Oct 2005 07:10:12 -0600

Lincoln,

Haresign Lincoln wrote:                                                           (Fri, 14 Oct 2005 08:48:46)
> saying it is valid, but only in limited scenarios?

I tried a good number of times to tell you that SCON was for SCCP and
Subsystem (N-STATE and N-PCSTATE) congestion only.  This is no different
in the SG->ASP or ASP->SG directions.  When the ASP sends SCON it is
indicating SCCP or SCCP Subsystem congestion to the SG depending upon
whether it places SSN in the message or not.  When there is no SSN in
the message, it corresponds to MTP congestion (precisely the same
scenario in which M3UA sends SCON from ASP to SG).  When there is an
SSN in the message, and SSN is 1, it indicates SCCP Congestion, when
SSN is other than 1, it indicates SCCP Subsystem Congestion.

> same point code as the SG.

It will try again: an ASP that is not aware of point codes has no business
signalling MTP or SCCP congestion levels.  MTP congestion levels are
maintained on a point code basis.  So are SCCP congestion levels (RIL).
SCCP subsystem congestion (CL) is also maintained on a point code basis.

If the ASP is unaware of point codes, why is it sending the messages?

Also, in the trivial case where SG an ASP share a single point code, the
SG with a fully functional SCCP layer is capable of providing all SCCP
congestion management functions without assistance from the ASP.  It is
more usable in the multiple SG as STP, and ASP as relay scenarios, where
the ASP can send SCON independently to each SG.

> In the RFC, the handling of the SCON message by the SG is implementation

No, the handling of the SCON message is clear.  Whether the SG sends
an SS7 message to the SS7 network is in accordance with the conformances
that it must meet in that direction that are outside the scope of the SUA
specification.  Because the SG MAY (in order to meet conformance) send an
SS7 congestion message, a SCON sent from the ASP clearly MUST have the
necessary information and be generated under the proper conditions.  The
description of the message, and its mandatory contents, accomplish this.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 14 Oct 2005 09:34:42 -0400

Brian,

On the big picture I agree with you that SSNM is meant to be used for SS7
network management, hence SCON is supposed to be used for SS7 congestion
procedures. OTOH, there is a need to notify congestion status of ASPs to SG
and right now it seems like we don't have a solution -actually till now the
supposed solution was relying on SCTP congestion but there are scenarios
where this is not enough/does not work well-. I believe something needs to
be done to address that issue.
a)Either a new ASPTM
b) or overloading SCON

    Thanks,
    Tolga

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Brian F. G. Bidulock
> Sent: Friday, October 14, 2005 9:10 AM
> To: Haresign Lincoln
> Cc: [email-masked]; [email-masked]; Valerie Gastaud;
> [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 14 Oct 2005 08:45:52 -0600

Tolga,

What were the scenarios where SCTP flow control (arwnd) do not work?

Could you detail them?

I would like to capture them in my congestion draft.

--brian

Tolga Asveren wrote:                            (Fri, 14 Oct 2005 09:34:42)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 14 Oct 2005 11:01:56 -0400

Brian,

As far as I can see, SCTP congestion may not be good enough for cases:
a)Where there are I/O bound operations on ASP as part of application
logic -depending on latency on I/O operation, application can declare itself
congested, rather than waiting SCTP to detect it-
b)If ASP-M3UA and ASP-Service Logic are on different hosts/cards/blades
etc..

For both of those cases, congestion will probably propogate down to the SCTP
level eventually, but it can be detected and SG can take proper action
earlier. Actually I believe even for the generic case, application can
detect congestion earlier than SCTP for most of the situations and I think
to have the option to communicate this as early as possible is a nice thing
to have.

    Thanks,
    Tolga

> Sent: Friday, October 14, 2005 10:46 AM
> To: Tolga Asveren
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 14 Oct 2005 09:39:33 -0600

Tolga,

So how can I sum that up in the introduction...  Something like:

 The new ASP Status message, when used by some ASP implementations,
 depending on the internal operations of the ASP, and the internal
 operations of the peer SG, might in some situations be able to more
 quickly indicate non-SS7 ASP congestion to the SUA peer than some
 SGs, depending on internal implementation, might be able to detect
 more slowly on their own otherwise.

 SCTP application flow control mechanisms are woefully inadequate in
 this regard.  SCTP provides no assistance whatsoever to the application
 in controlling congestion.  SCTP provides no flow control mechanisms.
 SCTP features such as SCTP lifetimes are useless in this regard.

Does that about sum it up?

Hey, I think that we need two more messages: an ASP Checkpoint and ASP
Checkpoint Ack messages.  They could be used by the SG to measure the
latency of the application.  The SG sends an ASP Checkpoint message with
an RC in it ever so often, and when the ASP finishes processing all of
the messages before the Checkpoint message, it responds with a Checkpoint
Ack message.  Then the SG could measure and monitor the I/O latency
across the peer application and use this information when deciding to
which ASP to distribute new transactions.

That's way better than SS7 congestion.  What do you think?

--brian

Tolga Asveren wrote:                                                                  (Fri, 14 Oct 2005 11:01:56)

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