Subject: RE: [Sigtran] Re: M3UA Congestion Procedures

From: "Wung, Joseph" <[email-masked]>
Date: Thu, 27 Mar 2003 18:12:41 -0500

Brian,

> > 
> > Is not the M3UA used between MTP and MTP-users even in the 
> case where 
> > the ASP is connected to multiple SGs acting as STPs?  If 
> SCON can't be 
> > sent from ASP to SGP due to the buffer congestion between 
> SGP (i.e.,MTP) 
> > and ASP (i.e., MTP-user), can you tell me under what condition the
> > ASP is supposed to send SCON?
> 
> Q.704/11.2.6 doesn't say anything about direction.  It says 
> that an SP can
> generate TFC in response to congestion at the signalling 
> point.  When the
> ASP is acting as an SP connected to mutliple SGs acting as 
> STPs, then the
> ASP might need to be able to generate the equivalent of a TFC 
> message (i.e,
> SCON) due to its implementation of Q.704/11.2.6.  After all, 
> the RFC does
> way "MAY".
> 

You did not answer my question explicitly.  Can you give me
an example of the implementation in which the ASP would send
SCON for a reason other than the congestion of the read/write
buffer used between the ASP and SGP?

Joe

> --brian
> > Thanks,
> > Joe
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 27 Mar 2003 16:26:10 -0700

Wung,,

Wung, Joseph wrote:                                                                  (Thu, 27 Mar 2003 18:12:41)
> buffer used between the ASP and SGP?

Yes; internal buffer capacity or other resource limitations
at the ASP.

Some existing MTP SP implementations use TFC as a last resort if
ISUP or SCCP congestion controls are not successful and resource
shortages persist.  This is permitted by Q.704/11.2.6, which does
not state what constitutes SP congestion.  ANSI-T1.111.4-2000 goes
further to state that only congestion of the SMH function can be
used to launch such a TFC (and that is not really receive congestion
in the SGP->ASP direction, but transmit congestion in the ASP->SGP
direction and is only really applicable to SPs with the transfer
function--which ASPs cannot have), but in any cast the procedure
is optional.

SCON from ASP to SGP is an optional mechanism that is there only
to accomodate this optionl use of nodal TFC.  The ASP "MAY" send
it.  The SGP is under no obligation to take any action with regard
to the SPMC in response to it, but, some SG designs might decide
under some circumstances to lauch a TFC in accordance with the
requirements of the SS7 network to which they attach.

So, if you don't understand or agree with how nodal TFC is used
in the SS7 network, you might be well advised to not send it from
the ASP, and not respond to it at the SGP.  It is OPTIONAL.  It
was included for completeness.

--brian

---

From: kamesh kaul <[email-masked]>
Date: Fri, 28 Mar 2003 20:24:16 -0800 (PST)

Brian,

See my comments inline 
Regards
Kamesh
--- "Brian F. G. Bidulock" <[email-masked]>
wrote:
> Wung, Joseph wrote:                                 
>                                 (Thu, 27 Mar 2003
> 18:12:41)
[Kamesh]Here as you are saying that ASP can send SCON
due to internal buffer capacity limitation why cant
same argument be used from SGP to ASP side.It can be
made optional to send SCON from SGP due to internal
buffer capacity at SGP.For flexability purposes
sending SCON from SGP to ASP due to receive buffer
limitation can be made optional even though i agree
that if the flow control mechanism at SCTP level is
efficent receive buffer occupancy can immidately lead
to increase in transmit buffer occupancy at ASP side. 

> was included for completeness.

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran