RE: Motivation for ASPTM for congestion

Brian,

I agree with your "not necessarily".  But on the other hand, it could
be.  So I think that the justifications are valid in some cases.
However, I guess the whole discussion is moot since you already
submitted a draft.  So I guess you're not looking for any text to add to
the document.

I'm not sure why you say using an ASP Status message causes more
problems than good.  Managing offset and abatement thresholds are
usually an implementation specific item just like in SCTP and are not
typically specified except to state that they should exist and be
managed with a certain level of hysteresis.

In any case, I'll read your drafts starting with the aspcong doc and
provide feedback.

Regards,
Lincoln

-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Brian F. G. Bidulock
Sent: Monday, October 17, 2005 9:20 AM
To: Tolga Asveren
Cc: [email protected]
Subject: Re: [Sigtran] Motivation for ASPTM for congestion

Tolga,

Tolga Asveren wrote:
(Mon, 17 Oct 2005 07:43:12)
> 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.

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.

> 
> 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.

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

> 
> d) Congestion of SCTP association effects all M3UA messages regardless

> of their importance, e.g.
> 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).

> 
> 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.

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 protected]
http://www.openss7.org/

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

______________________________________________________________________
  This email message has been scanned by PineApp Mail-Secure and has
been found clean.