Re: SIGTRAN Plugtest Day 2

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)
> 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 protected]
> https://www1.ietf.org/mailman/listinfo/sigtran

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