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

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 6 Oct 2005 15:02:28 -0400

Brian,

I certainly don't expect anyone outside fo Comverse to design our SW.
We are extremely successful at that deployed in 100s of networks and
thousands of deployments throughtout the world.  I'm not sure where you
are getting that from or why you would even suggest it.  What I do
expect is that if a committee is going to come out with a standard, then
that committee should be willing to:

1) accept improvements
2) accept compliments
3) accept criticism 

As I stated, the SIGTRAN RFCs are quite good for their age and my hats
off to the contributors.

In my humble opinion, I believe we can make improvements in the
specifications.  At the moment, I'll focus on the SUA specification.
This is not related to "nodal TFCs".  It is related to subsystem
management and how that applies to SCON messages from the ASP.  The
ability to send an SCON from the ASP exists today in the spec.  I've
already outlined two problems with this in SUA.  I will propose
alternate text.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Thursday, October 06, 2005 1:54 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:
(Thu, 06 Oct 2005 10:21:48)
> Tolga,
> 
> [TOLGA]:Does anybody know the rationale behind sending SCON from ASP 
> to SG when ASP -not the M3UA layer of ASP but something else- is
congested?
> 
> The rationale would be that the ASP is congested at the layer above 
> M3UA and you want to reduce or eliminate new traffic.  I can give you 
> several more concrete examples if you want them.  There are many 
> reasons why an ASP would want to indicate congestion.

User part (and subsystem) applications must use their own measures for
flow control within the user part (and subsystem).  These things are for
SS7 network and protocol congestion, not application congestion.

> 
> > [lincoln]: Where is this documented?
> [TOLGA]Probably nowhere in official documents, I happen to know about 
> it just because I could remember -hopefully correctly- the discussions

> about whether SCON from ASP to SG should be allowed or not. Could be 
> an idea to mention about it somewhere.
> 
> And if the specs don't specify something, then it's not in the specs.
> Period.  I don't think there is any getting around that one.  

ANSI T1.111.4/2000 specifies the conditions under which an SS7
signalling point can send a "nodal TFC" as a result of the congestion of
the Signalling Message Handling function.  The SS7 documents are
Normative.  SCON in the ASP->SG direction was intended to provide a
protocol mechanism to allow "nodal TFC", primarily in the multiple SG as
STP case (similar to DRST which is also only used in the mutliple SG as
STP scenario).

It has no other use.  As "nodal TFC" itself is optional to send in SS7,
SCON ASP->SG must obviously be optional in M3UA/SUA.  Also, because the
SG is responsible for policy towards the SS7 network (and other MTP- or
SCCP-Users), the SG does not need to respond to it or take any action on
it whatsoever, unless it wishes to.

If you cannnot figure out how to use it don't.  Nobody is requiring you
to use it.

If you would like someone to design your SG for you, do no expect the
specification to do so.

--brian

--
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, 7 Oct 2005 04:31:47 -0600

Lincoln,

In contrast to formal standards bodies, IETF WGs do not operate by
committee, they operate by consensus.  Improvements, compliments and
criticism only assist the process if they build consensus.

Your text should not impose any requirement on the SG toward the SS7
network (out of scope), should certainly not expect the SG to send DAUD
on an already congested SCTP association (doesn't make sense), and
should not make optional address in the SCON that the SG might need to
complete any SS7 message that it might wish to send.

Aside from these advance comments, I look forward to commenting on your
proposal.

Bear in mind that the WG just advanced the replacement RFC document
(rfc3332bis) a short while ago and only minor editorial changes will be
permitted.  If you keep your changes to the bare minimum the editors of
rfc3332bis might be able to include the changes before it goes to RFC.
Also, the smaller the change the greater the likelihood that the WG
might agree to your change.

--brian

Haresign Lincoln wrote:                     (Thu, 06 Oct 2005 15:02:28)

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