Subject: [Sigtran] Motivation for ASPTM for congestion

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 17 Oct 2005 07:43:12 -0400

Brian,

Some text about why we want to have ASPTM for congestion is below.

   Thanks,
   Tolga

M3UA and SUA protocols allow to split SS7 application
traffic into separate pieces by utilizing the concept
of Route Keys, where traffic belonging to each Route
Key can be served by multiple M3UA entities, i.e.
multiple ASPs. The concept of RKs and utilizing
multiple ASPs allows a flexible message distribution
architecture. On the other hand this distributed
architecture brings the need to aggregate status of
SS7 entities, e.g. PCs, user parts, subsystems, at SGs, so that a unique
view can be
presented to the rest of the SS7 network. Availability
status of distributed SS7 entities is aggregated based
on ASPTM and SCTP association state on SGs. In
addition to availability, congestion status of an ASP
is also important to determine the aggregated
congestion status of a distributed SS7 entity and to
distribute messages accordingly to ASPs for SGs, which
want to do so.

Current M3UA specification relies on SCTP congestion
indications to detect congestion status of ASPs. This
has certain drawbacks as listed below:

a) A typical implementation utilizes multiple queues
between an application and SCTP layer on an ASP.
Shrinking of rwnd on peer SCTP to a level where it
prevents message transfer will happen only after
application layer congestion propogates to local SCTP
after the queues between application and SCTP are
filled up with messages to certain threshold values.

       ASP                        SGP
+------------------+       +-------------------+
|   +------------+ |       |                   |
|   |Application | |       |                   |
|   +---+---+----+ |       |                   |
|       | - |      |       |                   |
|       | - |<-----+---+   |                   |
|       | - |      |   |   |                   |
|   +---+---+----+ |   |   |                   |
|   |   M3UA     | |   |   |                   |
|   +---+---+----+ |   |   |                   |
|       | - |      |   |   |                   |
|       | - |<-----+---+   |                   |
|       ||- |      |   |   |    SCTP    rwnd   |
|   +---+---+----+ |   |   | +---------------+ |
|   |   SCTP     | |   +---+>| | | | | | | | | |
|   +------------+ |   |   | +---------------+ |
+------------------+   |   +-------------------+
                       |
                   Queues on which
                   ASP congestion needs
                   to propogate

b) An ASP may serve multiple AS and only one of them
may get congested, e.g. due to a slow data-base
access. Relying on SCTP association congestion would
cause SCTP association to get congested for traffic
for all AS served by ASP.

c) M3UA logic of ASP and application logic could
reside on different blades/CPU cards adding another
layer of communication between SCTP and application
logic, delaying propogation of congestion further.

d) Congestion of SCTP association effects all M3UA
messages regardless of their importance, e.g.
management messages are blocked by congestion as well.

Because of the facors listed above, there is a need to
communicate congestion information of ASPs in the
context of an AS to SGPs. Considering that this is
simialar to ASP being ACTIVE/INACTIVE for an AS, this
can be best accomplished with a new ASPTM serving that purpose.

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

---

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

Tolga,

Tolga Asveren wrote:                                                                 (Mon, 17 Oct 2005 07:43:12)
> filled up with messages to certain threshold values.

Not necessarily.  It is not impossible to remember which messages
for which AS are occupying the SCTP send buffer and therefore run
the buffer as multiple queues, one for each AS.

> logic, delaying propogation of congestion further.

Not a big consideration: blade to blade delay is going to be very small
compared to communicating over the Internet between ASP and SGP.

> management messages are blocked by congestion as well.

Not necessrily.  Some SCTP implementations can expedite on Stream 0.
Even if an SCTP implementation does not, if a proper threshold is
provided for congestion, M3UA management messages can continue to flow
regardless of other messages (after a certain point, only M3UA
management messages will be sent).

> can be best accomplished with a new ASPTM serving that purpose.

Don't see a problem yet.

At any rate, I have already submitted draft-bidulock-sigtran-aspcong-00
to the RFC Editor.  I made the cutoff.

I have also updated and submitted all of the other outstanding drafts
that I have:

	draft-bidulock-sigtran-tua-04.txt, .ps, .pdf
	draft-bidulock-sigtran-isua-03.txt, .ps, .pdf
	draft-bidulock-sigtran-corid-04.txt, .ps, .pdf
	draft-bidulock-sigtran-sginfo-05.txt, .ps, .pdf
	draft-bidulock-sigtran-regext-04.txt, .ps, .pdf
	draft-bidulock-sigtran-m2ua-ss7test-02.txt, .ps, .pdf
	draft-bidulock-sigtran-m2pa-test-06.txt, .ps, .pdf
	draft-bidulock-sigtran-aspext-04.txt, .ps, .pdf
	draft-bidulock-sigtran-loadsel-04.txt, .ps, .pdf
	draft-bidulock-sigtran-loadgrp-04.txt, .ps, .pdf
	draft-bidulock-sigtran-aspcong-00.txt, .ps, .pdf

You can get advance copies from

	http://www.openss7.org/docs/draft-bidulock-sigtran-aspcong-00.txt

	and so on.

It looks like using an ASP Status message causes more problems than
good.  The biggest problem is managing onset and abatement thresholds
across both the SGP and ASP.

It looks like the HEARTBEAT from CORID along with the NTFY from
ASPCONG with load selection and grouping from LOADSEL and LOADGRP will
more properly do the trick.

But its all written up in the draft.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 17 Oct 2005 09:18:31 -0400

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, October 17, 2005 9:20 AM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Sigtran] Motivation for ASPTM for congestion
>
>
> Tolga,
>
> Tolga Asveren wrote:
[TOLGA]How would it help to do what you described on sender side, if the
rwnd is per association? In addition to that, I would think it is best to
consider a standard SCTP implementation, considering that now SCPT is
becoming more a service provided by OS.
> compared to communicating over the Internet between ASP and SGP.
[TOLGA]The problem is not communication delay, but increasing the number of
queues which need to be filled up between SCTP and application. The more
queues, the longer it will take application congestion to propogate to SCTP
on SG.
> management messages will be sent).
[TOLGA]This again is a bit related with the semantics of congestion
indication provided by SCTP. If indication is given when rwnd is small
enough preventing transfer of messages, it will be already too late, but
like you have said with proper adjustment of threshold, one can overcome
this issue -does anybody know how Linux/Soalris SCTP behave reagrding this
issue?-
> 	http://www.openss7.org/docs/draft-bidulock-sigtran-aspcong-00.txt
[TOLGA]I will have a look ASAP.