Re: aspcong draft -congestion levels-

Lincoln,

Haresign Lincoln wrote:                                                           (Mon, 17 Oct 2005 14:31:49)
> 
> 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.

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.

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

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.


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

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.

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

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

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

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.

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

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.

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

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.

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

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

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

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