Subject: RE: [Sigtran] Recommendation for SUA modifications

From: "Haresign Lincoln" <[email-masked]>
Date: Fri, 14 Oct 2005 11:25:18 -0400

Brian,

The ASP congestion that I am referring to is the same congestion we have
spoken about all along.  The SUA layer is detecting congestion.  I don't
think I can specify this any clearer due to the fact that congestion
detection is typically an implementation dependent feature.

The bottom line is that ASP is congested at a layer above SCTP.  What
type of text are you looking for?  Actually, I think the text in the
existing RFC is fine:

   The SUA layer at an ASP or IPSP MAY indicate local congestion to an
   SUA peer with an SCON message.

Of course if the WG decide to go with a new message, we can change it to
whatever the new message is.

Regards,
Lincoln

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brian F. G. Bidulock
Sent: Friday, October 14, 2005 10:08 AM
To: Haresign Lincoln
Cc: [email-masked]; [email-masked]; Valerie Gastaud;
[email-masked]
Subject: Re: [Sigtran] Recommendation for SUA modifications

Haresign,

Haresign Lincoln wrote:
(Fri, 14 Oct 2005 09:54:17)
> Brian,
> 
> Personally, I am not tied to SCON.  Initially I asked if SCON can by 
> used for ASP congestion and you seemed to imply that it could in our 
> first exchange.  I then tried to resolve the problems with the RFC.
> 
> If you want to use the ASP Status message, I have absolutely no 
> problem with this solution and would back it 100%.  We should indicate

> in the SUA IG that SCON can not be used for ASP->SG congestion as is 
> currently stated in the RFC.

No, it is correct in the RFC.  ASP->SG SCON is used for signalling ASP
congestion: just MTP and SCCP congestion at the ASP.  These new ASPTM
would be for some type of ASP congestion that has yet to be defined.

Also, the I-G is really a place for errata, not new (or
overloaded) sets of messages with completely new procedures and new
states and state transitions.  It deserves a separate draft.

What kind of ASP congestion are you talking about, and what is its
definition?

Perhaps you could contribute the text for the description of the ASP
Congestion parameter?

--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: Fri, 14 Oct 2005 09:49:29 -0600

Lincoln,

Well let's ferret this out: what event causes this non-SS7 congestion?
Is it too many messages crossing the SCTP/SUA boundary?  Too many messages
for what component to process?  The SCCP-User?

Or shall we just say that the ASP Status is used to indicate local congestion
at an ASP without defining it at all?

SS7 congestion is well defined, but that is its failing.  It needs things like
point codes.  This "local ASP congestion" is much broader, far more applicable
to IP networks.  I think we need to remove the Routing Context from the ASP Status
message.  "Local ASP congestion" knows no Routing Context.  It is the ASP in
general that is congested, locally.  Yes, I will remove Routing Context from the
message.  So, the ASP Status will have:

     ASP Congestion       Mandatory
     Info                 Optional

and the ASP Status Qry will have:

     Info                 Optional

Then the ASP need only respond with one ASP Status when the SG sends one ASP
Status Qry.  This is good.  Actually do we need the Info field?  I suppose we
could make the ASP Congestion field optional as well (when absent it would indicate
no congestion).

--brian

Haresign Lincoln wrote:                      (Fri, 14 Oct 2005 11:25:18)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 14 Oct 2005 11:41:25 -0400

Brian,

IMHO do not remove RC from the new ASPTM. An ASP may serve multiple AS and
depending on configuration/architecture/type of applications etc.. one of
them may get congested but not the other one, e.g. M3UA-ASP is running on a
blade and is active for AS1 and AS2, application logic for AS1 is running on
a second blade and application logic for AS2 on a third blade.

   Tolga

> From: [email-masked] [mailto:[email-masked]]On
> Sent: Friday, October 14, 2005 11:49 AM
> To: Haresign Lincoln

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 14 Oct 2005 10:07:49 -0600

Tolga,

It sounds like you have a definition in mind for this non-SS7 ASP congestion.

Lincoln prefers that it be broad and general "local ASP congestion", not specific
to any parameter or thing that might have to be provisioned at an ASP that would
otherwise not need to be.

I think, as Lincoln, we should first focus on the case where there is only one
point code, one ASP, one SG and one Routing Context.

--brian

Tolga Asveren wrote:                                                                  (Fri, 14 Oct 2005 11:41:25)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 14 Oct 2005 12:48:09 -0400

Brian,

My rational is as follows:
Congestion status of ASP is similar to ASP being ACTIVE/INACTIVE -which is
in the context of a specific AS-. It can be per AS -for certain cases ASP
can serve only a single AS but for the generic case it can serve multiple-.
This sounds reasonable to me but maybe I am missing something.

   Tolga

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, October 14, 2005 12:08 PM
> To: Tolga Asveren
> Cc: [email-masked]