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

From: Tolga Asveren <[email-masked]>
Date: Wed, 13 Nov 2002 16:33:43 -0500

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, November 13, 2002 4:14 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 14:40:44)
> > > 
> > > So you did.  You need to still allow responsive SCON so that
> > > approaches such as Kamesh's are still possible.  And the SHOULD
> > > must be a MAY (because it is optional and not required for
> > > interoperability).
> > [TOLGA] I think proposed sentence allows also this 
> approach. The goal is not
> > to prevent SCON as response to an incoming message but also 
> to allow it -or
> > to make it more clear that it is allowed- whenever ASP 
> decides that its
> > congestion level has changed.
> 
> Responsive is not just when the congestion level changes, but whenever
> a message encounters congestion regardless whether the 
> congestion level
> has changed or not.  Also, if SCON is sent to abatement, what goes in
> the "concerned PC" field (as there is no message to derive 
> the concerned
> point code from)?
[TOLGA] I would think no concernedPC field will be there for abatement case.
It just informs about the change of the congestion level for an AS.
> 
> > Furthermore I also think like in my initial proposal a section for
> > congestion mechanims between ASP and SG might be usefull. 
> Let's try to start
> > with the following: 
> > "Congestion Indication Procedures From ASP to SG
> > Congestion of M3UA layer on an ASP or ASP itself is 
> informed from ASP to SG
> > with a SCON message. This message MAY be generated when 
> congestion level
> > changes -for example because of a received message-. It is 
> responsibility of
> > SG, to change overall congestion level for SPMC, based on 
> SCON messages
> > received from ASPs and to follow relevant MTP3 procedures 
> based on the
> > updated congestion level. A SCON does not necessarily need 
> to be translated
> > to a corresponding TFC message. SCON message from ASP to SG 
> SHOULD be sent
> > per SG, i.e. only to one of the SGPs of the SG."
> 
> I thought all this was clear from the existing text.  Also, 
> there is no need
> for an ASP to generate this at all unless the protocol is 
> ANSI (nodal TFC is
> ignored and even a violation of other variants).  Again: 
> nodal SCON was just
> to handle the multiple SG case and only as an OPTION.  There 
> is no real need
[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.
> 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.
> IMO it would be
> better to let it drop out of existence (as an unimiplemented 
> option) at a 
> later stage.  It has already received more attention than it is worth.
[TOLGA] For me no problem, as long as everybody thinks it is clear from the
current text -but not just for us also for possible future newcomers-.
> --brian
> -- 
> 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: Wed, 13 Nov 2002 15:08:09 -0700

Tolga,

Tolga Asveren wrote:                             (Wed, 13 Nov 2002 16:33:43)

> for multiple SG case? I would think, for ANSI single SG case it is also

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.

> > for it.  The SG can determine congestion of SMH functions in any case by

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.

> > IMO it would be better to let it drop out of existence (as an
> > unimiplemented option) at a later stage.  It has already received more
> > attention than it is worth.

Its only a "Proposed Standard".  Significant implementation experience is yet
to come.  Besides, newcomers without an understanding of SS7 are lost anyway.
They will just have to ask questions.  Unfortunately there are no authors on
the document for them to ask.  Perhaps those responsible for the final
document should have put a note under contact information that because there
seem to be no authors for the document (just editors) that questions should be
directed at the editors (or perhaps the working group list).

--brian