Re: Recommendation for SUA modifications

Licoln,

Haresign Lincoln wrote:                                                            (Fri, 14 Oct 2005 11:36:11)
> Brian,
> 
> 1) if multiple ASPs or AS can use the same association, this is a
> scenario where you wouldn't want to use SCTP flow control.

Your right again!  The SUA specification is deeply flawed.  It currently
only allows 1 ASP per association.  It needs to be enhanced to allow multiple
ASPs per association.  That should be possible with an I-G entry.  We could
just add the ASP Id parameter to all the messages so that the SGP can distinguish
between all the ASPs on the association.  Hey!  Why not multiple SGPs per
association too!  We could use the ASP Id in all the messages in the other
direction.

> 
> 2) SCTP flow control would reduce or eliminate ALL traffic going to an
> ASP.  It may be that you want to see management messages, but not data
> messages.

Yes, MTP doesn't do this well.  It only has one buffer per links so it
splits it up into multiple onset and abatement threadsholds and prioritizes
management messages.  It create that horrible overhead of assigining two bits
of message priority to each message.  That would never do for SCTP.

> 
> 3) Peer-to-peer flow control allows an SG to implement features such as
> reducing traffic to a lower threshold.  Much of this might be
> implementation dependent.  A congestion level of 1 would reduce traffic
> by 25%, 2 - 50%, etc...  Or a congestion level of 1 would only let
> through certain application contexts, or only new dialogs.  In any case,
> all of this is really implementation dependent, but allows switch
> vendors to implement unique/configurable features in their products that
> will still interop with all other switches.

Yes, SCCP does that using a dual timer method, but we don't want to rely
on that for SUA.  We need a completely different, much better mechanism.

Do you think you could provide some text describing this better mechanism for
the ASP Congestion draft?


--brian

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