Subject: [Sigtran] SIGTRAN Plugtest Day 2

From: "Barry Nagelberg" <[email-masked]>
Date: Wed, 18 Apr 2007 10:18:13 +0400

Greetings from Moscow! Here is the wrap-up report for Day 2 of the SIGTRAN
Plugtest.

Protocols tested:
M2PA - 6 implementations
M3UA - 6 implementations
SUA  - 5 implementations

There was one issue raised at the Day 2 wrap-up:

For M2PA proving, a suggestion was made that the M2PA RFC should contain a
standard criteria for evaluating the health of an M2PA link based on the
results of the proving.

This issue actually came up in a fielded implementation, not at the
plugtest. A customer using M2PA links reported that there were problems in
their network. After extensive and time-consuming trouble-shooting, it was
determined that one of the M2PA links was using a problematic IP connection,
which was causing a lot of SCTP re-transmissions.

A post-mortem of the entire affair indicated that a lot of time and trouble
could have been saved if the user had been informed immediately, i.e. at the
time that the link was brought up, that there were problems at the SCTP
layer.

The issue with the M2PA RFC is that it delegates, to the relevant MTP2
specs, the details of evaluating the health of the link, such as error rate
monitoring. Section 4 (Procedures) states that:

<snip>
   Except as modified in this document, M2PA SHOULD follow the
   requirements of the applicable MTP2 specification.  These may include
   [Q.703] or [T1.111].  The same standard MUST be followed on both ends
   of the M2PA link.
<snip>

However the MTP2 error rate monitoring details aren't readily transferable
to SCTP. So the suggestion is being made that it would be helpful if the
M2PA RFC itself would specify a standard criteria for evaluating the health
of an M2PA link based on the results of the proving. Such criteria would
probably be based on the SCTP retransmission rate.

The consensus of the group here is that this is a good idea.

Barry Nagelberg

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 18 Apr 2007 11:33:11 -0600

Barry,

Signal Unit Error Rate Monitoring (SUERM) or Errored Interval Monitor (EIM)
equivalents for M2PA do not require any protocol element exchanges between
peers, are completely a local matter (involve only the local endpoint) and are
SCTP implementation specific (whether the SCTP supports the gathering of
retransmission information or events, or not, and how).

Aside from saying that a SUERM/EIM eqivalent should be implemented, and
perhaps illustrating one possible way of implementing it (and clearly
indicating that is neither the best nor the only way) what can be done?

In the case cited were T7 excessive delay of acknowledgement timers correctly
implemented at both ends and set to an apporpriate value?  I would find it
surprising if excessive SCTP retransmissions could cause upper level
application problems (presumably delay related) without triggering T7.

Perhaps there are other issues. (E.g. an SCTP implementation that cannot
changeover between primary and secondary addresses quick enough causing the
operator to set T7 too large.)  Could the person mentioning the issue provide
more detail at a later date?

--brian

Barry Nagelberg wrote:                           (Wed, 18 Apr 2007 10:18:13)

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