Subject: [Sigtran] aspcong draft -congestion levels-

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 17 Oct 2005 10:12:50 -0400

Brian,

I saw that you map congestion levels in ASPSTATUS message to SS7 congestion
levels. IMO, it is better to interprete this congestion as something not
directly related with SS7 congestion. Any mapping could be done by SG. We
can have 8-bits of congestion indicating 256 levels. When SG maps the
aggregated congestion status to SS7 congestion levels, 256 is overkill but
OTOH this congestion information may be used by SG also for message
distribution purposes.

   Thanks,
   Tolga

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 17 Oct 2005 09:46:18 -0600

Tolga,

I suppose.  But how then does the ASP know what it is telling the SGP?

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

Onset and abatement thresholds in SS7 are often tuned to an equivalent
queing delay.  A HEARTBEAT procedure from the SGP might better determine
delay (and stuck ASPs as well).

Well, hopefully I acheived some basis for discussion with the draft.  I
surely didn't mean to cast anything in concrete.  We can tune it as we
move forward.

-brian

Tolga Asveren wrote:                           (Mon, 17 Oct 2005 10:12:50)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 17 Oct 2005 13:08:34 -0400

Brian,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Brian F. G. Bidulock
> Sent: Monday, October 17, 2005 11:46 AM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Sigtran] aspcong draft -congestion levels-
>
>
> Tolga,
>
[TOLGA]I agree with you totally that there should be some definiton of what
ASP is telling SG about its congestion state, just I thought it may not be
necessary to use SS7 congestion levels for that purpose.
> 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...

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 17 Oct 2005 17:35:07 -0600

Tolga,

Tolga Asveren wrote:                             (Mon, 17 Oct 2005 13:08:34)
> 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-masked]
http://www.openss7.org/

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 18 Oct 2005 08:30:48 -0400

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

> Sent: Monday, October 17, 2005 7:35 PM
> To: Tolga Asveren
> Cc: [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 18 Oct 2005 11:59:42 -0600

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 F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 18 Oct 2005 14:57:24 -0400

Brian,

> Sent: Tuesday, October 18, 2005 2:00 PM
> To: Tolga Asveren
> Cc: [email-masked]
[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?

> the job.  That is why I originally put 3, 4, 8, 8, 3 levels for M2UA,
[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.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 18 Oct 2005 19:07:50 -0600

Tolga,

Tolga Asveren wrote:                                                                  (Tue, 18 Oct 2005 14:57:24)
> 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.

> can't come up with a simple mechanism, SS7 congestion levels are probably

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-masked]
http://www.openss7.org/

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 19 Oct 2005 07:59:37 -0400

Brian,

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, October 18, 2005 9:08 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA]IMO, the number of levels desired for message distribution and the
number of levels required to aggregate SS7 congestion could be different.
OTOH, I agree with you that signaling more than to be used by SG is not a
good idea, but the idea behind allowing ASP and SG to operate on different
levels was to allow flexibility. If this is seen as a problem, using same
number of levels at both ASP and SGP could be endorsed with a SHOULD -where
the number of levels should be at least as much as the corresponding SS7
congestion levels-.
> increasing the amount of ASP Status traffic.
[TOLGA]I believe here we have different ideas -or I misinterprete what you
wrote-. IMO, congestion onset/abatement levels for ASP are better to be
provisioned by ASP itself and for SS7 congestion on SG.
> by the SGP with ASP Status Query.
[TOLGA]For now, it seems to me a better idea that ASP signals that
information, because it is ASP which has best knowledge, when the congestion
levels change for ASP.