RE: Congestion in M3UA/SUA and the use of the SCON

Brian,

See below.

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Friday, October 07, 2005 6:44 AM
To: Haresign Lincoln
Cc: Tolga Asveren; [email protected]
Subject: Re: [Sigtran] Congestion in M3UA/SUA and the use of the SCON

Lincoln,

Haresign Lincoln wrote:                       (Thu, 06 Oct 2005
14:51:56)
> Brian,
> 
> OK, the SUA layer on the ASP detects congestion towards the 
> application layer.  It should generate a SCON. The SG should take 
> implementation specific actions.

The SUA layer at the ASP also has immediately at its disposal all the
addresses necessary to complete the mandatory address fields in the
SCON.

[lincoln]: It doesn't.  The SUA layer only knows source address which
may be a GT.

> 
> For example, in our case, we can optionally not direct new traffic to 
> a congested ASP.  This works quite well in a query/response type of 
> application.  I suppose we can make our SGs as intelligent as we want 
> and still operate within the norms of the RFC.

You might not be able to redirect traffic if TID labelling is in effect.
Also, unless you are running the entire transaction state machine at the
SG (which would defeat the point of backhauling to an ASP), you cannot
distinguish new from old traffic.  When redirecting anything, the
procedures of the CORID draft are applicable.

[lincoln]: In general, I agree with you.  In certain applications (e.g,
a query/response) you could easily redirect.  Or if you ASPs have the
ability to take over dialogs in the middle (as ours do), you could fail
over a dialog in the middle.

> No matter what, the SCON from the ASP is in the spec as a justified 
> procedure after years of getting the RFC through acceptance.  I don't 
> think we should remove it now because it doesn't apply to the way that

> some people are implementing their architectures.

Any optional behaviour not used by more than one implementation will be
dropped when the spec advances from Proposed Standard.  That is why we
don't really worry too much about optional behaviour at this point.  We
are far more interested in required behaviour necessary for
interoperability (also security and protection of the Internet).


--brian

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