Subject: M3UA v9 : SCON message handling

From: Richard Adams <[email-masked]>
Date: Mon, 22 Oct 2001 10:55:03 +0100

Dear all,
some comments from a standby worker in redundant mode -
The suggested sentence "....However, an SCON message is not required to be
delayed to collect individual congested destinations into a single SCON "
seems far too weak to me.
It also puts the stress in the wrong place - I prefer "....It is required
not to delay the SCON in order to collect individual congested destinations
into the report", or some such.

In the UK we recently did a number of studies into node overload, the
control of which is similar to that for MTP congestion. There we saw that
the stability of control depended critically upon the speed at which the
users react when a node becomes congested.

I agree that it is a network implementation matter as to how much delay is
acceptable in reporting congestion from M3UA to its users, and consequently
the use of the term "MUST NOT" is not appropriate. But the Q.764 procedures
on receipt of an MTP-STATUS (congested) depend upon a prompt indication from
the MTP. ISUP typically starts a 5 second timer to control throttling its
messages/new calls to or through the affected destination, the congestion
level is set according to the number of status indications received within
successive timing intervals. And for ISUPs relying upon ITU-T - like MTPs
there is no aggregation of congested destinations. SCCP flow control was
based on the ISUP scheme, with its timers set accordingly.

Brian's statement that the actual delay for reporting congestion is not
specified is not complete - the acceptable TFC or MTP-STATUS delay is
actually linked to the time that a signalling link can persist in congestion
without being taken OOS, this is governed by the T6 MTP level 2 timer. But
Q.706 chickened out of specifying anything for performance under adverse
conditions (section 6 is just for further study!).

I would say that a delay of the order of seconds would be far too high to
enable effective control. I guess there has to be a balance in networks
where aggregation of destinations is done between the time taken to
aggregate against the time taken to send and react on individual reports.
So, please can we rearrange the part about "not required" as I suggest, plus
I would like to see an implementation note as well!

Kind regards,
Richard A. Adams,
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 22 Oct 2001 04:50:58 -0500

Richard,

Did you realize that once sent to the ASP, it might take 120 seconds
for it to reach the ASP?  (Any message for that matter.)  SCTP could
retransmit and back off quite a few times before delivering or telling
the UA that anything was wrong.  There are no life-time values
on SCTP messages specified for M3UA.

You are welcome to require a vendor to meet whatever performance
requirements you see fit; however, it has no place in the M3UA RFC
as they have been explicitly placed out of scope.

The sentence should be struck altogether.

--brian

Richard Adams wrote:                                      (Mon, 22 Oct 2001 10:55:03)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Mon, 22 Oct 2001 13:24:46 +0200

Dear all,

There is the SCTP Applicability Statement for Signalling Transport, which
(should) put far more stringent timer and max.retransmission values than
suggested for a "default" SCTP. Clearly, if it takes minutes for a message
to reach the ASP (suppose an ISUP call setup message !!), there's something
completely wrong in the SCTP's settings.

Lacking hands-on experience, I suggest something along the lines "whether it
is appropriate or not for an M3UA implementation to collect individual
congested destinations into a single SCON message is f.f.s. (or AS or BCP)".
At least there's nothing wrong with being able to receive such a message. We
can fine-tune the sender in a BCP later on (we never know it might be useful
if we receive bursts of TFC messages for one reason or another).

Regards,

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: maandag 22 oktober 2001 11:51
To: sigtran
Cc: [email-masked]; gregside; karen.d.king
Subject: Re: M3UA v9 : SCON message handling

Richard,

--brian

Richard Adams wrote:                                      (Mon, 22 Oct 2001
10:55:03)
> To unsubscribe send a blank email to
[email-masked]

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

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: [email-masked]
Date: Tue, 30 Oct 2001 09:43:40 -0000

Greg, 

In a previous email on this subject, you mentioned you couldn't recall the
original reason for including the sentence as it was in the specification.

I've contacted Gerhard Rufa (who originally requested this sentence to be
included) for his comments and to outline his original thoughts on this.
He's asked me to pass on the following,

***

Brian and Greg,

I followed your recent discussions on the sentence ''However, an SCON
message MUST not be delayed to collect individual congested destinations
into a single SCON message as any delay might affect the timing of
congestion indications to the M3UA Users.'' 

Greg, you said ''maybe Richard Adams remembers the discussion with BT''. In
fact, it was me making specific proposals at the BT meeting regarding the
M3UA specification. 

Especially, I tried to express my concerns with the sentence ''The Affected
Destination parameter can be used to indicate congestion of multiple
destinations or ranges of destinations.'' (see section 3.4.4 SS 7 Network
Congestion). I have nothing against using the Affected Destination parameter
in the SCON message to indicate that an ANSI cluster gets congested when a
related route set gets congested and I think this is what you intended to
express with this sentence. However, I felt that this sentence could be
misleading and implementers might think that they are allowed to collect
received TFC messages related to congested DPCs in the SS 7 network into a
single SCON message at the signalling gateway (SG), which is in conflict
with the SS 7 philosophy, as specified in ITU, ANSI and ETSI, and must not
be performed. 

Greg, in order to reflect my concerns, you then introduced the sentence
above which in principle covers my concerns, so I could live with it. Now
Brian said that ''it is the MUST that I object to....MUST is an RFC keyword
which has to do with interoperability requirements.'' 

In order to help with the discussion I would like to make the following new
proposal to cover my concerns and the ones from Brian:

Replace the complete paragraph in section 3.4.4: SS 7 Network Congestion

'' The Affected Destination parameter can be used to indicate congestion of
multiple destinations or ranges of destinations. However, an SCON message
MUST not be delayed to collect individual congested destinations into a
single SCON message as any delay might affect the timing of congestion
indications to the M3UA Users. One use for including a range of congested
DPCs is when the SG supports an ANSI cluster route set to the SS 7 network
that becomes congested due to outgoing link set congestion.''

By the following paragraph:

''The Affected Destination parameter can be used in case of a route set
congestion to indicate the congestion of a cluster or range of destinations
that are reached via that congested route set, e.g. when an ANSI cluster
route set to the SS 7 network becomes congested due to outgoing link set
congestion.''

I hope that my comments are of help!

Regards,

Gerhard

Dr. Gerhard Rufa
Professor of Physics and Mathematics
University of Applied Sciences Mannheim

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: 22 October 2001 10:51
To: sigtran
Cc: [email-masked]; gregside; karen.d.king
Subject: Re: M3UA v9 : SCON message handling

Richard,

--brian

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

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 30 Oct 2001 04:13:17 -0600

Gerhard,

[email-masked] wrote:                           (Tue, 30 Oct 2001 09:43:40)

> route set to the SS 7 network becomes congested due to outgoing link set

This text is acceptable, however, I would remove references to link sets
and route sets which are not well defined in M3UA, and also imply functions
that are the responsibility of the NIF, as follows:

> ''The Affected Destination parameter can be used -- ---- -- - ----- ---
> ---------- to indicate the congestion of a cluster or range of destinations
> ---- --- ------- --- ---- --------- ----- ---, e.g. when an ANSI cluster
> ----- --- -- --- -- - ------- becomes congested --- -- -------- ---- ---
> ----------.''

or,

    The Affected Destination parameter can be used to indicate
    the congestion of a cluster or range of destinations, e.g.
    when an ANSI cluster becomes congested.

But, geee!  Now it looks like the definition of the parameter.  Yet
the definition of the mask field says:

    The Mask field can be used to identify a contiguous range of
    Affected Destination Point Codes, independent of the point
    code format.  Identifying a contiguous range of Affected DPCs
    may be useful when reception of an MTP3 management message or
    a linkset event simultaneously affects the availability status
    of a series of destinations at an SG.

So it seems that the existing definition of the Affected DPC mask
field and this proposed replacement text are the same.  There is no
need to say it twice.

Please strike the original sentence.

--brian

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

---