Subject: RE: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2

From: Tolga Asveren <[email-masked]>
Date: Wed, 13 Nov 2002 18:18:56 -0500

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, November 13, 2002 5:08 PM
> To: Tolga Asveren
> Cc: [email-masked]'
> Subject: Re: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2
> 
> 
> Tolga,
> 
> Tolga Asveren wrote:                             (Wed, 13 Nov 
> 2002 16:33:43)
> 
> > [TOLGA] I agree it is practically usefull only for ANSI 
> case, but why only
> > for multiple SG case? I would think, for ANSI single SG 
> case it is also
> > usefull.
> 
> I explained that back at the beginning of the thread, but 
> here it is again:
> ANSI only permits nodal TFC to be send with the SMH 
> (Signalling Message
> Handling) function congests.  Only in the multiple SG case 
> can the ASP be
> viewed to handle any SMH functions whatsoever (and Al Varney 
> tells me offline
> that the intention was the discrimination function and not 
> the distribution
> function).  So, even in the multiple SG case it is a stretch 
> to say that the
> ASP performs any function which can congest and be used to 
> trigger nodal TFC.
> Nevertheless, some implementations were considering 
> reapplying the routing key
> at the ASP (some cases of NA only routing and default routing) so the
> discrimination function could, I suppose, be duplicated in 
> the ASP and in
> these corner cases SCON might need to be sent (again it is 
> OPTIONAL in ANSI).
> The thought that an ASP could have a congestible message 
> discrimination
> function while connected to, say, a 100Mb interface is rather 
> ludicrous
> considering modern day equipment, but I suppose someone could 
> underengineer
> an ASP so badly.
[TOLGA]So, you say in case of single SG configuration, M3UA congestion at
ASP is not considered as signalling point congestion, because ASP does not
need to perform any MTP3 fucntionality. Fair enough. But I would say in
multiple SG case it is routing function of MTP3, which ASP performs. BTW,
IMO trying to support backhaul/non-backhaul/singleSG/multipleSG cases all
with the same model gets more and more ugly. 
> 
> > > for it.  The SG can determine congestion of SMH functions 
> in any case by
> > > monitoring SCTP congestion.  Rather than expand the section, 
> > [TOLGA] For that I disagree, because there is no 1:1 
> relationship between AS
> > and SCTP association. IMO, waiting till the congestion 
> propogates through
> > SCTP will just delay things.
> 
> Not really.  Each AS can have its own stream.  The SG can 
> determine congestion
> onset based on buffer occupancy and use the same statistical 
> methods used by
> TFC in SS7 (trigger TFC on the message that begins onset).  
> The ASP could fail
> to service one stream without affecting the other as long as onset is
> determined before full congestion.  PR-SCTP is another option.
[TOLGA] Because stream selection based on AS is not mandatory, personally I
still wouldn't prefer relying on SCTP congestion.
 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 13 Nov 2002 17:11:05 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 13 Nov 2002 18:18:56)
> multiple SG case it is routing function of MTP3, which ASP performs.

Well, it was Al's point that the only routing function the ASP performs
is routing from ASP to SG, for which nodal TFC was not intended.  It is
only really the discrimination (incoming to the ASP) function which applies.
For incoming messages, the ASP has no MTP3 functionality, it is above the
MTP/MTP-User line in the backhaul scenario.  Therefore, in the backhaul case
there should be no need for SCON unless special arrangement requires it.
One case that might apply is for multiple SG where routing is done on NA only,
or whole point code.  But this case is closer to IPSP than ASP/SG, even though
the elements are still called ASP/SG.  For this corner case, the SCON should
remain, but it should probably be left to advocates of that corner case (i.e,
the NA school) to express their preferences.

> BTW, IMO trying to support backhaul/non-backhaul/singleSG/multipleSG cases
> all with the same model gets more and more ugly. 

Yes, but without the deviations, multiple SG would not be supported.
Consideration was given that installing M3UA at an STP pair could be
not only a desirable thing, but a commonplace thing in quasi-associated
networks, and support was necessary.  I often said that properly addressing
the configuration would require an M3PA protocol of which SG-SG is 
probably not so different, but the RFC had to be bitten off at some point.

> still wouldn't prefer relying on SCTP congestion.

Well, no, it is not an interoperability matter.  It is the SG which selects
the outgoing stream to the AS and the SG which wants to monitor backlog on
the stream.  If the SG wishes to monitor in this fashion, it would need to
select indepdent outgoing streams, but that is solely at the control of the SG
and need not be known to the ASP.

Also, the SG doesn't really need to address streams at all, just have separate
queues to SCTP for each AS, and monitor the depth of the backlog on each
queue.  This is possible entirely within M3UA at the SG without any SCTP or
ASP involvement.

--brian

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