RE: aspcong draft -congestion levels-

Brian,

The following may be unique to SUA, but would be very nice:

Another thought, if the ASP-SG relationship is using the TID parameter
for routing, I think it would be useful to have traffic reduction on the
SG as one of the congestion methods in addition (or alternately) to
using priority/importance.  Perhaps this can be aligned with # of
congestion levels supported.

For example:

- Assume that we have 2 ASPs (ASP1 & ASP2) and both of them are using
the TID parameter to assure that all traffic for ongoing dialogs are
properly routed.

- Assume we have 8 levels of congestion.

- Assume we are using round-robin for all new incoming dialogs.

If ASP1 goes to congestion level 1, it would mean reduce _NEW_ dialogs
by 12.5%.  If ASP1 goes to congestion level 8, it would mean reduce
_NEW_ dialogs by 100%.  ASP1 will still receive messages for existing
dialogs.

Of course, this could be done with 4 congestion levels or 256, but I
think somewhere between 8 and 16 is probably sufficient.  With the
appropriate hysterisis built in at the ASP, this should prevent
unneccessary oscillation of traffic.  The ASP will slowly be able to
increase traffic after some event that may have caused congestion.

I haven't really looked at this from the other UA perspectives.

Regards,
Lincoln

-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Haresign Lincoln
Sent: Tuesday, October 18, 2005 3:00 PM
To: [email protected]
Cc: [email protected]; Tolga Asveren
Subject: RE: [Sigtran] aspcong draft -congestion levels-

Brian,

OK, In general I have no problems with what you have indicated below. 

I'll take a look at your other drafts and provide some feedback if it
seems relevant.

Regards,
Lincoln  

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]]
Sent: Monday, October 17, 2005 7:26 PM
To: Haresign Lincoln
Cc: [email protected]; Tolga Asveren
Subject: Re: [Sigtran] 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/

______________________________________________________________________
  This email message has been scanned by PineApp Mail-Secure and has
been found clean.



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