RE: [SUA] yes, more on ASP Congestion

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 protected] [mailto:[email protected]]On
> Behalf Of Brian F. G. Bidulock
> Sent: Friday, October 14, 2005 4:58 PM
> To: Haresign Lincoln
> Cc: [email protected]; Craig, Jeffrey
> 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.
[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.
>
> 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.
[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.
>
> 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.
[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 :-) -.
>
> 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
>