Subject: RE: [Sigtran] [SUA] yes, more on ASP Congestion

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

Jeff,
 
See my comments below.
 
Thanks for your input.
 
Regards,
Lincoln

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Craig, Jeffrey
Sent: Friday, October 14, 2005 2:07 PM
To: [email-masked]
Subject: [Sigtran] [SUA] yes, more on ASP Congestion

Hello All,
 
I've been following the very very long thread regarding SUA ASP
congestion.
In general I agree with Brian Bidulock: leave the ASP->SG SCON alone,
and instead
create a new draft to address the general issue of user part congestion
and the UA
protocols.

[lincoln]: This is a perfectly fine solution for me if the WG accepts
it.
 
I'm having a hard time understanding why the following solutions don't
work:
* congested ASP stops receiving on association

[lincoln]: We don't want to stop receiving all traffic.  Just data
traffic.  I'd still like to received management messages on my ASP
(e.g., NOTIFY).

* congested ASP issues ASP-INACTIVE upon detecting inbound congestion
* congested ASP issues ASP-DOWN upon detecting inbound congestion

[lincoln]: See previous comments.  Also, by not disabling the
association and receiving an explicit PEER notification, the SG can take
actions such as reducing traffic by stages.

* use MTP3 and M2PA instead

[lincoln]: Not sure what you are referring to here.  
 
I'm having an especially hard time understanding how overloading the
ASP->SG 
SCON will result in an interoperable solution. 

[lincoln]: I don't believe it would.  But again, I'm not tied to this
solution if others want something else.  Overloading the SCON is easier
to implement although I agree that it was not the original intent of
SCON.  That's why I initially questioned it's use to do ASP congestion.
And I felt that overloading SCON was easier to the WG to stomach than a
completely new message.  But again, as long as there is a single
accepted solution to the problems, it doesn't need to be mine.
 
Regards,
 
Jeff

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

---

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

Haresign,

Haresign Lincoln wrote:                                                           (Fri, 14 Oct 2005 14:16:46)
> Lincoln

Well, you're going to convince them to accept it, right?  You are going
to back it 100%, right?

I won't take the time to write a draft if you are not going to contribute
to it and back it 100%.

> traffic.  I'd still like to received management messages on my ASP

Jeff is right, this is how it happens in SS7 and can easily be implemented
with SCTP congestion today.  All traffic does not stop because there are three
(or four depending how you think of it) levels of onset and abatement.  This
is how all but "nodal TFC" MTP congestion is signalled within the SS7 network.

But I'm sure that the SS7 way of doing things is not good enough for you,
or Tolga it seems, because it cannot signal congestion faster than it onsets
(which is what Tolga hopes the ASP Status message will do) so we will describe
a new a better way of doing things.

> actions such as reducing traffic by stages.

Jeff again make a good point.  It is fairly common practice in SS7 within
the industry to start prohibiting routes to avoid congestive overload 
which congstion indications seem incapable of suppressing.  In is common
practice in SS7 to start with MTP-User congestion controls, follow down
with TFC and, if inbound traffic persists at unacceptable levels, sending
TFP (or taking signalling links down) as a last resort.  These are equivalent
procedures.

But these are available to you now.  You don't want to use these, just the
new ASP Status message.

> [lincoln]: Not sure what you are referring to here.  

I think Jeff means that MTP3/M2PA works better than M3UA in the same scenarios
and I would agree.  M2PA does attempt to change anything about MTP3, gives it
just another signalling link that happens to be IP-based, and lets MTP3 get
on with the job.

But you need to use SUA (event though I think you should consider TUA for your
applications instead).

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 14 Oct 2005 17:22:19 -0400

Brian,

I will also send some text to you why IMO we need something like ASPCONG,
hopefully we can convince the WG about the need for such a mechanism.

A few more comments below.

   Thanks,
   Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Brian F. G. Bidulock
> Sent: Friday, October 14, 2005 4:58 PM
> To: Haresign Lincoln
> Cc: [email-masked]; Craig, Jeffrey
> Subject: Re: [Sigtran] [SUA] yes, more on ASP Congestion
>
>
> Haresign,
>
> Haresign Lincoln wrote:
[TOLGA]The point we are trying to address is not SS7 congestion -like you
also have mentioned several times-. OTOH, it may trigger SS7 congestion
related procedures on SG, depending on the aggregated congestion status.
> TFP (or taking signalling links down) as a last resort.  These
[TOLGA]Like you also expressed several times, we are here in the domain of
SCCP/SCCP User communication. It may be the case that SCCP itself -or none
of the subsystems- is congested but only one instance handling traffic for a
subsystem, where there are  other uncongested ones processing traffic for
the same subsystem.
> just another signalling link that happens to be IP-based, and
[TOLGA]It does not help to distribute traffic to multiple entities, i.e. no
RK support. One needs to have a proprietary mechanism for that
purpose -Actually one can discuss in length about "virtues/disadvantages" of
M2PA but this is besides the point right now :-) -.