Re: aspcong draft -congestion levels-

Tolga,

If the SGP sets onset or abatement analyis points within the gap in the
range of congestion levels that the ASP is sending, would not the
necessary hysteresis for the analysis be lost?

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.

--brian

Tolga Asveren wrote:                           (Tue, 18 Oct 2005 08:30:48)
> Brian,
> 
> I share your concern about message approach.
> 
> I personally prefer the approach that it is ASP which decides for congestion
> onset/abatement levels for ASP congestion because it has more inoformation
> than SG available for that purpose, e.g. latency on I/O bound operations,
> available CPU power etc..
> 
> OTOH, I believe it should be SG aggregating congestion states of ASPs and
> decide for SS7 entity congestion onset/abatement.
> 
> To prevent unnecessary messaging between ASP and SGP for congestion purposes
> without sacrificing flexibility what about something similar to that:
> - 16 congestion levels (could be actually 256 as well, just we need to set a
> limit and it should be specified in the draft)
> - From 0 to 15 , the indicated congestion level increases
> - If ASP wants to use only 2 levels, it can use 0 and 15 -similarly for 5
> levels 0,3,7,11,15, i.e. granularity can be decided by ASP and SGP does not
> need to know the desired granularity. SGP is only aware of the "maximum"
> granularity as defined by the draft and acts according to it. Basically, ASP
> can decide for the granularity necessary -and should also consider the
> assocaitied messageging cost with it, while deciding for it-,
> - If SGP wants to use less granularity than provided by ASP for its own
> processing, it can do that as well, e.g. ASP is using 16 levels and sends
> all congestion indications accordingly, SGP wants to use 2 levels, it will
> act just based on levels 0 and 7.
> 
>     Thanks,
>     Tolga
> 

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