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

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

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