RE: aspcong draft -congestion levels-

Brian,

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Brian F. G. Bidulock
> Sent: Tuesday, October 18, 2005 2:00 PM
> To: Tolga Asveren
> Cc: [email protected]
> Subject: Re: [Sigtran] 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?
[TOLGA] I am not sure whether I understood you 100% -you may be right
though-, just to make it easier for myself, I will provide a numerical
example -and please feel free to change it the way you want to emphasize
problem situations-
Assumption:
ASP sends levels 0 and 15, i.e. either congested or not congested. Hyteresis
for ASP congestion is provided by ASP.
SGP chooses to use all 16 levels while distributing traffic to ASPs and to
aggregate SS7 enttity conestion state. Let's assume we have 4 levels of
congestion for this SS7 entity.

I would expect traffic distribution logic on SGP to work similar to the
following:
Each ASP has a dynamic weight set according to its congestion value,
congestion level 0 ==> ASP weight 16, congestion level 1 ==> ASP weight 15
etc...
SGP would distribute traffic according to those weights -it also could be
the case that after certain congestion level, ASP is taken out of
distribution list-. As far as I can see, hysteresis provided by ASP should
be enough to make this mechanism work. In the example, ASP will send only
congestion level 0 and 15, but this probably won't break anything on SG.

I would expect SS7 congestion aggregation in SG to work similar to the
following:
SG decides for congestion onset/abatement levels via configuration. Let's
say, according to configured value if average ASP congestion level is 7, SS7
entity congestion changes to level1, and when average drops to 5, SS7 entity
congestion level becomes 0.
Let's assume we have 4 ASPs and they all send only levels 0 and 15:
7*4=28, this is the sum of congestion levels to switch to level1
5*4=20, this is the sum of congestion levels to switch back to level0

One ASP sends level15, sum_of_cong = 15 , SS7 entity cong. in level0
Another ASP sends level15, sum_of_cong = 30, SS7 entity cong. switches to
level1
One of the congested ASPs sends level0, sum_of_cong =15, SS7 entity cong.
switches to level0

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?

>
> 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.
>
> --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/
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>