RE: [SUA] yes, more on ASP Congestion

Brian,

As I said before, if there is a solution that satisfies my problem, I'll
back it.  I'll provide some comments on the issues that you brought up
next week and then I'll await the draft to comment.

The difference that I see between SS7 and ASP->SG (when talking about a
UA like M3UA or SUA) is that we now have "part" of an application.  For
example, one ASP may be just part of a subsystem.  And we need to manage
the parts.  One ASP needs to be able to give it's status (e.g., down,
congested) and the SG needs to see the overall view of the entire AS and
make an intelligent decision about what to do.

I think the ASPTM is one way to do that.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Friday, October 14, 2005 4:58 PM
To: Haresign Lincoln
Cc: Craig, Jeffrey; [email protected]
Subject: Re: [Sigtran] [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/