RE: aspcong draft -congestion levels-

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]]
> Sent: Tuesday, October 18, 2005 9:08 PM
> To: Tolga Asveren
> Cc: [email protected]
> Subject: Re: [Sigtran] aspcong draft -congestion levels-
>
>
> Tolga,
>
> Tolga Asveren wrote:
>                     (Tue, 18 Oct 2005 14:57:24)
> >
> > Now let me try to build a "bad" example:
> > -Obviously the easiest "bad" example is where congestion
> communicated by ASP
> > is less granular than the congestion granularity of corresponding SS7
> > entity, e.g. ASP reports only 2 levels of congestion and SS7
> entity has 4
> > levels. This could cause problems if  there are few ASPs, e.g. only
> > one -with a sufficiently large number of ASPs should work
> though-.This can
> > be worked around by forcing ASPs to notify at least as many congestion
> > levels as the SS7 entity or face the consequences. Would it be
> a reasonable
> > solution if we ask ASP to honor that principle, or wil there be
> other cases,
> > where this mechanims still won't work?
>
> If the ASP need know the number of levels, is it not wasteful to
> signal more?
> Signalling 16 levels when only 4 are required is a bad idea.  It increases
> the rate of ASP Status messages send while doing nothing to
> increase the utility
> of the protocol.
[TOLGA]IMO, the number of levels desired for message distribution and the
number of levels required to aggregate SS7 congestion could be different.
OTOH, I agree with you that signaling more than to be used by SG is not a
good idea, but the idea behind allowing ASP and SG to operate on different
levels was to allow flexibility. If this is seen as a problem, using same
number of levels at both ASP and SGP could be endorsed with a SHOULD -where
the number of levels should be at least as much as the corresponding SS7
congestion levels-.
>
> >
> > >
> > > I think that if the ASP is to send level, the ASP and SGP must agree
> > > on a contiguous set of levels that are sufficient and necessary for
> > > the job.  That is why I originally put 3, 4, 8, 8, 3 levels for M2UA,
> > > M3UA, SUA, TUA, ISUA.
> > [TOLGA]That is also not unacceptable, just I am throwing out
> ideas to see
> > whether it is possible not to map ASP congestion/SS7 congestion
> > directly -they will be indirectly tied though-. The SS7
> congestion levels
> > are obviously a logical choice to aggregate the SS7 congestion but for
> > message distribution a little bit more flexibility could be
> useful. If we
> > can't come up with a simple mechanism, SS7 congestion levels
> are probably
> > the way to go.
>
> Well, I suppose the goal of this mental exercise was to see if
> there is a good
> way around operators having to administrate thresholds at both
> the SGP and the
> ASP.  Message (or message octet) counts was one thought, a wider number of
> congestion levels is another, but both have to the problem of excessively
> increasing the amount of ASP Status traffic.
[TOLGA]I believe here we have different ideas -or I misinterprete what you
wrote-. IMO, congestion onset/abatement levels for ASP are better to be
provisioned by ASP itself and for SS7 congestion on SG.
>
> One thought in that direction is to not have the ASP send ASP
> Status autonomously
> at all: i.e, have the ASP only respond with ASP Status if an when queried
> by the SGP with ASP Status Query.
[TOLGA]For now, it seems to me a better idea that ASP signals that
information, because it is ASP which has best knowledge, when the congestion
levels change for ASP.
>
> My original thoughts are that an approach using Correlation Id/Ack or BEAT
> along the lines of their existing use in CORID would be a better
> mechanism for
> the SGP to monitor effective buffer occupancies at the ASP on
> whatever basis
> the SGP sees fit (e.g, messages, message octets, or even message
> handling delay).
> In which case ASP Status and ASP Status Query could be dropped altogether.
>
> But that's for the next draft, I think.
>
> --brian
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>