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

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

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.

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/