Re: [SUA] yes, more on ASP Congestion

Haresign,

Haresign Lincoln wrote:                                                           (Fri, 14 Oct 2005 14:16:46)
> Jeff,
>  
> See my comments below.
>  
> Thanks for your input.
>  
> Regards,
> Lincoln
> 
> ________________________________
> 
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Craig, Jeffrey
> Sent: Friday, October 14, 2005 2:07 PM
> To: [email protected]
> 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.

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%.

>  
> 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).

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.

> 
> * 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.

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.

> 
> * use MTP3 and M2PA instead
> 
> [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

>  
> 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 protected]
> https://www1.ietf.org/mailman/listinfo/sigtran

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