Subject: RE: [Sigtran] aspcong draft -congestion levels-

From: "Haresign Lincoln" <[email-masked]>
Date: Mon, 17 Oct 2005 14:31:49 -0400

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-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,

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

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

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

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 17 Oct 2005 14:33:03 -0400

> ASP work identically to an IPSP SE client.....I have no good answer for
[TOLGA]This is an interesting issue. I believe it should be possible to use
ASPSTATUS for IPSP communication as well. OTOH one could argue that this is
not-so-clean from architecture point of view for SE mode. In SE mode ASPTM
has meaning bothways, i.e. traffic for AS is activated/inactivated with a
single ASPTM in both directions. For congestion case, this won't be true
necessarily, i.e. two peers won't get congested simultaneously. Still,
considering that congestion information about peer IPSPs may be useful for
traffic distribution purposes as well, I think we can sacrifice some
architectural sanity in this case.

---

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

Lincoln,

Haresign Lincoln wrote:                                                           (Mon, 17 Oct 2005 14:31:49)
> single SG, does it send the message to ALL SGPs.

Yes, I think so.  The idea is to parallel other ASPTM messages such as
ASP Active.  Other ASPTM messages are specific to an SCTP association,
so I figured the ASP Status should be as well.

> or not and some of the previous suggestions are better than others.

That was the idea of the ASP Status Query message, to give the SGP the
ability to verify the ASP's congestion status when the SGP deems
necessary.

For M3UA, an ASP Status Query could, for example, be initiated upon
receipt of a corresponding signalling route set test message from the
SS7 network.

For SUA, a dual timer approach could be used and ASP Status Query
launched when the timer goes to reduce the congestion level.

I think that the only requirement that needs to be placed is that the
ASP MUST respond with an ASP Status to an ASP Status Query that is
received in an expected state.

> we want to mandate this or not.

Well, the problem is that ASP Status is being sent on a possibly
congested link.  It will not be lost (SCTP will not lose it) and it will
arrive in due course.  As the SGP is not really required to take any
immediate action upon receipt of the ASP Status that needs
syncrhonization between ASP and SGP, as is the case for, say, ASP
Active, I think it might not accomplish anything to acknowledge the ASP
Status.  In the other direction, the ASP Status Query is acknowledged
with an ASP Status.  Sending every n'th message might simply contribute
to SCTP association congestion in the reverse direction.

Certainly, if the association is too congested for the ASP Status to get
through, the fallback is to ASP Congestion detection local to the SGP.

> message.  It also gives flexiblity to the SG implementors.

Oh, I didn't mean cease all traffic (but that's probably the way I wrote
it).  I meant ceasing traffic below the priority/importance level that
was indicated to the ASPs in a NTFY("AS-CONGESTED") message.  This
parallels NTFY("AS-PENDING").  The idea is that the SGP notifies all
ASPs ASP-ACTIVE or ASP-INACTIVE in the AS that it is about to start
discarding messages and returning congestion notifications toward the
SS7 Network if the ASPs don't do something about it (e.g. activate
another ASP).

> seperately.  I'm not strong on this though as you have not ruled it out.

SHOULD NOT and MAY are about the same thing.  However, there is not only
a danger of loss or mis-sequencing of messages, but of overly congesting
the IP network by oscillating traffic between associations.  We might
even have to land on MUST.

The principle of ASP traffic management is, as noted, that the ASPs are
in control of which ASPs receive traffic (with ASP Active and ASP
Inactive).  The premise in the current UA specifications is that the SG
equally loadshares traffic within a Loadshare AS, and, also, that the
SG give due consideration to circuit or transaction state when doing so
(i.e, does not distribute messages relating to the same circuit or
transaction across diverse ASPs serving the AS.)

This is largely because the ASPs are responsible for coordination of
circuit state and transaction state between ASPs in the pool.  If the
SGP simply redistributes traffic, the ASP to which the traffic is being
offered migth not have immediate access to the circuit or transaction
state, requiring syncrhonization with the previous ASP before traffic
can be handled.  This would also contribute to congestion and
oscillation.

For SUA, if the TID or DRN labels are used, as noted on the list
recently, they effectively override any load sharing algorithm that
the SGP might use, and the SGP has no choice for redistribution of
traffic.

Use of the TID and DRN labels in SUA is similar to the more general load
selection procedures presented in draft-bidulock-sigtran-loadsel and
draft-bidulock-sigtran-loadgrp.  Note that, even without LOADSEL or
LOADGRP, an SUA ASP can decide to go ASP-INACTIVE for a label range and
another ASP can decide to go ASP-ACTIVE for the same label range
resulting in the redistribution of traffic at the SGP, but under ASP
control.

This is the preferred way of doing things in the SIGTRAN UAs: the ASP
is in control.  The purpose of the NTFY("AS-CONGESTED") message is to
inform all ASPs ASP-ACTIVE or ASP-INACTIVE for the AS of the overall
congestion status of the AS so that the ASPs can decide amoungst
themselves which is going to take over traffic.

So, for example, upon congestion of an ASP and receipt of a
NTYF("AS-CONGESTED"), another ASP in the pool can decide to take steps
to transfer transaction state from the congested ASP and then take
steps for the congsted ASP to deactivate for a label range and have the
non-congested ASP activate for the same range.

We talked on the list a while back about using ASP Id to allow one
ASP to deactivate another, the idea being at the time that a healthy
ASP might be in a better position to detect a failing ASP that the
failing ASP itself.

LOADSEL and LOADGRP is a little more convenient in this regard because
the ASP can be active for more than one load selection at a given point
in time, permitting a finer granularity of segmentation of traffic and
failover.  LOADGRP even permits failover within a load selection.

> traffic.  I'm just not sure what the point of the last sentence is.

Just thinking out loud about some other possibilities.  This is a first
cut at a draft.  Don't worry, none of the text is unchangeable.  I was
just trying to capture some thoughts in the Issues and Conclusions
sections.  These sections would likely be removed altogether if the
draft moves toward finalization.

> a priority/importance in the message and/or we don't want to purely

I agree with the purpose, it is the subject of draft-bidulock-sigtran-loadsel
and draft-bidulock-sigtran-loadgrp.  I believe that the ASP should not
recommend discard, reduction or redistirbution, but should, instead,
command it.  The mechanisms described in these two load distribution
drafts provides the ASP with protocol elements and procedures for
commanding the SGP exactly which traffic flows to act upon using
definitions agreed upon between ASP and SGP.

> are interested in what I found at this point since it may undergo

I was typing quite quickly.  I appologize for the initial sorry state of
the grammar and spelling.

> ASP work identically to an IPSP SE client.....I have no good answer for

I was not recommending getting rid of SCON altogether, just in the
ASP->SG direction.

Thanks for the comments.  Please take a look at the LOADSEL and LOADGRP
drafts as I am quite certain that some of the issues that you have with
existing load distribution between SGP and ASP can be solved by
approaches similar to those outlined in those drafts.

--brian

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