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

From: Tolga Asveren <[email-masked]>
Date: Mon, 11 Nov 2002 08:46:19 -0500

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Sunday, November 10, 2002 3:31 PM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2
> 
> 
> Tolga,
> 
> Tolga Asveren wrote:                                  (Sun, 
> 10 Nov 2002 08:42:54)
> > [TOLGA]IMO, relying only on a timer is not a good
> > idea. SG should know, when congestion ends, without a
> > timer. With timer, you limit the duration of
> > congestion to a predefined value.
> 
> I disagree 100%: In Kamesh's approach the timer is a good
> thing,  Not only does it protect from ASPs which do not signal
> abatement, but it does limit the duration of congestion to a
> predefined value, which is exactly what the sender does in SS7
> with the route set congestion test procedure and is also a
> good thing.
[TOLGA]What I am saying is not not to use a timer at all but not to rely
only on a timer. Because current RFC does not indicate that SCON should be
sent when congestion abates, the only thing to be done is to rely on the
predefined value of the timer. This is not, what happens in SS7, RCT is
replies with TFC if necessary. There is also timer, but it is not the only
thing, which is relied on. 
> 
> > [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. The special messages -I assume you mean management
messages- will have high priority, so they still will be routed to the
congested ASP. If ASP is so badly congested not being able to process
anything at all, then it will send ASPIA. Loss and missequencing will be the
same with the scenario, when an ASP becomes INACTIVE, when other ASPs were
ACTIVE. 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. 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.
> 
> > [TOLGA] Here you consider relationship between ASP/SG
> > as MTP/MTP-User part relationship, but to justify SCON
> > as it is now in RFC you refer to MTP3-MTP3
> > relationship as described in MTP3 specs. That is, what
> > I mean with contradiction.
> 
> There is no contradiction.  It was intentional to stretch
> the relationship to provide for the multiple SG case.
> 
> > > Non-backhaul scenarios are optional.
> > [TOLGA] I believe non-backhaul scenarios should be
> > supported, but in a proper way, which IMO is SG-SG
> > communication.
> 
> They are supported but not required.
[TOLGA] IMO, non-backhaul case is important but unfortunately poorly
supported as for now.
> 
> --brian
> 
> -- 
> 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: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 11 Nov 2002 08:46:02 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Mon, 11 Nov 2002 08:46:19)
> thing, which is relied on. 

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.

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

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

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

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

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

--brian