Subject: RE: [Sigtran] aspcong draft -congestion levels-

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 20 Oct 2005 11:43:40 -0400

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-masked]]
> Sent: Thursday, October 20, 2005 10:49 AM
> To: [email-masked]; Haresign Lincoln
> Cc: [email-masked]; 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-masked] [mailto:[email-masked]] On
> Behalf Of Brian F. G. Bidulock
> Sent: Tuesday, October 18, 2005 8:49 PM
> To: Haresign Lincoln
> Cc: [email-masked]; 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-masked]
> http://www.openss7.org/
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 20 Oct 2005 17:07:21 -0600

Tolga,

Tolga Asveren wrote:                    (Thu, 20 Oct 2005 11:43:40)
> DUNA/DAVA etc... , which is not part of TCAP-user interface.

On the contrary, the TCAP-user interface described in the Q.77X series
of specifications, does include primitives for the availability and
reachability of destinations.  They happen to be the same as the SCCP
ones:

 Q.771/2.2.3 Management aspects

 SCCP Management primitives used to inform SCCP users of availability
 and non- availability of SCCP (local or remote), wil be passed
 transparently by TC to the TC-user.

That's pretty clear.  draft-bidulock-sigtran-tua-04.txt provides
DUNA/DAVA/DRST/SCON in the same fashion as SUA to accomodate this.
These are summarized in section 1.3.5.3 of the draft and detailed in
Sections 3.5.1 (DUNA), 3.5.2 (DAVA), 3.5.3 (DRST), 3.5.4 (SCON),
procedures in 4.1.2.1, and all of 4.5.

> is not what TCAP is doing.

No, I'm sorry, but that is simply wrong: SCCP management is included in
TCAP per TCAP standard specifications.  TUA simply follows standard TCAP
in passing SCCP management messages transparently to the TC-User, and
even does so with the same semantics and syntax of SUA.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 21 Oct 2005 08:23:24 -0400

Brian,

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, October 20, 2005 7:07 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA]Yes, you are right -should not think on just TCAP primitives,
destination status related ones are SCCP primitives but they are sent to the
user after all-.
> even does so with the same semantics and syntax of SUA.
[TOLGA]As far as I can see, it is not totally wrong, if a TCAP-User
Interface based UA solution supports ASPs to use multiple SGP(SG?)s. Still
some type of transport functionality need to be implemented on ASP side,
e.g. to select a SGP, and if communciation with multiple SGs are not
supported -I did not think on that one yet at all, whether it makes sense-
aggregating destination status based on SSNM for such a solution.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 21 Oct 2005 14:54:26 -0600

Tolga,

Please point to the place in the draft where you believe
these overwhelming defficiencies exist that preclude TUA
from being a useful protocol.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 21 Oct 2005 17:29:29 -0400

Brian,
> from being a useful protocol.
[TOLGA]I did not say that but it is true that personally I am not sure -let
me clarify that this is a non-rhetorical "not sure"- whether a TCAP-User
Interface based UA protocol is necessary -regardless whether it is the draft
you are mentioning or something else-.

Regarding the concept -below I use TUA to refer to a TCAP-User Interface
based UA protocol, not to the specific protocol defined in the draft-:

1- There is nothing preventing people to be creative in terms of RK types
supported for SUA -even for M3UA-. If application specific parameters are
going to be used for message distribution purposes at SG, SG will perform
deep packet inspection. This deep packet inspection is necessary also for
TUA if one wants to use application specific parameters, e.g. IMSI. Are we
going then to have a UA protocol for each application type to prevent deep
packet inspection? I consider support for different RK types as an
implementation dependent feature, which is also a differentiator for a SG.
Just because it is related with that, probably most people will remember how
CIC based RKs were removed from M3UA specification -I don't have problem
with that, still one can have any type of RK as long as it is statically
configured-. I know commercial M3UA SGs, which support CIC based RKs,
without requiring any modifications to M3UA and with no specific behavior
expected from the peer, i.e. totally based on local procedures. I believe
the issue of routing messages on SUA SG based on non-SCCP constructs is
similar to that, anything is allowable as long as it is relying on local
procedures.

2- How scalable is TUA architecture? Can one have multiple SGs -probably
not-? Will it have something similar to relaying -probably not-? Will SG
become a bottleneck easily -probable-. Will TUA have mechanisms to support
geographical distribution of traffic on SG side-probably not-? I believe
that TCAP itself is not a transport protocol may create problems related
with those issues.

3- What will TUA enable us, which is not possible with SUA? Will the net
effect be trading deep packet inspection for TIDs with TCAP processing on
SUA SG?

Regarding the TUA in the draft -below I use TUA to refer to the TUA as
defined by the draft-:
1- It could be an idea to cut protocol stack between TCAP component and
transaction sublayers.Why should one care about component layer processing
if the goal is just to implement transaction processing for TID based RKs? I
know that this sounds strange but OTOH there may be advantages as well:
a)Less processing on SG
b)Simplifies messaging between ASP and SGP
c)May help to prevent/minimize possible race conditions happening because of
separation of Component Layer state machine and TCAP-User on different
entities(Actually it may cause race conditions between component and
transaction sublayers).
Well, the disadvantage is of course that one needs to split TCAP stack in
two pieces, maybe a problem for stacks which don't have a properly designed
interface between Component/Transaction sublayers.

    Thanks,
    Tolga

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 21 Oct 2005 22:52:33 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Fri, 21 Oct 2005 17:29:29)
> effect be trading deep packet inspection for TIDs with TCAP processing on

I can't speak to your hypothetical protocol, because it is not defined, but
as regards "what can TUA do that SUA can't?" I pose the question "what can
SUA do that M3UA can't", or "what can M3UA do that M2UA can't", or "what can
M2UA do that M2PA can't."

> know that this sounds strange but OTOH there may be advantages as well:

The draft provides transport of both (or either) the TR/TR-User interface and
the TC/TC-User interface.  Use whichever you want.  It is probably not a good
idea to prohibit others from using the TC interface even if you believe that
the TR interface meets all needs.

If you read the draft, you will see that there are two groups of messages,
Dialogue Handling (DH) messages that correspond to the TR/TR-User interface
and Component Handling (CH) messages that correspond to the TC/TC-User interface.

If you read Q.771, you will see that the TC primitives are simply a superset of
the TR primitives.

For example, the TQRY message described in section 3.3.3 can have Components
included in the message and Note 2: says: "Any components SHOULD be included in
the TQRY messages but MAY be formatted in separate Component Handling (CH)
messages."

Have you read the draft?

> a)Less processing on SG

Having an SS7 stack, the SG is usually more capable at performing protocol
processing than the ASP.  To do the least processing at the SG, use M2UA.
A benefit of TUA is one can do the least amount of SS7 specific processing
at the ASP (and therefore the ASP need not worry about SS7 localizations, such
as protocol variant).

> b)Simplifies messaging between ASP and SGP

Both options exist in the draft.  You will also find both methodologies present
in Q.771 and in the Java JTCAP specification.

> entities(Actually it may cause race conditions between component and

An yet you think that SUA is capable of this?

The need for component handling arrises when, as can often occur in today's
TCAP protocols, the components are too large to fit in a single TCAP package
(or a single SCCP message) and, therefore, segmentation must be performed by
speparating component into multiple TCAP packages.

TCAP utilizes a timeout that defines the amount of time that the TC provider
will wait for additional components before an invocation is cancelled.  This
parameter is included in the CINV message and is described in section 3.11.2.8
of the draft.

If you understand the component handling state machine, component handling is
merely a set of sequential operations used to build an invocation or response
component by component instead of all at once.  There are no races in the
procedure.

> interface between Component/Transaction sublayers.

Does matter: the way the draft is written component handling can be used or not.
There are situations where it is necessary.

I don't see any difference between an improperly designed SCCP-User and an
improperly defined TC-User.  An improperly designed user will always encounter
problems.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 24 Oct 2005 08:04:55 -0400

Brian,

> From: [email-masked] [mailto:[email-masked]]On
> Sent: Saturday, October 22, 2005 12:53 AM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Sigtran] RE: draft-bidulock-sigtran-tua-04.txt
>
>
> Tolga,
>
> Tolga Asveren wrote:
[TOLGA]It does not need to be defined because it is an implementation
dependent and local procedure -BTW it is not hypothetical-. The point is
that people can be creative about RK types, there is nothing preventing them
to do so, as long as they achieve this by using local procedures without
modifying the SIGTRAN protocol used.
About necessity of SIGTRAN protocols we have right now, if I had the Occam's
razor, I could have done some cleaning -one or maybe two-. OTOH, not all of
them are redundant.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 24 Oct 2005 11:33:04 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Mon, 24 Oct 2005 08:04:55)
> >
> > I can't speak to your hypothetical protocol, because it is not
> > defined, but as regards "what can TUA do that SUA can't?" I pose the
> > question "what can SUA do that M3UA can't", or "what can M3UA do
> > that M2UA can't", or "what can M2UA do that M2PA can't."

People are also welcome to invent their own protocol.

Did you have any comments on the draft itself?

--brian

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