Re: Recommendation for SUA modifications

Tolga,

So how can I sum that up in the introduction...  Something like:

 The new ASP Status message, when used by some ASP implementations,
 depending on the internal operations of the ASP, and the internal
 operations of the peer SG, might in some situations be able to more
 quickly indicate non-SS7 ASP congestion to the SUA peer than some
 SGs, depending on internal implementation, might be able to detect
 more slowly on their own otherwise.

 SCTP application flow control mechanisms are woefully inadequate in
 this regard.  SCTP provides no assistance whatsoever to the application
 in controlling congestion.  SCTP provides no flow control mechanisms.
 SCTP features such as SCTP lifetimes are useless in this regard.

Does that about sum it up?

Hey, I think that we need two more messages: an ASP Checkpoint and ASP
Checkpoint Ack messages.  They could be used by the SG to measure the
latency of the application.  The SG sends an ASP Checkpoint message with
an RC in it ever so often, and when the ASP finishes processing all of
the messages before the Checkpoint message, it responds with a Checkpoint
Ack message.  Then the SG could measure and monitor the I/O latency
across the peer application and use this information when deciding to
which ASP to distribute new transactions.

That's way better than SS7 congestion.  What do you think?

--brian

Tolga Asveren wrote:                                                                  (Fri, 14 Oct 2005 11:01:56)
> Brian,
> 
> As far as I can see, SCTP congestion may not be good enough for cases:
> a)Where there are I/O bound operations on ASP as part of application
> logic -depending on latency on I/O operation, application can declare itself
> congested, rather than waiting SCTP to detect it-
> b)If ASP-M3UA and ASP-Service Logic are on different hosts/cards/blades
> etc..
> 
> For both of those cases, congestion will probably propogate down to the SCTP
> level eventually, but it can be detected and SG can take proper action
> earlier. Actually I believe even for the generic case, application can
> detect congestion earlier than SCTP for most of the situations and I think
> to have the option to communicate this as early as possible is a nice thing
> to have.
> 
>     Thanks,
>     Tolga
> 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]On
> > Behalf Of Brian F. G. Bidulock
> > Sent: Friday, October 14, 2005 10:46 AM
> > To: Tolga Asveren
> > Cc: [email protected]; [email protected]; [email protected]
> > Subject: Re: [Sigtran] Recommendation for SUA modifications
> >
> >
> > Tolga,
> >
> > What were the scenarios where SCTP flow control (arwnd) do not work?
> >
> > Could you detail them?
> >
> > I would like to capture them in my congestion draft.
> >
> > --brian
> >
> > Tolga Asveren wrote:                            (Fri, 14 Oct 2005
> > 09:34:42)
> > > Brian,
> > >
> > > On the big picture I agree with you that SSNM is meant to be
> > used for SS7
> > > network management, hence SCON is supposed to be used for SS7 congestion
> > > procedures. OTOH, there is a need to notify congestion status
> > of ASPs to SG
> > > and right now it seems like we don't have a solution -actually
> > till now the
> > > supposed solution was relying on SCTP congestion but there are scenarios
> > > where this is not enough/does not work well-. I believe
> > something needs to
> > > be done to address that issue.
> > > a)Either a new ASPTM
> > > b) or overloading SCON
> > >
> > >     Thanks,
> > >     Tolga
> > >
> >
> > --
> > Brian F. G. Bidulock
> > [email protected]
> > http://www.openss7.org/
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran

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