Subject: RE: [Sigtran] Recommendation for SUA modifications

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

Brian,

I would recommend leaving the RC in.  Otherwise how would the SG
identify which ASP this is?

I would recommend leaving congestion as mandatory to make this similar
to the congestion level field in the SCON today.  Perhaps we can even
use the same tag value.

I would recommend an Info field as optional. 

With regards to ASP congestion, there can be two scenarios.  Either the
SUA layer itself is congested or congestion is detected in the direction
of the user (perhaps the queue depth of the application reaches a
specific size).  In any case, I would leave this very general as this is
very implementation dependent.

Regards,
Lincoln

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

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

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

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

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

---

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

Haresign,

Haresign Lincoln wrote:                                                            (Fri, 14 Oct 2005 11:55:36)
> identify which ASP this is?

Oh.  ASP Id.  We should put ASP Id in the message so that we can identify
the ASP.

> to the congestion level field in the SCON today.  Perhaps we can even

No, we will use a new tag value because it is a completely different
parameter.  The Congestion Level parameter only has those few congestion
levels (4 for MTP, 8 for SCCP) and we will probably need way more than
those.

> very implementation dependent.

Ok a queue to some user, or something within the SUA layer blocks up.  Is
there a way that we can identify the user in the ASP Status?  RC?  No, that
is too heavily tied to an SS7 routing key.  How about a new SUA User Index?

--brian

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