RE: aspcong draft -congestion levels-

Brian,

In general, this looks very good.  I have a few minor thoughts/questions
regarding your draft:

- When an ASP detects congestion in the UA layer of the ASP and sends an
ASPSTAT message, and it has associations to multiple SGPs within a
single SG, does it send the message to ALL SGPs.

- Are we at all concerned about the scenario that the SG may think an
ASP is congested, but the ASP is not.  In which case we are in a
permanent block condition.  This might be solved with either an ASPSTAT
ACK message, regular ASPSTAT QUERYs, or a timed procedure in the SG to
knock down traffic a certain level.  Not sure if we want to mandate this
or not and some of the previous suggestions are better than others.

- Are we at all concerned about the scenario that the SG doesn't realize
the ASP is congested even though it sent an ASPSTAT message.  This might
be solved with either an ASPSTAT ACK message or regular ASPSTAT messages
if the ASP continues to receive data (every nth message).  Not sure if
we want to mandate this or not.

- Section 1.6.2, last paragraph: You indicate that the "SG SHOULD cease
passing traffic...".  Do you think this should be a SHOULD and not a
MAY?  This would give flexibility such as the ability to reduce traffic
in the case that there might not be an "importance level" in the
message.  It also gives flexiblity to the SG implementors.

- Section 1.8, paragraph 3 (and also the Implementation note [3] for
Section 1): I would recommend milder language rather than a definite
"SHOULD NOT" as I believe there are scenarios that we are working with
where the SG can make intelligent decisions about redistribution.  It is
not a trivial problem, but we have some ideas for how this could be
handled effectively (e.g., slowly bringing traffic back online).  You
have language warning about the dangers and I think this is good.  The
other documents are draft and may or may not ever be accepted, so
specifying that it SHOULD be done in this way is, IMHO, problematic.
Perhaps if you say that it MAY be done using the other draft methods
will divorce this draft from the others and we can address each draft
seperately.  I'm not strong on this though as you have not ruled it out.

- Section 1.8, paragraph 4: I'm a little confused by this paragraph.
The 1st sentence is not clear.  And the paragraph seems to be saying to
use some other method [CORID] rather than the ASPCONG draft.  I
understand the principle you are specifying to measure outstanding
traffic.  I'm just not sure what the point of the last sentence is.

- Section 3.1.1:  Do you think it would be practial to use some of the
"reserved" bits as an indicator to what the SG SHOULD do?  For example,
if we ar not in the pure discard mode we could take certain actions:
discard, reduce traffic, redistribute traffic (I know you are not
excited about this last one).  This might be practical when there is not
a priority/importance in the message and/or we don't want to purely
discard everything.  

- There are a few very minor grammatical errors.  I don't know if you
are interested in what I found at this point since it may undergo
further edits.

Overall, I think this is very good and it definitely resolves all the
problems that I was looking to be solved.  I'm uncertain what we should
do with the SCON.  Since SCON is support in IPSP, and you can have an
ASP work identically to an IPSP SE client.....I have no good answer for
this.

Regards,
Lincoln

-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Brian F. G. Bidulock
Sent: Monday, October 17, 2005 11:46 AM
To: Tolga Asveren
Cc: [email protected]
Subject: Re: [Sigtran] aspcong draft -congestion levels-

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,
> 
> 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 protected]
> https://www1.ietf.org/mailman/listinfo/sigtran

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

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