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

From: Tolga Asveren <[email-masked]>
Date: Fri, 8 Nov 2002 10:20:37 -0500

Kamesh,

a) You put the SPMC to congested status even when only one ASP is congested.

b) After receiving TFC the peer in SS7 domain will stop sending messages and
will send RCT. So, there won't be any DATA to be pumped from SG to ASP,
there you rely only on a timer.

For both of those reasons (especially a) ) I disagree with that method.

    Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, November 08, 2002 9:51 AM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: RE: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2
> 
> 
> 
> 
> Tolga
>      Let us assume SPMC congestion level  0 initially. Now when one
>                  of the ASP (out of 3 ASP's) sends SCON in 
> response to DATA
> message
>                  received. SPMC congestion status is updated 
> to lets say 1 (as
> received
>                  in SCON message).Now as SPMC congestion 
> status is updated TFC
>                  will be send to conerned PC , Concerned 
> Point code will start
> RCT procedure.
>                  At SG congestion timer (per SPMC ) will 
> start on reception of
> SCON. If SG
>                  side goes on pumping data messages to 
> congested ASP. Data
> messages
>                  in a way will audit ASP congestion status. 
> If no SCON message
> is received
>                  by SG till congestion timer expires SG will decrement
> congestion level of SPMC
>                  assuming congestion abatement.
> Regards
> Kamesh
> 
> 
> 
> 
> Tolga Asveren <[email-masked]> on 11/08/2002 08:14:52 PM
> 
> To:   "[email-masked]'" <[email-masked]>
> cc:    (bcc: Kamesh Kaul/HSS)
> 
> Subject:  RE: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2
> 
> 
> 
> 
> Kamesh,
> 
> For example in the scenario in my original message (3 ASPs, 
> one of them gets
> congested and sends SCON as response to a received DATA), 
> what would you
> expect SG to do? Also, how should SG resposne to an incoming 
> RCT afterwards,
> just set a timer and wait till it times out (if there won't 
> be any more DATa
> to send to congested ASP)?
> 
>     Tolga
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Friday, November 08, 2002 9:20 AM
> > To: Tolga Asveren
> > Cc: [email-masked]
> > Subject: RE: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2
> >
> >
> >
> >
> > Tolga
> >      It may be typo. In my openion TFC will be generated by SG
> >                 if and only if SPMC congestion status is
> > changed on reception
> >                 of SCON from any ASP(serving SPMC). Also SCON from
> >                 ASP is send only when ASP receives MSU's from
> > SG in congested
> > state. In my openion
> >                 SG has to have a timer per SPMC to provision
> > congestion status
> >                 of SPMC. There is no way by which SG will
> > come to know about
> > congestion abatement
> >                 of ASP'S serving SPMC.
> > Regards
> > Kamesh
> >
> >
> >
> >
> >
> >
> > Tolga Asveren <[email-masked]> on 11/08/2002 07:50:06 PM
> >
> > To:   [email-masked]
> > cc:    (bcc: Kamesh Kaul/HSS)
> >
> > Subject:  RE: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2
> >
> >
> >
> >
> > Kamesh,
> >
> > As far as I understand, you propose that each SCON from ASP
> > generates a TFC.
> > In such a case, if only one of the n ASPs serving the same AS gets
> > congested, TFC will be generated, not nice IMO. Even for one
> > ASP case, when
> > TFC is generated based on SCON, the remote SP in SS7 domain 
> will stop
> > sending messages and will send RCT. So, there will be no 
> DATA to audit
> > status of ASP.
> > Also, IMO it is important not to forget about the
> > relationship between ASP
> > and SG, i.e. that it is similar to relationship between MTP3
> > and MTP3 user.
> >
> >      Tolga
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Friday, November 08, 2002 8:55 AM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2
> > >
> > >
> > >
> > >
> > > Hi
> > >      What i want to say is that  SCON from ASP is send to SG when
> > >                  it receives data message in congested state.
> > > That means
> > >                  when congestion abets at ASP, ASP will not
> > > respond with SCON
> > > message.
> > >                  So SG should have some SPMC congestion
> > > provisioning mechanism.
> > >                  So I was suggesting to have a timer per SPMC
> > > to provision
> > > congestion at SG side.
> > >                   When SCON is received at SG timer starts
> > > and if timer expires
> > > without
> > >                    receiving SCON SPMC can decrement its
> > > congestion level
> > > similar to
> > >                    RCT mechanism in Q.704 .
> > > Regards
> > > Kamesh
> > >
> > >
> > >
> > >
> > >
> > >
> > > Tolga Asveren <[email-masked]> on 11/08/2002 07:12:33 PM
> > >
> > > To:   "[email-masked]'" <[email-masked]>
> > > cc:    (bcc: Kamesh Kaul/HSS)
> > >
> > > Subject:  RE: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2
> > >
> > >
> > >
> > >
> > > Kamesh,
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]
> > > > Sent: Friday, November 08, 2002 8:19 AM
> > > > To: Tolga Asveren
> > > > Cc: [email-masked]
> > > > Subject: RE: [Sigtran] Sigtran Plugtest 
> SUA/M3UA/M2UA/IUA - Day 2
> > > >
> > > >
> > > >
> > > >
> > > > Hi
> > > >      Tolga this is fine if SPMC congestion status is updated by
> > > >                  SCONS coming from ASP's serving SPMC TFC
> > > will be send
> > > >                  to the conerned PC. We can have a congestion
> > > > timer per SPMC
> > > >                  which will be triggered when ever SPMC
> > > > congestion status is
> > > >                  updated.When the timer expires we can
> > > > decrement the congestion
> > > >                  level of SPMC. This seems similar to RCT
> > > > procedure. Here in
> > > > this
> > > >                  case RCT messages is nothing but MSU's
> > > received from
> > > >                  the SS7 domain.
> > > [TOLGA] I failed understant what you mean exactly (maybe an
> > > example might
> > > make it more clear for me). IMO, if ASPs update SG about
> > > congestion status
> > > changes, whenever it happens, there is no need for a timer on
> > > SG to decide
> > > for the SPMC congestion level.
> > > > Regards
> > > > Kamesh
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Tolga Asveren <[email-masked]> on 11/08/2002 06:40:54 PM
> > > >
> > > > To:   "[email-masked]'" <[email-masked]>
> > > > cc:    (bcc: Kamesh Kaul/HSS)
> > > >
> > > > Subject:  RE: [Sigtran] Sigtran Plugtest 
> SUA/M3UA/M2UA/IUA - Day 2
> > > >
> > > >
> > > >
> > > >
> > > > Brian,
> > > >
> > > > I think it will be more clear (at least for me) to discuss
> > > > this based on a
> > > > configuration:
> > > >
> > > >  AS1:1-1-1    AS1:1-1-1  AS1:1-1-1
> > > >     +-----+   +-----+    +-----+
> > > >     |ASP1 |   |ASP2 |    |ASP3 |
> > > >     |     |   |     |    |     |
> > > >     +--+--+   +--+--+    +--+--+
> > > >        |         |          |
> > > >        |         |          |
> > > >        |         |          |
> > > >        |         |          |
> > > >        |         |          |
> > > >        |      +--+--+       |
> > > >        |      | SG1 |       |
> > > >        +------+     +-------+
> > > >               +--+--+
> > > >                  |
> > > >                --+---
> > > >             ///      \\\
> > > >            |            |
> > > >           |   SS7        |
> > > >           |   network    |
> > > >            |            |
> > > >             \\\\    ////
> > > >                 ----
> > > >
> > > > SG1 is loadsharing between ASPs based on SLS. Let's
> > consider ASP2 is
> > > > congested. Then what will happen with messages arriving from
> > > > SS7 network:
> > > >
> > > > *Based on current SCON mechanism according to RFC3332:
> > > > Messages sent to ASP1/ASP3 will be processed. ASP2 will drop the
> > > > message(based on the congestion level if applicable) and
> > > > willr eply with
> > > > SCON. It also will fill Concerned Destination field with the
> > > > OPC of the
> > > > incoming message. Now what will SG do? Generate TFC based on
> > > > that SCON, or
> > > > nothing at all?If it sends TFC, how can it reply to a
> > > > possible future RCT
> > > > coming from SS7 network, because in this model ASPs don't
> > update SG,
> > > > whenever congestion level changes, they only can generate
> > > > SCON as reply to
> > > > an incoming message.
> > > >
> > > > *How it should work IMO:
> > > > a)Whenever ASP gets congested for an AS, it informs SG, so
> > > > can have the
> > > > combined congestion view for SPMC. Whenever traffic to a
> > > > particular ASP is
> > > > switched on or off based on congestion level for a
> > > particular priority
> > > > level, SG executes necessary procuderes to prevent 
> missequencing.
> > > >
> > > > b)(If all of this routing based on congestion level/message
> > > > priority is too
> > > > complex and we don't see too much added value)Whenever ASP is
> > > > congested for
> > > > an AS, in sends ASPIA to SG. SG can decide, when SPMC is
> > > > congested based on
> > > > the number of ACTIVE ASPs.
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > >
> > > >
> > > >
> > > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > >
> > >
> > >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> >
> >
> >
> _______________________________________________
> 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: Fri, 8 Nov 2002 16:12:14 -0700

Tolga,

Tolga Asveren wrote:                                  (Fri, 08 Nov 2002 10:20:37)
> a) You put the SPMC to congested status even when only one ASP is congested.

This would actually be good thing.

> there you rely only on a timer.

No, then ASP would indicates abatement with SCON.

> For both of those reasons (especially a) ) I disagree with that method.

Actually, because indicating congestion early is a good thing (a)
and the ASP will indicate abatement (b) so that the SG can respond
correctly to signalling route set congestion test messages, Kamesh's
approach works.  However, it is not necessarily the only or the
best approach.  That is why it is implementation dependent in the
RFC.

--brian

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

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 8 Nov 2002 16:37:43 -0800 (PST)

Brian,
--- "Brian F. G. Bidulock" <[email-masked]>
> This would actually be good thing.
[TOLGA] I don't think so, I would prefer stop routing
to congested ASP and continue to route to uncongested
ones, i.e. to make it similar to decide for the
availability/unavailability of SPMC.
> No, then ASP would indicates abatement with SCON.
[TOLGA] I was planning to disagree but then looked
again to RFC3332 carefully. There it says
"The SCON message MAY also be sent from the M3UA layer
of an ASP to an M3UA peer indicating that the M3UA
layer or the ASP is congested." 
I don't know whether this might be interpreted as that
ASP sends SCON whenever congestion ends. Also
explanation for ConcernedPC parameter hints that SCON
from ASP is sent only as reply to an incoming message.
If both of those text are polished to reflect that
SCON from ASP to SGP can be sent to indicate change of
congestion level, it is fine for me (although I
believe to use SSNM to inform about status of an AS
served by an ASP is not elegant)
> Actually, because indicating congestion early is a
[TOLGA]IMO, indicating congestion is only good, when
it really happens and personally I wouldn't consider
the case where only one of the n ASPs is congested a
good case for declaring SPMC congested.
> best approach.  That is why it is implementation

__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 8 Nov 2002 18:58:02 -0700

Tolga,

Tolga Asveren wrote:                     (Fri, 08 Nov 2002 16:37:43)
> availability/unavailability of SPMC.

And so it is implementation dependent.  Kamesh's approach
is valid, however.  An approach which does not signal
congestion to the sender when congestion onset occurs
risks message loss due to congestion discard.  In the
example, if TFC is not sent when one ASP in a loadshare
AS congests, the sender will continue sending messages
at the congestion priority and the ASP will eventually
start discarding (or risk excessive message delays).
This is why it is a good thing.

> served by an ASP is not elegant)

But is there to support ANSI T1.111.4.

> good case for declaring SPMC congested.

It is a good thing in SS7.  When a single message
encounters congestion on a single link in a link set,
regardless of the congestion status of other signalling
links in the link set, TFC is sent.  Kamesh's approach
is completely consistent with this.  The main point in
SS7 congestion is that messages at a certain priority
will be discarded, and indicating congestion at the
onset of congestion will allow the sender to stop sending
such message before congestion discard threshold is
reached.  The fact that one AS/ASP is at congestion onset
is sufficient to begin congestion procedures.  Kamesh's
approach is very valid in this respect and is well in
fitting with the principles of SS7 network management
and congestion procedures in ANSI T1.111.4.

-brian

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 8 Nov 2002 18:37:48 -0800 (PST)

Brian,
wrote:
> > > Tolga Asveren wrote:                            
> > >  (Fri, 08 Nov 2002 10:20:37)
> > > > Kamesh,
> > > > 
> > > > a) You put the SPMC to congested status even
> when
> > > only one ASP is congested.
> > > 
[TOLGA] If SG does not route to the congested ASP and
follows procedures to prevent missequencing , I don't
see a problem. What I am saying is not, not to send
SCON from congested ASP to SG at all, but to send
congestion indication from ASP to SG whenever it
happens, and based on that SG updates SPMC congestion
state and replies with TFC to incoming messages if
necessary, similar what we do with
availability/unavailability.
> 
> > > 
> > > > 
> > > > b) After receiving TFC the peer in SS7 domain
> will
> > > stop sending messages and
> > > > will send RCT. So, there won't be any DATA to
> be
> > > pumped from SG to ASP,
[TOLGA] But also it is intended to be sent only as
reply to an incoming message. IMO, this is not enough.
> > > Actually, because indicating congestion early is
> a
> > > good thing (a)
> is completely consistent with this.  The main point
[TOLGA] We are not speaking of links here. Here the
relationship we have is a MTP3/MTP3 user part
relationship and if I have my user part distributed, I
don't think it is a clever idea to see it as
congested, when only one piece of it is congested.
> in
[TOLGA]But in fact it does not need to fit, because we
don't have a MTP3-to-MTP3 relationship. If I apply
this procedure to the example I gave, IMO the result
is not very good, SPMC is deeclared congested when one
ASP replies with SCON to an incoming message, and also
as I pointed before my understanding from the text in
RFC3332 is, SCON is sent only as response to a message
from ASP to SG, so I don't see how ASP can send it
when congestion ends, if SG does not send DATA to it.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 8 Nov 2002 22:09:43 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Fri, 08 Nov 2002 18:37:48)
> availability/unavailability.

In the RFC, the ASP is sending both state changes and
in response to messages.  This is better than just in
response to state changes as it permits the SG more
information.  There is no need to limit it to just
state changes only.

> congested, when only one piece of it is congested.

It is foolish to treat the whole user part as uncongested
when any part of it is congested.  This is particularly
true for loadshare arrangements because transferring
load will just lead to congestion of another partition
and eventual congestive failure of the entire system.

> when congestion ends, if SG does not send DATA to it. 

Yes it needs to fit because it is an SS7 SNMM management
procedure: something that must interwork with the SS7
domain.  The result is in fact both sufficient and
necessary.  Kamesh's approach even includes a timer
should the ASP fail to indicate abatement with SCON which
is brilliant, because it even accomodates ASPs which fail
to signal abatement.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 9 Nov 2002 10:05:22 -0800 (PST)

Brian,
> information.  There is no need to limit it to just
[TOLGA] The RFC does not indicate that SCON is sent
when congestion ends. This is necessary in any case.
> and eventual congestive failure of the entire
[TOLGA] If you think that ASPs can serve different
sets of AS (with some of them overlapping), I wouldn't
agree with your this conclusion , i.e. I don't find it
foolish to not declare the whole SPMC congested
because only one of the n ASPs is congested, just I
wouldn't route traffic to it.
> domain.  The result is in fact both sufficient
and[TOLGA] No, it does not need to fit. What needs to
fit to MTP3 specs is the behavior of SG to the SS7
domain nodes. That currently SCON is used from ASP to
SG is just because of the fact it is thought as a
reply to an incoming message mechanism. I would think,
this should happen with ASPTM. ASPTM is used for
status of the SPMC memebers, SSNM is used for remote
peers. 
> is brilliant, because it even accomodates ASPs which
[TOLGA]What you advocate contradicts with what you
defend on other issues. If you think that congestion
management between ASP and SG should fit to MTP3
specs, then you should also advocate to have a
counterpart for RCT between ASP and SG. In fact source
of the problem is clear, trying to handle both
backhaul and non-backhaul scenarios with the same
mechanism -which IMO creates also some other
problems-.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 9 Nov 2002 15:29:50 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sat, 09 Nov 2002 10:05:22)
> when congestion ends. This is necessary in any case.

No, it's not necessary.  Kamesh's approach uses a timer
to determine abatement.

> wouldn't route traffic to it.

What else can you do with the traffic?

> counterpart for RCT between ASP and SG.

No, because there is no RCT between MTP and MTP-User.

> In fact source

Non-backhaul scenarios are optional.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sun, 10 Nov 2002 08:42:54 -0800 (PST)

Brian,
> No, it's not necessary.  Kamesh's approach uses a
[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.
> What else can you do with the traffic?
[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.
> No, because there is no RCT between MTP and
[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.
> 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.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 10 Nov 2002 13:30:47 -0700

Tolga,

Tolga Asveren wrote:                                  (Sun, 10 Nov 2002 08:42:54)
> 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.

> with only one congested ASP-, traffic should be routed

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?

> I mean with contradiction.

There is no contradiction.  It was intentional to stretch
the relationship to provide for the multiple SG case.

> supported, but in a proper way, which IMO is SG-SG

They are supported but not required.

--brian