RE: aspcong draft -congestion levels-

IMHO, it is not that straightforward what to do about improved TID based
routing support. First let't see what TCAP and SCCP provide:

SCCP: transport functionality
TCAP: asynchronous remote procedure call semantics

As far as I can see, one can't just provide TCAP-User interface to
applications and expect them to do something usefull, they need to receive
SCCP primitives as well to decide reachability of destinations. So, there is
no architecturally pure solution to that problem, any solution mimicing TCAP
user-interface should also include transport related messaging like
DUNA/DAVA etc... , which is not part of TCAP-user interface.

Considering the distributed architecture of SIGTRAN UA protocols, all of
them also have some transport functionality in that context, e.g. ASPs may
communicate with multiple SGPs adn based on reachability information of the
SGPs, status for SS7 destinations may change as well.

It seems, a SCCP User-Interface based solution would need to perform some
TCAP processing to be able to support improved TID based routing. Similarly
a TCAP User-Interface based solution needs to implement some transport
related functionality and should support transport of SCCP primitives, which
is not what TCAP is doing.

   Thanks,
   Tolga



> -----Original Message-----
> From: Doss, James [mailto:[email protected]]
> Sent: Thursday, October 20, 2005 10:49 AM
> To: [email protected]; Haresign Lincoln
> Cc: [email protected]; Tolga Asveren
> Subject: RE: [Sigtran] aspcong draft -congestion levels-
>
>
> Hi Brian and Lincoln,
>
> I have been closely monitoring the TID related email trail. I would be
> interested in TUA being in place because TID is more relevant to TCAP
> user. It is more appropriate to have TUA have the correlating the
> Transaction IDs of query and responses. The 3GPP GSM MAP, ANSI41 MAP for
> CDMA networks, AIN-0.1 (GR 1299) and CNAM and other services uses TCAP
> level service. I have been working with TCAP-query look up systems for
> many years and the loss due to signaling links are not acceptable (SLA
> is addressing this issue - many times we have paid the price - high
> redundancy is desired and message losses are not tolerated by the
> carrier) and if it is frequent it is going to affect the system
> performance.
>
> If TUA is coming back in active mode I am willing to particpate in the
> discussions.
>
> -James Doss
> VeriSign Inc
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Brian F. G. Bidulock
> Sent: Tuesday, October 18, 2005 8:49 PM
> To: Haresign Lincoln
> Cc: [email protected]; Tolga Asveren
> Subject: Re: [Sigtran] 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/
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>