Re: aspcong draft -congestion levels-

Lincoln,

I think it would be a better idea to use TUA
(draft-bidulock-sigtran-tua-04.txt in the group of drafts that I just
submitted) instead of expecting an SUA SG to do anything with TID.  Just
to extract the TID would require most of a fully functional TCAP TR
sublayer, and a SS7 TCAP Variant specific TCAP TR sublayer at that.  For
SUA we pretty much drew the line at using a TID blindly to distribute
traffic over ASPs, and any message not containing a destination
transaction ID are load shared on some other basis, along the lines of
your example.

However, the SUA SG is not required to identify a messages without a TID
as being a "new transaction".  To do so would require another level of
TCAP message parsing and state machine that does not make sense at an SG
containing only up to an SCCP layer.  For example, in 3GPP MAP, there
are a good number of procedures that require correlated trasnactions.
To ensure that all correlated transactions arrive at the same ASP would
require a state machine.  Once you have a state machine, TUA makes much
more sense.

We only left TID in the SUA spec because there was no TUA to address
requirements for distribution of transactions across.

So, IMO TUA better addresses handling of TCAP transaction and dialogues
between SGP and ASP, and load selection and distribute is best
controlled by an ASP using the mechanisms of LOADSEL and LOADGRP.  See

  http://www.openss7.org/docs/draft-bidulock-sigtran-tua-04.txt
  http://www.openss7.org/docs/draft-bidulock-sigtran-tua-04.ps
  http://www.openss7.org/docs/draft-bidulock-sigtran-tua-04.pdf

  http://www.openss7.org/docs/draft-bidulock-sigtran-loadsel-04.txt
  http://www.openss7.org/docs/draft-bidulock-sigtran-loadsel-04.ps
  http://www.openss7.org/docs/draft-bidulock-sigtran-loadsel-04.pdf

  and

  http://www.openss7.org/docs/draft-bidulock-sigtran-loadgrp-04.txt
  http://www.openss7.org/docs/draft-bidulock-sigtran-loadgrp-04.ps
  http://www.openss7.org/docs/draft-bidulock-sigtran-loadgrp-04.pdf

(These should appear on the ietf internet-draft servers soon.)


--brian


Haresign Lincoln wrote:                      (Tue, 18 Oct 2005 16:05:48)
> Brian,
> 
> The following may be unique to SUA, but would be very nice:
> 
> Another thought, if the ASP-SG relationship is using the TID parameter
> for routing, I think it would be useful to have traffic reduction on the
> SG as one of the congestion methods in addition (or alternately) to
> using priority/importance.  Perhaps this can be aligned with # of
> congestion levels supported.
> 
> For example:
> 
> - Assume that we have 2 ASPs (ASP1 & ASP2) and both of them are using
> the TID parameter to assure that all traffic for ongoing dialogs are
> properly routed.
> 
> - Assume we have 8 levels of congestion.
> 
> - Assume we are using round-robin for all new incoming dialogs.
> 
> If ASP1 goes to congestion level 1, it would mean reduce _NEW_ dialogs
> by 12.5%.  If ASP1 goes to congestion level 8, it would mean reduce
> _NEW_ dialogs by 100%.  ASP1 will still receive messages for existing
> dialogs.
> 
> Of course, this could be done with 4 congestion levels or 256, but I
> think somewhere between 8 and 16 is probably sufficient.  With the
> appropriate hysterisis built in at the ASP, this should prevent
> unneccessary oscillation of traffic.  The ASP will slowly be able to
> increase traffic after some event that may have caused congestion.
> 
> I haven't really looked at this from the other UA perspectives.
> 
> Regards,
> Lincoln
> 

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