RE: Motivation for ASPTM for congestion

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]]
> 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.
[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.
>
> >
> > 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.
[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.
>
> >
> > 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).
[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?-
>
> >
> > 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.
[TOLGA]I will have a look ASAP.
>
> 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/
>