Subject: RE: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2

From: Tolga Asveren <[email-masked]>
Date: Mon, 11 Nov 2002 18:21:13 -0500

Brian,

There are things I agree with you and things that I disagree (please see
below). But the main point is, IMO congestion indication should match to the
general model of ASP/SG communication, so assuming that one wants to do
things like you describe (declaring SPMC congested with the first congested
ASP), still I would think the correct approach is that ASP sends congestion
indication, whenever it happens, and SG changes state of SPMC to congested.
Because this is, how ASP/SG communication works, information about local
SPMC is sent via ASPTM. IMO, it is not only important that a procedure
"somehow" works, but it is also important that it behaves according to the
architecture.

    Tolga
> 
> Errr, yes it is.  An SS7 node does not send TFC with a lower 
> congestion level
> when congestion abates.  It is only the expiry of a timer at 
> the sender of the
> RCT which causes abatement.
[TOLGA]For that I agree. In fact STP can send TFC with a lower congestion
level as response to RCT, but because we are discussing only about
congestion of endpoint I would agree with you, I didn't consider this in my
former comment.
> 
> > > 
> > > > [TOLGA] What I mean is stopping to route traffic just
> > > > to the ASP, which is congested. If the SPMC is not
> > > > congested -and IMO it is odd to consider it congested
> > > > with only one congested ASP-, traffic should be routed
> > > > to uncongested ASPs.
> > > 
> > > Which will result in congestion of those ASPs and then
> > > you will reroute again?  When do you ever route back?
> > > How do you recall messages that are queued to the
> > > congested ASP?  How much message loss and missequencing
> > > will result?  Why are not your ASPs sized so that they
> > > all have the same traffic handling capacity?  Where are
> > > you going to route traffic after the last ASP congests?
> > [TOLGA] I will route to ASP, when it is no more congested, 
> i.e. when it
> > inidates this to SG.
> 
> Won't the ASP be no more congested very shortly after you
> remove traffic from it?  Will you then thrash the traffic back
> and forth?  Once you remove it, the ASP is no more congested,
> so you put it back and then it is congested, and so on?
> 
> > The special messages -I assume you mean management messages-
> > will have high priority, so they still will be routed to the
> > congested ASP.
> 
> What special messages?
[TOLGA]SSNM, ASPTM etc....
> 
> > If ASP is so badly congested not being able to process
> > anything at all, then it will send ASPIA.
> 
> If it cannot process anything at all, how will it find
> the time to send ASPIA?
[TOLGA] I better should have said, not to be able process anymore DATA.
> 
> > Loss and missequencing will be the same with the scenario,
> > when an ASP becomes INACTIVE, when other ASPs were ACTIVE.
> 
> No, it is much worse than just going INACTIVE.  You have a
> congested ASP, meaning that there are many messages in queue.
> These will all be lost and/or potentially missequenced if you
> remove traffic from the ASP.  Do you not agree?
[TOLGA] That the messages in the queue might be lost seems unavoidable to
me. But I agree, possibility of missequencing will be higher than the
possibility going to INACTIVE case.
> 
> > RFC does not put any restriction that ASPs serving the same
> > AS should have the same processing power, and also ASPs can
> > serve a different set of AS with some of them overlapping.
> 
> It hardly carrier-class capacity engineering that you are
> proclaiming.  In carrier-class environments, capacity sizing
> is done so that if congestion occurs it is because there is
> an overload of traffic from the stimulus.  In that case,
> dropping traffic and indicating congestion is better than
> starting cascading failures by transferring the excessive
> stimulus to otherwise unaffected nodes.  There is about
> a hundred years of telephony experience in why transferring
> load is foolish.
[TOLGA] I don't know, to which extent the protocol itself should be shaped
based on the possible/common configurations. Also SIGTRAN case might be
different than regular SS7 case, now we have multiple ASPs serving the same
AS, and each ASP might serve a different set of AS. Trying to avoid
congestion by notifying the originator of traffic sounds also nice to me.
But still I don't see something wrong with the idea that it is SG, which
decides for the congestion of SPMC. Now, you might say that this is already
like this in the current RFC, but I think 90% of people reading it, will
interprete SCON from ASP to SG as a message, which will trigger TFC, i.e. it
will be ASP deciding for congestion of SPMC, that is what I basically don't
agree. 
> 
> > If the last ASP congests TFC will be generated for incoming
> > messages destined for the congested SPMC. In fact, deciding,
> > when SPMC is congested is implementation dependent. If one
> > wants, one can still declare it congested even with one
> > congested ASP, but there should be flexibility for different
> > approaches.
> 
> Yes, there is event the flexibility for the foolish approach.
[TOLGA]IMO this flexibility does not exist in the current RFC. I also think
that as a native speaker of english, you can use other words instead of
"foolish", which are more appropriate for a forum, where professional
individuals are discussing.
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 11 Nov 2002 17:16:30 -0700

Tolga,

Tolga Asveren wrote:                                                               (Mon, 11 Nov 2002 18:21:13)
> "somehow" works, but it is also important that it behaves according to the

The architecture isn't so perfect that it needs to take precedence over
function.  I believe the intentions were to have an operational protocol here,
not a pretty one that doesn't work.

> congestion of endpoint I would agree with you, I didn't consider this in my

The STP will not send TFC at a lower level than RCT: the TFC must contain the
same congestion level as the message priority in the RCT if the STP is going
to send TFC in response to it.

So how is this so different then than Kamesh's approach?

> possibility going to INACTIVE case.

So rather than changing over traffic and losing and missequencing messages, we
keep processing the messages but signal congestion at its onset (before the
discard level) to the originator of the traffic.  This is what SCON affords:
having the ASP indicate to the SG when congestion is at onset for the
specified congestion level and to the specific destination that is
statistically responsible for the traffic.  So that traffic is throttled
before an ASP gets to the point of discard.  How is the SG to determine that
the ASP is at the point of discard?  When all the other ASPs become congested?
I think not.

> based on the possible/common configurations.

The protocol very much has been shaped based on the possible/common
configurations.  It is intended as a practical protocol: not an intereseting
mind experiment.  Do you think that the protocol should ignore typical and
common configurations used in telephony?

> Also SIGTRAN case might be different than regular SS7 case, now we have
> multiple ASPs serving the same AS, and each ASP might serve a different set
> of AS.

What makes you think this is something new?  We have been designing SS7 nodes
and telephone switches this way for many years.  We also know the dangers of
mixing fixed capacity call processing with variable load service processing
(and normally keep the two well separated).  Some of the original SCP nodes
had SS7 SGs sitting in front of a number of databases acting as ASPs
communicating using (well, not SCTP/IP, but) X.25!  Did you think that nobody
ever implemented distributed user-parts in an SS7 architecture before?
Where did you think that active/standby, loadshare and broadcast came from?

> Trying to avoid congestion by notifying the originator of traffic sounds
> also nice to me.  But still I don't see something wrong with the idea that
> it is SG, which decides for the congestion of SPMC. Now, you might say that
> this is already like this in the current RFC, but I think 90% of people
> reading it, will interprete SCON from ASP to SG as a message, which will
> trigger TFC, i.e. it will be ASP deciding for congestion of SPMC, that is
> what I basically don't agree. 

It says no such thing, but that is is one very valid (and obvious) approach
anyway.  If you look back in the mailing list, you'll see that I was the one
most strongly opposed to making statements that SCON would trigger TFC (or
visa versa).  The current wording avoids such mention due to objections raised
concerning specifying the implementation specifics of the NIF (which *are*
the responsibility of the SG, regardless of the algorithm chosen).

I think the current wording allows many implementation approaches, some unwise
and some that could endanger the health of an SS7 network such as you have
proposed.

> individuals are discussing.

A "foolish" approach is one which has no basis in experience.  It is used
in reference to a technical approach, not any individual.

So, if you think that a text change or clarification is required, what is
the text that you would propose?

--brian

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