RE: Congestion in M3UA/SUA and the use of the SCON

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 protected] [mailto:[email protected]] On
Behalf Of Brian F. G. Bidulock
Sent: Tuesday, October 11, 2005 7:19 PM
To: Tolga Asveren
Cc: [email protected]
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 protected]
http://www.openss7.org/

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

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