aspcong draft -general comments-

Brian,

Questions/comments I came up with till now about ASPCONG draft.

   Thanks,
   Tolga

- "1.4 Overview" mentions only about providing congestion toward SS7-Users.
On use case of ASPCONG is to distribute messages according to ASP congestion
status on SG. I think, this needs to be mentioned. Actually IMHO a more
complete motivation section could make it clearer why we want ASPCONG.

- IMHO, this draft should focus only on ASPSTATUS message and related
procedures. Other ways of detecting/handling congestion could be another
draft -if it is seen as necessary, we can have also a draft which discusses
for what reasons ASP congestion information seems to be necessary and why
existing SCTP congestion based approach is not always satisfactory-

- "Congestion beyond the interface between the UA protocol layer and
  the Application Server (e.g. congestion within the Application Server
  function itself), is not considered as part of ASP Congestion, but is
  considered as congestion within the SS7 User layer for the
  corresponding UA."
I disagree with that. Application logic is distributed as well and we need
to know which instance is congested how much so that we may provide some
intelligent message distribution on SG. It may be the case that application
detects/foresees congestion earlier than the queue between application and
M3UA is abova a certain threshold value based on some other means, e.g.
average latency on database access.

- Do we really need Notify("AS-CONGESTED"). We already have
NOTIFy("Insufficient ASP resources active in AS"). What other information
does NOTIFY("AS-CONGESTED") provide, or do we need to distinguish between
"CONGESTED" and "Insufficient ASP resources active in AS" case in ASPs?

-"The UA protocols were designed to permit a Nodal Interworking
         Function (NIF) to be placed over an existing SS7 protocol layer
         provider and, using only the primitives and interface to the
         SS7-Provider that is available to a normal SS7-User as
         described by the SS7 standards, provide the functions necessary
         to implement a Signalling Gateway (SG) in the back-haul SG/ASP
         configuration.

         The ASPSTAT message would remove this ability."
I agree with this concern but this need arises due to distribution of user
part/application logic to multiple instances and is not mandatory to
support -but yes, still it is a good idea to mention about this-


-     "A mechanism where the management of onset and abatement
         thresholds are contained within the SG if not within the SS7
         provider layer is far more preferable than the arrangement
         required by the ASPSTAT message."
Yes, agreed. IMO, that is one of the reasons why we need to conveey ASP
congestion status to SG so that SG can aggregate congestion status of the
SS7 entity. OTOH I am confused that you list this as an "Issue", for me this
supports the idea to have ASPSTATUS.


-"The UAs have an existing optional mechanism for communicating
         SS7 User congestion to the SG.  For  [M3UA-BIS, SUA, ISUA, TUA]
         that mechanism is the use of the SCON message in the ASP to SG
         direction.  For [M2UA] it is the use of the Status Request
         message.

         Adoption of ASPSTAT message would likely require the removal of
         that mechanism so that it does not conflict with the ASPSTAT
         mechanism."
Yes, agreed. It probably is not a good idea to have both simultaneously.
Afterall, wasn't SCON in ASP=>SG direction already a stepchild and was
(mis)used most of the time, instead of ASPSTATUS?

-"Use of the ASP Status procedures at the SG for redistribution
         of traffic within an AS can be dangerous.  Without proper
         knowledge about the load characteristics of the ASPs serving an
         AS, an SG could provoke rapid oscillations in load distribution
         across the ASP pool."
I see your point, but IMHO this could be mentioned in a more positive way
and also emphasizing that this type of message distribution is optional and
implementation dependent. It could be confusing to discuss different methods
serving the same purpose in a draft where one of those methods is also
defined, maybe another draft comparing different mechanisms could be a
better approach, just my 2 cents.