One document matched: draft-malas-performance-metrics-04.txt
Differences from draft-malas-performance-metrics-03.txt
SIPPING Working Group D. Malas
Internet Draft Level 3 Communications
Expires: February 2007 August 16, 2006
SIP End-to-End Performance Metrics
draft-malas-performance-metrics-04.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on February 16, 2007.
Abstract
This document defines a set of metrics and their usage to evaluate
the performance of end-to-end SIP-based services in both production
and testing environments. The purpose of this document is to combine
a set of common metrics, allowing interoperable performance
measurements, easing the comparison of industry implementations.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].
Malas Expires February 16, 2007 [Page 1]
Internet-Draft SIP End-to-End Performance Metrics August 2006
Table of Contents
1. Introduction...................................................2
2. Terminology....................................................3
3. SIP Performance Metrics........................................4
3.1. Registration Request Delay (RRD)..........................4
3.1.1. Successful REGISTER Completion RRD...................4
3.1.2. Failed REGISTER Attempt RRD..........................5
3.2. Session Request Delay (SRD)...............................6
3.2.1. Successful Session Setup SRD.........................6
3.2.2. Failed Session Setup SRD.............................7
3.3. Session Completion Delay (SCD)............................8
3.3.1. Successful session completion SCD....................9
3.3.2. Failed session completion SCD........................9
3.4. Average Hops per INVITE (AHI)............................10
3.5. Session Duration Time (SDT)..............................12
3.5.1. Successful session completion SDT...................12
3.5.2. Failed session completion SDT.......................13
3.6. Session Establishment Rate (SER).........................14
3.7. Session Defects (SD).....................................14
3.8. Ineffective Session Attempts (ISA).......................15
3.9. Session Disconnect Failures (SDF)........................15
3.10. Session Completion Rate (SCR)...........................16
3.11. Session Success Rate (SSR)..............................18
4. Metric Correlations...........................................18
5. Additional Considerations.....................................19
5.1. Back-to-back User Agent (B2BUA) Considerations...........19
5.2. Data Collection Considerations...........................19
5.3. Testing Documentation....................................19
6. Security Considerations.......................................19
7. IANA Considerations...........................................19
8. Conclusions...................................................20
9. Acknowledgments...............................................20
10. References...................................................20
10.1. Normative References....................................20
10.2. Informative References..................................21
Author's Addresses...............................................21
Intellectual Property Statement..................................21
Disclaimer of Validity...........................................21
Copyright Statement..............................................21
Acknowledgment...................................................22
1. Introduction
SIP has become a standard among many service providers, vendors, and
end users. Although there are many different standards for measuring
the performance of signaling protocols, none of these have been
adapted for use with SIP. This document is intended for providing a
Malas Expires February 16, 2007 [Page 2]
Internet-Draft SIP End-to-End Performance Metrics August 2006
guideline for the above listed entities in providing a standard
approach for measuring and reporting SIP performance metrics with an
end-to-end perspective. This will allow a common approach and
understanding of performance expectations between service providers,
vendors, and the users of those services based on SIP.
The metrics defined in this document DO NOT take into consideration
durations, impairments, or failures associated with the actual
application processing of a request or response. Metrics associated
with single device application processing are out of scope of this
document.
Some metric inputs in this document are affected by external
variables to SIP. The following list provides examples, but should
NOT be considered exhaustive:
. Network connectivity
. Switch and router performance
. Server processes and hardware performance
Note that some metrics in this document may not apply to all
applications of SIP. This document provides an overview of pertinent
metrics, which may be used individually or as a set based on the
usage of SIP within the context of a given service.
This document provides a common subset of metrics with a common
industry agreed upon definition. This document does not provide any
standard or benchmark value regarding IETF recommended performance
criteria to compare any output value derived from the following
described metrics.
2. Terminology
The following terms will be used throughout this document:
End-to-End - This is described as two or more elements utilized for
initiating a request, receiving the request, and responding to the
request. It encompasses elements as necessary to be involved in a
session dialog between the originating UAC, destination UAS, and any
interim proxies (may also include B2BUA's). This may be relative to a
single operator's set of elements or extend to encompass all elements
(if beyond a single operator's network) associated with a session.
Time Begin (TB) - This is the time stamp to begin determination of
the duration until the relative response is received. This begins
Malas Expires February 16, 2007 [Page 3]
Internet-Draft SIP End-to-End Performance Metrics August 2006
when the relative request has been processed by the application and
is being sent from the proxy or UA.
Time Stop (TS) - This is the time stamp to end determination of the
duration relative to the necessary response received by the initiator
of the request. This ends when the application recognizes the
response.
3. SIP Performance Metrics
The following metrics may be utilized for many different SIP
applications. In regards to all of the following metrics, message
re-transmissions must be excluded in order to provide accurate metric
results.
Some metrics are calculated based on the final response message.
These metrics do not take into consideration route advances to
additional signaling functions based on "final" failure responses.
In these unique cases, the final response related to the initial
setup attempt should be utilized for input to the metric.
3.1. Registration Request Delay (RRD)
Registration Request Delay is utilized to detect failures or
impairments causing delays in responding to a UAC REGISTER request.
RRD is measured for both successful and failed REGISTER requests.
This metric is measured from the originating UAC perspective as
relative to the end-to-end network under measurement. The output
value of this metric is numerical and should be adjusted to indicate
seconds and/or milliseconds. The following represents the
calculation for this metric:
RRD = Time of Final Response - Time of REGISTER Request
This metric is commonly calculated as an average. The following
represents the calculation for this metric as an average:
SUM (Time of Final Response - Time of REGISTER Request)
ARRD = -------------------------------------------------------
SUM # of REGISTER Requests
3.1.1. Successful REGISTER Completion RRD
In a successful registration attempt, RRD is defined as the time
interval from the moment the initial REGISTER message containing the
necessary information is passed by the originating UAC to the
intended registrar until the 200OK is received indicating the
registration attempt has completed successfully. This dialog
Malas Expires February 16, 2007 [Page 4]
Internet-Draft SIP End-to-End Performance Metrics August 2006
includes an expected authentication challenge prior to receiving the
200OK as describe in the following registration flow examples.
The following flow provides an example of identifiable events
necessary for inputs in calculating RRD during a successful
registration completion:
UA1 Registrar
| |
|REGISTER |
TB---->|--------------------->|
/\ | 401|
|| |<---------------------|
RRD |REGISTER |
|| |--------------------->|
\/ | 200|
TS---->|<---------------------|
| |
3.1.2. Failed REGISTER Attempt RRD
In a failed registration attempt, the interval is defined from the
initial REGISTER request and the final response indicating a failure
received from the destination registrar or interim proxies. A
failure response is described as a 4XX, 5XX, or possible 6XX message.
RRD may be used to detect problems in downstream signaling functions,
which may be impairing the REGISTER message from reaching the
intended registrar.
The following flow provides an example of identifiable events
necessary for inputs in calculating RRD during a failed registration
attempt:
UA1 Registrar
| |
|REGISTER |
TB---->|--------------------->|
/\ | 401|
|| |<---------------------|
RRD |REGISTER |
|| |--------------------->|
\/ | 401|
TS---->|<---------------------|
| |
Malas Expires February 16, 2007 [Page 5]
Internet-Draft SIP End-to-End Performance Metrics August 2006
3.2. Session Request Delay (SRD)
Session Request Delay is utilized to detect failures or impairments
causing delays in responding to a UA session request. SRD is
measured for both successful and failed session setup requests. This
metric is also known as Post Dial Delay (PDD) in telephony
applications of SIP. This metric is measured from the originating
UAC or proxy perspective as relative to the end-to-end network under
measurement. The output value of this metric is numerical and should
be adjusted to indicate seconds and/or milliseconds. The following
represents the calculation for this metric:
SRD = Time of Status Indicative Response - Time of INVITE
This metric is commonly calculated as an average. The following
represents the calculation for this metric as an average:
SUM (Time of Status Indicative Response - Time of INVITE)
ASRD = ---------------------------------------------------------
SUM # of INVITE Requests
3.2.1. Successful Session Setup SRD
In a successful request attempt, SRD is defined as the time interval
from the moment the INVITE message containing the necessary
information is passed by the originating agent or user to the
intended mediation or destination agent until the first provisional
response is received indicating an audible or visual status of the
initial session request. In SIP, the message indicating status would
be a non-100 Trying provisional message received in response to an
INVITE request. In some cases, a non-100 Trying provisional message
is not received, but rather a 200 message is received as the first
status message instead. In these situations, the 200 message would
be used to calculate the interval.
The following flow provides an example of identifiable events
necessary for inputs in calculating SRD during a successful session
setup without a redirect (i.e. 3XX message):
Malas Expires February 16, 2007 [Page 6]
Internet-Draft SIP End-to-End Performance Metrics August 2006
UA1 UA2
| |
|INVITE |
TB---->|--------------------->|
/\ | |
|| | |
SRD | |
|| | |
\/ | 180|
TS---->|<---------------------|
| |
The following flow provides an example of identifiable events
necessary for inputs in calculating SRD during a successful session
setup with a redirect (e.g. 302 Moved Temporarily):
UA1 Redirect Server UA2
| | |
|INVITE | |
TB---->|--------------------->| |
/\ | 302| |
|| |<---------------------| |
|| |ACK | |
SRD |--------------------->| |
|| |INVITE |
|| |------------------------------------------->|
\/ | 180|
TS---->|<-------------------------------------------|
3.2.2. Failed Session Setup SRD
In a failed request attempt, the interval is defined from the initial
session request and a non-100 Trying provisional message or a failure
indication response. A failure response is described as a 4XX, 5XX,
or possible 6XX message. SRD may be used to detect problems in
downstream signaling functions, which may be impairing the INVITE
message from reaching the intended UA.
The following flow provides an example of identifiable events
necessary for inputs in calculating SRD during a failed session setup
attempt without a redirect (i.e. 3XX message):
Malas Expires February 16, 2007 [Page 7]
Internet-Draft SIP End-to-End Performance Metrics August 2006
UA1 UA2
| |
|INVITE |
TB---->|--------------------->|
/\ | |
|| | |
SRD | |
|| | |
\/ | 480|
TS---->|<---------------------|
| |
The following flow provides an example of identifiable events
necessary for inputs in calculating SRD during a failed session setup
attempt with a redirect (e.g. 302 Moved Temporarily):
UA1 Redirect Server UA2
| | |
|INVITE | |
TB---->|--------------------->| |
/\ | 302| |
|| |<---------------------| |
|| |ACK | |
SRD |--------------------->| |
|| |INVITE |
|| |------------------------------------------->|
\/ | 480|
TS---->|<-------------------------------------------|
3.3. Session Completion Delay (SCD)
This metric is utilized to detect failures or impairments delaying
the time necessary to end a session. SCD is measured for both
successful and failed session completions. This metric is measured
from the originating UAC or proxy perspective as relative to the end-
to-end network under measurement. The output value of this metric is
numerical and should be adjusted to indicate seconds and/or
milliseconds. The following represents the calculation for this
metric:
SCD = Time of 2XX or Timeout - Time of Completion Message (BYE)
This metric is commonly calculated as an average. The following
represents the calculation for this metric as an average:
Malas Expires February 16, 2007 [Page 8]
Internet-Draft SIP End-to-End Performance Metrics August 2006
SUM (Time of 2XX or Timeout - Time of Completion Message)
ASCD = ---------------------------------------------------------
SUM # of Completed Sessions
3.3.1. Successful session completion SCD
In a successful session completion, SCD is defined as the interval
between sending a session completion message, such as a BYE, and
receiving the subsequent 2XX acknowledgement. The following flow
provides an example of identifiable events necessary for inputs in
calculating SCD during a successful session completion:
UA1 UA2
| |
|INVITE |
|--------------------->|
| 180|
|<---------------------|
| 200|
|<---------------------|
|ACK |
|--------------------->|
|BYE |
TB---->|--------------------->|
/\ | |
|| | |
SCD | |
|| | |
\/ | 200|
TS---->|<---------------------|
3.3.2. Failed session completion SCD
In some cases, no response is received after a session completion
message is sent and potentially retried. In this case, SCD is
defined as the interval between sending a session completion message,
such as a BYE, and the resulting Timer F expiration. The following
flow provides an example of identifiable events necessary for inputs
in calculating SCD during a failed session completion attempt:
Malas Expires February 16, 2007 [Page 9]
Internet-Draft SIP End-to-End Performance Metrics August 2006
UA1 UA2
| |
|INVITE |
|--------------------->|
| 180|
|<---------------------|
| 200|
|<---------------------|
|ACK |
|--------------------->|
|BYE |
TB---->|--------------------->|
/\ |BYE |
|| |--------------------->|
SCD |BYE |
|| |--------------------->|
\/ | |
TS---->|***Timer F Expires |
3.4. Average Hops per INVITE (AHI)
This metric is used to indicate potential inefficient routing and to
detect failure occurrences related to the number of elements
traversed by a single SIP INVITE. AHI is defined as the number of
hops traversed by an INVITE. It is calculated as an average. This
metric requires the Max-Forwards value to be captured at both the
originating UAC or proxy and the terminating UAS or proxy perspective
as relative to the end-to-end network under measurement. The output
value of this metric is measured in a numerical value indicating a
number of hops.
Variables =
a = Initial INVITE "Max-Forwards" value
b = Initial INVITE received by terminating UAS "Max-Forwards"
value
c = # of Hops for INVITE requests
d = SUM # of INVITE requests
Malas Expires February 16, 2007 [Page 10]
Internet-Draft SIP End-to-End Performance Metrics August 2006
c = a - b
This metric is calculated as an average. The following represents
the calculation for this metric:
AHI = (SUM of aggregate c's / d)
The following dialog provides an example describing the inputs
necessary for this calculation (The dialog continuation was omitted
for clarity):
UA1 Proxy 1 Proxy 2 UA2
| | | |
|INVITE | | |
|--------------->| | |
| 407| | |
|<---------------| | |
|ACK | | |
|--------------->| | |
|INVITE (F4) | | |
|--------------->|INVITE (F5) | |
| 100|--------------->|INVITE (F6) |
|<---------------| 100|--------------->|
| |<---------------| |
Message Details (Only the message details of the INVITE messages have
been included for clarity. Also, some headers after Max-Forwards
have been omitted for additional clarity.):
(F4) INVITE UA1 -> Proxy 1
INVITE sip:ua2@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
Route: <sip:ss1.atlanta.example.com;lr>
From: UA1 <sip:ua1@atlanta.example.com>;tag=9fxced76sl
To: UA2 <sip:ua2@biloxi.example.com>
(F5) INVITE Proxy 1 -> Proxy 2
INVITE sip:ua2@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP
ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Max-Forwards: 69
Record-Route: <sip:ss1.atlanta.example.com;lr>
Malas Expires February 16, 2007 [Page 11]
Internet-Draft SIP End-to-End Performance Metrics August 2006
From: UA1 <sip:ua1@atlanta.example.com>;tag=9fxced76sl
To: UA2 <sip:ua2@biloxi.example.com>
(F6) INVITE Proxy 2 -> UA2
INVITE sip:ua2@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1
Via: SIP/2.0/TCP
ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.111
Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Max-Forwards: 68
Record-Route: <sip:ss2.biloxi.example.com;lr>,
<sip:ss1.atlanta.example.com;lr>
From: UA1 <sip:ua1@atlanta.example.com>;tag=9fxced76sl
To: UA2 <sip:ua2@biloxi.example.com>
3.5. Session Duration Time (SDT)
This metric is used to detect problems (e.g. poor audio quality)
causing short session durations. SDT is measured for both successful
and failed session completions. This metric is also known as Call
Hold Time, and is traditionally calculated as Average Call Hold Time
(ACHT) in telephony applications of SIP. This metric is measured
from the originating UAC or proxy perspective as relative to the end-
to-end network under measurement. The output value of this metric is
numerical and should be adjusted to indicate minutes and seconds.
The following represents the calculation for this metric:
SDT = Time of BYE or Timeout - Time of 200 OK response to INVITE
This metric is commonly calculated as an average. The following
represents the calculation for this metric as an average:
SUM (Time of BYE or Timeout - Time of 200 OK response to INVITE)
ASDT = --------------------------------------------------------------
SUM # of INVITE w/ 200OK & BYE or Timeout
3.5.1. Successful session completion SDT
In a successful session completion, SDT is calculated as an average
and is defined as the duration of a dialog from receipt of a 200 OK
response to an INVITE and an associated BYE message indicating dialog
completion.
Malas Expires February 16, 2007 [Page 12]
Internet-Draft SIP End-to-End Performance Metrics August 2006
The following flow provides an example of identifiable events
necessary for inputs in calculating SDT during a successful session
completion:
UA1 UA2
| |
|INVITE |
|--------------------->|
| 180|
|<---------------------|
| 200|
TB---->|<---------------------|
/\ |ACK |
|| |--------------------->|
|| | |
SDT | |
|| | |
|| | |
\/ |BYE |
TS---->|--------------------->|
| |
3.5.2. Failed session completion SDT
In some cases, no response is received after a session completion
message is sent and potentially retried. In this case, SDT is
defined as the interval between sending a session completion message,
such as a BYE, and the resulting Timer F expiration. The following
flow provides an example of identifiable events necessary for inputs
in calculating SDT during a failed session completion attempt:
UA1 UA2
| |
|INVITE |
|--------------------->|
| 180|
|<---------------------|
| 200|
TB---->|<---------------------|
/\ |BYE |
|| |--------------------->|
|| |BYE |
SDT |--------------------->|
|| |BYE |
|| |--------------------->|
\/ | |
TS---->|***Timer F Expires |
Malas Expires February 16, 2007 [Page 13]
Internet-Draft SIP End-to-End Performance Metrics August 2006
3.6. Session Establishment Rate (SER)
This metric is used to detect the ability of a terminating UA to
successfully establish sessions per INVITE request. SER is defined
as the number of INVITE requests resulting in a 200 OK response, to
the total number of attempted INVITE requests. This metric is also
known as Answer Seizure Rate (ASR) in telephony applications of SIP.
The input variables for this metric are captured from the originating
UAC or proxy perspective as relative to the end-to-end network under
measurement. The output value of this metric is numerical and should
be adjusted to indicate a percentage (likely a fractional percentage)
of successfully established sessions. The following represents the
calculation for this metric:
# of INVITE Requests w/ associated 200OK
SER = ----------------------------------------
Total # of INVITE Requests
The following flow provides an example of identifiable events
necessary for inputs in determining session establishment as
described above:
UA1 UA2
| |
|INVITE |
+----------->|------------------>|
| | 180|
| |<------------------|
Session Established | |
| | |
| | 200|
+----------->|<------------------|
| |
3.7. Session Defects (SD)
Session defects provide a subset of SIP failure responses, which
consistently indicate a failure in dialog processing. Defects are
necessary to provide input to calculations such as Defects per
Million (DPM) or other similar metrics. These failure responses are
in response to initial session setup requests, such as a new INVITE.
The input variables for this metric are captured from the originating
UAC or proxy perspective as relative to the end-to-end network under
measurement. The output value of this metric is numerical and should
be adjusted to indicate a percentage (likely a fractional percentage)
of defective sessions. The following failure responses provide a
guideline for defective criterion:
Malas Expires February 16, 2007 [Page 14]
Internet-Draft SIP End-to-End Performance Metrics August 2006
. 500 Server Internal Error
. 503 Service Unavailable
. 504 Server Timeout
This set of failure responses was derived through correlating more
granular ISUP failure responses as described in RFC 3398.
3.8. Ineffective Session Attempts (ISA)
Ineffective session attempts occur when a proxy or agent internally
releases a setup request with a failed or congested condition. This
metric is also known as Ineffective Machine Attempts (IMA) in
telephony applications of SIP, and was adopted from Telcordia GR-512-
CORE [7]. The input variables for this metric are captured from the
originating UAC or proxy perspective as relative to the end-to-end
network under measurement. The output value of this metric is
numerical and should be adjusted to indicate a percentage (likely a
fractional percentage) of ineffective session attempts. The
following failure responses provide a guideline for this criterion:
. 408 Request Timeout
. 500 Server Internal Error
. 503 Service Unavailable
. 504 Server Timeout
This set was derived in a similar manner as described in Section 3.6,
in addition 408 failure responses is indicative a congested state
with a downstream element.
This metric is calculated as a percentage of total session setup
requests. The following represents the calculation for this metric:
# of ISA
ISA % = -----------------------------
Total # of Session Requests
3.9. Session Disconnect Failures (SDF)
Session disconnect failures occur when an active session is
terminated due to a failure condition that can be identified by a
REASON header [5] in a BYE message. This occurs, for example, when a
user agent (UA) is controlling an IP or TDM (Time Division
Multiplexing) media gateway, and the media gateway notifies the UA of
a failure condition causing the loss of media related to an
Malas Expires February 16, 2007 [Page 15]
Internet-Draft SIP End-to-End Performance Metrics August 2006
established session. The UA will release the session with a BYE, but
should include a REASON header indicating the session was
disconnected abnormally. The REASON value is utilized to determine
the disconnect was a failure. This metric is also known as Cutoff
Calls (CC) in telephony applications of SIP, and was adopted from
Telcordia GR-512-CORE [7]. The input variables for this metric are
captured from the originating UAC or proxy perspective as relative to
the end-to-end network under measurement. The output value of this
metric is numerical and should be adjusted to indicate a percentage
(likely a fractional percentage) of session disconnect failures.
This metric is calculated as a percentage of total session completed
successfully as defined in Section 3.5. The following represents the
calculation for this metric:
# of SDF's
SDF % = -------------------------------
Total # of Session Requests
3.10. Session Completion Rate (SCR)
A session completion is defined as a SIP dialog, which completes
without failing due to a lack of response from an intended proxy or
UA. A session completes successfully when it begins with a setup
request and ends with a session completion message. This metric is
only used when at least one proxy is involved in the dialog. This
metric is also known as Call Completion Rate (CCR) in telephony
applications of SIP. The input variables for this metric are
captured from the originating UAC or proxy perspective as relative to
the end-to-end network under measurement. The output value of this
metric is numerical and should be adjusted to indicate a percentage
(likely a fractional percentage) of successfully completed sessions.
The following dialog [4] provides an example describing the necessary
events of a successful session completion:
UA1 Proxy 1 Proxy 2 UA2
| | | |
|INVITE | | |
|--------------->| | |
| 407| | |
|<---------------| | |
|ACK | | |
|--------------->| | |
|INVITE | | |
|--------------->|INVITE | |
| 100|--------------->|INVITE |
|<---------------| 100|--------------->|
Malas Expires February 16, 2007 [Page 16]
Internet-Draft SIP End-to-End Performance Metrics August 2006
| |<---------------| |
| | | 180|
| | 180 |<---------------|
| 180|<---------------| |
|<---------------| | 200|
| | 200|<---------------|
| 200|<---------------| |
|<---------------| | |
|ACK | | |
|--------------->|ACK | |
| |--------------->|ACK |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
| | | BYE|
| | BYE|<---------------|
| BYE|<---------------| |
|<---------------| | |
|200 | | |
|--------------->|200 | |
| |--------------->|200 |
| | |--------------->|
| | | |
The following dialog provides an example describing the necessary
events of an unsuccessful session completion:
UA1 Proxy 1 Proxy 2 UA2
| | | |
|INVITE | | |
|--------------->| | |
| 407| | |
|<---------------| | |
|ACK | | |
|--------------->| | |
|INVITE | | |
|--------------->|INVITE | |
| 100|--------------->|INVITE |
|<---------------| 100|--------------->|
| |<---------------| |
| | |INVITE |
| | |--------------->|
| | | |
| | |INVITE |
| | |--------------->|
| | | |
| | 408| |
| 408|<---------------| |
Malas Expires February 16, 2007 [Page 17]
Internet-Draft SIP End-to-End Performance Metrics August 2006
|<---------------|ACK | |
| |--------------->| |
|ACK | | |
|--------------->| | |
This metric is calculated as a percentage of total sessions completed
successfully. The following represents the calculation for this
metric:
# of Successfully Completed Sessions
SCR % = ---------------------------------------
Total # of Session Requests
3.11. Session Success Rate (SSR)
Session success rate is defined as the percentage of successfully
completed sessions compared to sessions, which fail due to ISA or
SDF. This metric is also known as Call Success Rate (CSR) in
telephony applications of SIP. The output value of this metric is
numerical and should be adjusted to indicate a percentage of
successful sessions. The following represents the calculation for
this metric:
SSR = 100% - (ISA% + SDF%)
4. Metric Correlations
These metrics may be used to determine the performance of a domain
and/or user. This would be to provide a metric relative to one or
more dimensions. The following is a subset of dimensions for
providing further granularity per metric:
. To "user"
. From "user"
. Bi-direction "user"
. To "domain"
. From "domain"
. Bi-direction "domain"
Example: The SCR of SIP domain A is 99.97%.
Malas Expires February 16, 2007 [Page 18]
Internet-Draft SIP End-to-End Performance Metrics August 2006
5. Additional Considerations
5.1. Back-to-back User Agent (B2BUA) Considerations
A B2BUA may impact the ability to collect these metrics with an end-
to-end perspective. It is necessary to realize a B2BUA may act as an
originating UAC and terminating UAS or it may act as a proxy. In
some cases, it may be necessary to consider information collected
from both sides of the B2BUA in order to determine the end-to-end
perspective. In other cases, the B2BUA may act simply as a proxy
allowing data to be derived as necessary for the input into any of
the listed calculations.
5.2. Data Collection Considerations
The input necessary for these calculations may be collected in a
number of different manners. It may be collected or retrieved from
call detail records (CDR) or raw signaling information generated by a
proxy or UA. When using records, time synchronization must be
considered between applicable elements.
The information may also be transmitted through use of SNMP traps as
described in the work in progress SIP MIB draft [6], or through a
potential undefined new performance metric event package [3]
retrieved via SUBSCRIBE requests.
Data may be collected for a sample of calls or all calls, and may
also be derived from test call scenarios. These metrics are flexible
based on the needs of the application.
5.3. Testing Documentation
In some cases, these metrics will be used to provide output values to
signify the performance level of a specific SIP-based element. When
using these metrics in a test environment, the environment must be
accurately documented for the purposes of replicating any output
values in future testing and/or validation.
6. Security Considerations
Security should be considered in the aspect of securing the relative
data utilized in providing input to the above calculations. All
other aspects of security should be considered as described in [2].
7. IANA Considerations
There are no IANA considerations at this time.
Malas Expires February 16, 2007 [Page 19]
Internet-Draft SIP End-to-End Performance Metrics August 2006
8. Conclusions
The proposed guideline provides a description of common performance
metrics, and their defined use with SIP. The use of these metrics
will provide a common viewpoint across all vendors, service
providers, and customers. These metrics will likely be utilized in
production SIP environments for providing input regarding Key
Performance Indicators (KPI) and Service Level Agreement (SLA)
indications; however, they may also be used for testing end-to-end
SIP-based service environments.
9. Acknowledgments
I would like to thank John Hearty for his efforts in scrubbing
through the draft and providing insight regarding clarification of
certain aspects described throughout the document.
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[4] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
Summers, "Session Initiation Protocol (SIP) Basic Call
Flow Examples", BCP 75, RFC 3665, December 2003.
[5] Schulzrinne, H., Oran, D., Camarillo, G., "The Reason Header
Field for the Sessions Initiation Protocol (SIP)", RFC 3326,
December 2002.
[6] Lingle, K., Mule, J., Maeng, J., Walker, D., "Management
Information Base for the Session Initiation Protocol (SIP)",
draft-ietf-sip-mib-10, Work in Progress.
[7] Telcordia, "LSSGR: Reliability, Section 12", GR-512-CORE, Issue
2, January 1998.
Malas Expires February 16, 2007 [Page 20]
Internet-Draft SIP End-to-End Performance Metrics August 2006
10.2. Informative References
Author's Addresses
Daryl Malas
Level 3 Communications LLC
1025 Eldorado Blvd.
Broomfield, CO 80021
USA
EMail: daryl.malas@level3.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006).
Malas Expires February 16, 2007 [Page 21]
Internet-Draft SIP End-to-End Performance Metrics August 2006
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Malas Expires February 16, 2007 [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-24 02:45:35 |