Subject: [Sigtran] Comment on M2PA - Performance Monitoring

From: [email-masked]
Date: Fri, 28 Jun 2002 15:01:15 -0400

Folks,

According to Section 4.1.3 (Link Alignment) the is no performance
monitoring during the M2PA  proving procedure.  Also, according to Section
4.1.6 (Error Monitoring) there is no in-service performance monitoring of
the M2PA link.  It appears that the general concept is that the SCTP
association is either up or down from the M2PA perspective and it is the
responsibility of SCTP to remove an SCTP association with degraded
performance.

It is not clear that the necessary performance monitoring is actually being
done at the SCTP level.  Section 3.2.3 of the Telephony Signalling
Transport over SCTP Applicability  Statement, indicates that the
Path.Max.Retrans and Association.Max.Retrans SCTP parameters can be set to
lower values to speedup failure detection.  We don't think this would
necessarily be adequate for  the M2PA link application.  Given the
connectionless nature of the underlying IP paths, it is possible that  an
SCTP association might be performing inadequately in terms of its overall
retransmission rate  without exceeding the Path.Max.Retrans and
Association.Max.Retrans thresholds for any given message. Since setting
values too low for these parameters could result in false fault detection,
that approach may not be a solution.

We believer it is prudent to monitor the performance of the underlying SCTP
association somewhere so that a link with degraded performance can be
prevented from proving in or be  taken out of service and the traffic
diverted to other links using the changeover procedure.  Prior text from
draft 3 (since removed)  included an SRTT check on proving (retrievable via
the SCTP GETSRTTREPORT primitive), and made similar nonspecific statements
that proving and periodic  in-service performance monitoring  procedures
should check the SRTT, retransmission frequency, and gap acknowledgements
as measured at the SCTP layer against management-determined thresholds.  We
feel such text or similar procedures should be restored in Sections 4.1.3
and 4.1.6.

The latter 2 criteria were  problematic in that there are no SCTP
primitives that would allow M2PA to retrieve such SCTP statistics for
thresholding. However, we feel that the SRTT check should be specified as
an optional procedure at proving and during periodic in-service monitoring.
Also, we feel the protocol specification should identify the retransmission
frequency and gap acknowledgement frequency as useful performance criteria
for link  proving and in-service monitoring, even though these statistics
are not clearly defined in the SCTP specification and the M2PA/SCTP
interface cannot support their retrieval.  This would at least allow,  if
not encourage, implementation-specific solutions for use of the SCTP
retransmission and gap acknowledgement frequency criteria during proving
and in-service performance monitoring.

Regards
Ray

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