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

From: "Haresign Lincoln" <[email-masked]>
Date: Fri, 7 Oct 2005 09:05:19 -0400

Brian,

Thanks for your input.  With regards to the SCON, I'm more concerned
about make additions to SUA.  

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Friday, October 07, 2005 6:32 AM
To: Haresign Lincoln
Cc: Tolga Asveren; [email-masked]
Subject: Re: [Sigtran] Congestion in M3UA/SUA and the use of the SCON

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,
> 
> 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
> 

--
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: "Haresign Lincoln" <[email-masked]>
Date: Wed, 12 Oct 2005 09:09:07 -0400

Brian,

I'm working on alternate text for the SCON message.  If you would rather
have an ASPTM message, that's fine with me.  Please propose it and if it
solves the problem, I'll back it up.  In any case, there is a problem
that needs to be solved.

I respectfully disagree with the previous comments that you've made in
this email and the previous ones.  But at this point, it's probably no
longer practical to keeping up the debate.  I think we are just talking
in circles at this point and it probably doesn't matter what either one
of us says.  

Regards,
Lincoln 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brian F. G. Bidulock
Sent: Tuesday, October 11, 2005 7:19 PM
To: Tolga Asveren
Cc: [email-masked]
Subject: Re: [Sigtran] Congestion in M3UA/SUA and the use of the SCON

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,
> 
> 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
> 

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