RE: aspcong draft -congestion levels-

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


> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Brian F. G. Bidulock
> Sent: Monday, October 17, 2005 7:35 PM
> To: Tolga Asveren
> Cc: [email protected]
> Subject: Re: [Sigtran] aspcong draft -congestion levels-
>
>
> Tolga,
>
> Tolga Asveren wrote:                             (Mon, 17 Oct
> 2005 13:08:34)
> > >
> > > I am toying with the idea of having the ASP report congestion in terms
> > > of number of messages (or message octets) queued rather than
> a congestion
> > > level.  That might avoid the problem of managing onset and abatement
> > > thresholds in two places (i.e, the SG could manage the
> thresholds and just
> > > have the ASP report an effective occupancy level).
> > [TOLGA]This is an interesting idea, is almost like to provide a virtual
> > queue semantics between ASP and SG. There are also a few things
> to consider
> > about it, e.g. non-homogeneous ASPs in terms of processing
> power, whether
> > processing power of ASP needs to be known by SG etc...
>
> The only problem with the message (or message octet) approach is
> that it could
> cause the ASP to send as many as two ASP Status messages for each
> received user
> message: once for when it is queued and once for when it is dequeued.
>
> This is also a problem with introducing too many congestion
> levels (e.g, 256)
> in that redundant ASP Status traffic will increase dramatically.
> So, for example,
> whereas M3UA only really requires 4 levels, sending ASP Status on
> the basis of
> 256 levels will cause 256/4 or 64 times the number of ASP Status
> messages as are
> required.  If the levels are too granular (so that the level
> changes with the
> enqueuing or dequeuing of a single message), again the ASP could
> discover itself
> sending two ASP Status messages for every received user message.
> This would
> probably not be acceptable.
>
> So, I'm still struggling for a way to maintain the thresholds
> only at the SG,
> but not have the ASP send excessive ASP Status messages.  Again,
> I think that
> a HEARTBEAT or Correlation Id/Ack procedure might work better.
>
> --brian
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>