RE: draft-bidulock-sigtran-tua-04.txt

Brian,
> Please point to the place in the draft where you believe
> these overwhelming defficiencies exist that preclude TUA
> 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