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