RE: [SUA] yes, more on ASP Congestion

Lincoln,

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Haresign Lincoln
> Sent: Friday, October 14, 2005 5:05 PM
> To: [email protected]
> Cc: [email protected]; Craig, Jeffrey
> Subject: RE: [Sigtran] [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.
[TOLGA]Yes, I think this is the key issue here. SG may aggregate congestion
status for the whole SPMC/-whatever the equivalent term should be for SUA-
like it does it for availability status. Furthermore SG may do intelligent
loadsharing based on congestion status of ASPs. All of this distribution is
totally implementation dependent from SS7 point of view hence not addressed
in SS7 specifications but needs to be addressed by SUA/M3UA because they
allow distribution of certain SS7 entities to multiple instances as part of
protocol.
>
> 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/
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>