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

From: Tolga Asveren <[email-masked]>
Date: Wed, 13 Nov 2002 14:40:44 -0500

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, November 13, 2002 2: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 13:27:01)
> > Brian,
> > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Wednesday, November 13, 2002 1:19 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 10:12:12)
> > > > 
> > > > (I am waiting comments also for other items of the proposal)
> > > 
> > > You did not propose any other text changes.
> > [TOLGA] Yes I did:
> > My proposal:
> > 1)3.4.4
> > Current:
> > "The SCON message MAY also be sent from the M3UA layer of 
> an ASP to an M3UA
> > peer indicating that the M3UA layer or the ASP is congested."
> > Proposal:
> > "The SCON message SHOULD be sent from the M3UA layer of an 
> ASP to an M3UA
> > peer indicating that the congestion level of the M3UA layer 
> or of the ASP
> > has changed."
> > Why?: So, SCON will be sent, whenever ASP gets congested, 
> because of an
> > incoming message to ASP or for any other reason(for example 
> because of a
> > message destined for another AS, served by the same ASP). 
> IMO, it is also
> > better to change MAY to SHOULD, so we update the SG, and it 
> is up to it how
> > to behave.
> > 
> > [TOLGA] The poprosal was not just to change MAY to SHOULD, 
> the sentence
> > itself is also modified.
> > 
> 
> 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.

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."
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

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

Tolga,

Tolga Asveren wrote:                                                               (Wed, 13 Nov 2002 14:40:44)
> 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)?

> 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
for it.  The SG can determine congestion of SMH functions in any case by
monitoring SCTP congestion.  Rather than expand the section, 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.

--brian

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