draft-ietf-bmwg-sip-bench-term-07.txt   draft-ietf-bmwg-sip-bench-term-08.txt 
Benchmarking Methodology Working Group C. Davids Benchmarking Methodology Working C. Davids
Internet-Draft Illinois Institute of Technology Group Illinois Institute of Technology
Intended status: Informational V. Gurbani Internet-Draft V. Gurbani
Expires: July 10, 2013 Bell Laboratories, Intended status: Informational Bell Laboratories, Alcatel-Lucent
Alcatel-Lucent Expires: July 12, 2013 S. Poretsky
S. Poretsky
Allot Communications Allot Communications
January 6, 2013 January 8, 2013
Terminology for Benchmarking Session Initiation Protocol (SIP) Terminology for Benchmarking Session Initiation Protocol (SIP)
Networking Devices Networking Devices
draft-ietf-bmwg-sip-bench-term-07 draft-ietf-bmwg-sip-bench-term-08
Abstract Abstract
This document provides a terminology for benchmarking the SIP This document provides a terminology for benchmarking the SIP
performance of networking devices. The term performance in this performance of networking devices. The term performance in this
context means the capacity of the device- or system-under-test to context means the capacity of the device- or system-under-test to
process SIP messages. Terms are included for test components, test process SIP messages. Terms are included for test components, test
setup parameters, and performance benchmark metrics for black-box setup parameters, and performance benchmark metrics for black-box
benchmarking of SIP networking devices. The performance benchmark benchmarking of SIP networking devices. The performance benchmark
metrics are obtained for the SIP signaling plane only. The terms are metrics are obtained for the SIP signaling plane only. The terms are
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 10, 2013. This Internet-Draft will expire on July 12, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 49 skipping to change at page 3, line 49
3.4. Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . 31 3.4. Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.1. Registration Rate . . . . . . . . . . . . . . . . . . 31 3.4.1. Registration Rate . . . . . . . . . . . . . . . . . . 31
3.4.2. Session Establishment Rate . . . . . . . . . . . . . . 31 3.4.2. Session Establishment Rate . . . . . . . . . . . . . . 31
3.4.3. Session Capacity . . . . . . . . . . . . . . . . . . . 32 3.4.3. Session Capacity . . . . . . . . . . . . . . . . . . . 32
3.4.4. Session Overload Capacity . . . . . . . . . . . . . . 33 3.4.4. Session Overload Capacity . . . . . . . . . . . . . . 33
3.4.5. Session Establishment Performance . . . . . . . . . . 33 3.4.5. Session Establishment Performance . . . . . . . . . . 33
3.4.6. Session Attempt Delay . . . . . . . . . . . . . . . . 34 3.4.6. Session Attempt Delay . . . . . . . . . . . . . . . . 34
3.4.7. IM Rate . . . . . . . . . . . . . . . . . . . . . . . 34 3.4.7. IM Rate . . . . . . . . . . . . . . . . . . . . . . . 34
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
5. Security Considerations . . . . . . . . . . . . . . . . . . . 35 5. Security Considerations . . . . . . . . . . . . . . . . . . . 35
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.1. Normative References . . . . . . . . . . . . . . . . . . . 36 7.1. Normative References . . . . . . . . . . . . . . . . . . . 36
7.2. Informational References . . . . . . . . . . . . . . . . . 36 7.2. Informational References . . . . . . . . . . . . . . . . . 36
Appendix A. White Box Benchmarking Terminology . . . . . . . . . 37 Appendix A. White Box Benchmarking Terminology . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 5, line 48 skipping to change at page 5, line 48
o Stateless Proxy: A logical entity that does not maintain the o Stateless Proxy: A logical entity that does not maintain the
client or server transaction state machines defined in this client or server transaction state machines defined in this
specification when it processes requests. A stateless proxy specification when it processes requests. A stateless proxy
forwards every request it receives downstream and every response forwards every request it receives downstream and every response
it receives upstream. it receives upstream.
o Back-to-back User Agent: A back-to-back user agent (B2BUA) is a o Back-to-back User Agent: A back-to-back user agent (B2BUA) is a
logical entity that receives a request and processes it as a user logical entity that receives a request and processes it as a user
agent server (UAS). In order to determine how the request should agent server (UAS). In order to determine how the request should
be answered, it acts as a user agent client (UAC) and generates be answered, it acts as a user agent client (UAC) and generates
requests. Unlike a proxy server, it maintains dialog state and requests. Unlike a proxy server, it maintains dialog state and
must participate in all requests sent on the dialogs it has must participate in all requests sent on the dialogues it has
established. Since it is a concatenation of a UAC and a UAS, no established. Since it is a concatenation of a UAC and a UAS, no
explicit definitions are needed for its behavior. explicit definitions are needed for its behavior.
o Loop: A request that arrives at a proxy, is forwarded, and later o Loop: A request that arrives at a proxy, is forwarded, and later
arrives back at the same proxy. When it arrives the second time, arrives back at the same proxy. When it arrives the second time,
its Request-URI is identical to the first time, and other header its Request-URI is identical to the first time, and other header
fields that affect proxy operation are unchanged, so that the fields that affect proxy operation are unchanged, so that the
proxy will make the same processing decision on the request it proxy will make the same processing decision on the request it
made the first time. Looped requests are errors, and the made the first time. Looped requests are errors, and the
procedures for detecting them and handling them are described by procedures for detecting them and handling them are described by
skipping to change at page 9, line 27 skipping to change at page 9, line 27
+--------+ Signaling request +--------+ +--------+ Signaling request +--------+
| +----------------------------->| | | +----------------------------->| |
| Tester | | Tester | | Tester | | Tester |
| EA | Signaling response | EA | | EA | Signaling response | EA |
| |<-----------------------------+ | | |<-----------------------------+ |
+--------+ +--------+ +--------+ +--------+
/|\ /|\ /|\ /|\
| Media | | Media |
+=========================================+ +=========================================+
Figure 1: Baseline performance of the Emulated Agent without Figure 1: Baseline performance of the Emulated Agent without a DUT
a DUT present present
Figure 2 shows the DUT playing the role of a user agent client (UAC), Figure 2 shows the DUT playing the role of a user agent client (UAC),
initiating requests and absorbing responses. This model can be used initiating requests and absorbing responses. This model can be used
to baseline the performance of the DUT acting as an UAC without to baseline the performance of the DUT acting as an UAC without
associated media. associated media.
+--------+ Signaling request +--------+ +--------+ Signaling request +--------+
| +----------------------------->| | | +----------------------------->| |
| DUT | | Tester | | DUT | | Tester |
| | Signaling response | EA | | | Signaling response | EA |
| |<-----------------------------+ | | |<-----------------------------+ |
+--------+ +--------+ +--------+ +--------+
Figure 2: Baseline performance for DUT acting as a Figure 2: Baseline performance for DUT acting as a user agent client
user agent client without associated media without associated media
Figure 3 shows the DUT plays the role of a user agent server (UAS), Figure 3 shows the DUT playing the role of a user agent server (UAS),
absorbing the requests and sending responses. This model can be used absorbing the requests and sending responses. This model can be used
as a baseline performance for the DUT acting as a UAS without as a baseline performance for the DUT acting as a UAS without
associated media. associated media.
+--------+ Signaling request +--------+ +--------+ Signaling request +--------+
| +----------------------------->| | | +----------------------------->| |
| Tester | | DUT | | Tester | | DUT |
| EA | Response | | | EA | Response | |
| |<-----------------------------+ | | |<-----------------------------+ |
+--------+ +--------+ +--------+ +--------+
Figure 3: Baseline performance for DUT acting as a Figure 3: Baseline performance for DUT acting as a user agent server
user agent server without associated media without associated media
Figure 4 shows the DUT plays the role of a user agent client (UAC), Figure 4 shows the DUT plays the role of a user agent client (UAC),
initiating requests and absorbing responses. This model can be used initiating requests and absorbing responses. This model can be used
as a baseline performance for the DUT acting as a UAC with associated as a baseline performance for the DUT acting as a UAC with associated
media. media.
+--------+ Signaling request +--------+ +--------+ Signaling request +--------+
| +----------------------------->| | | +----------------------------->| |
| DUT | | Tester | | DUT | | Tester |
| | Signaling response | (EA) | | | Signaling response | (EA) |
| |<-----------------------------+ | | |<-----------------------------+ |
| |<============ Media =========>| | | |<============ Media =========>| |
+--------+ +--------+ +--------+ +--------+
Figure 4: Baseline performance for DUT acting as a Figure 4: Baseline performance for DUT acting as a user agent client
user agent client with associated media with associated media
Figure 5 shows the DUT plays the role of a user agent server (UAS), Figure 5 shows the DUT plays the role of a user agent server (UAS),
absorbing the requests and sending responses. This model can be used absorbing the requests and sending responses. This model can be used
as a baseline performance for the DUT acting as a UAS with associated as a baseline performance for the DUT acting as a UAS with associated
media. media.
+--------+ Signaling request +--------+ +--------+ Signaling request +--------+
| +----------------------------->| | | +----------------------------->| |
| Tester | | DUT | | Tester | | DUT |
| (EA) | Response | | | (EA) | Response | |
| |<-----------------------------+ | | |<-----------------------------+ |
| |<============ Media =========>| | | |<============ Media =========>| |
+--------+ +--------+ +--------+ +--------+
Figure 5: Baseline performance for DUT acting as a Figure 5: Baseline performance for DUT acting as a user agent server
user agent server with associated media with associated media
Figure 6 shows that the Tester acts as the initiating and responding Figure 6 shows that the Tester acts as the initiating and responding
EA as the DUT/SUT forwards Session Attempts. EA as the DUT/SUT forwards Session Attempts.
+--------+ Session +--------+ Session +--------+ +--------+ Session +--------+ Session +--------+
| | Attempt | | Attempt | | | | Attempt | | Attempt | |
| |<------------+ |<------------+ | | |<------------+ |<------------+ |
| | | | | | | | | | | |
| | Response | | Response | | | | Response | | Response | |
| Tester +------------>| DUT +------------>| Tester | | Tester +------------>| DUT +------------>| Tester |
| (EA) | | | | (EA) | | (EA) | | | | (EA) |
| | | | | | | | | | | |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
Figure 6: DUT/SUT performance benchmark for session Figure 6: DUT/SUT performance benchmark for session establishment
establishment without media without media
Figure 7 is used when performing those same benchmarks with Figure 7 is used when performing those same benchmarks with
Associated Media traversing the DUT/SUT. Associated Media traversing the DUT/SUT.
+--------+ Session +--------+ Session +--------+ +--------+ Session +--------+ Session +--------+
| | Attempt | | Attempt | | | | Attempt | | Attempt | |
| |<------------+ |<------------+ | | |<------------+ |<------------+ |
| | | | | | | | | | | |
| | Response | | Response | | | | Response | | Response | |
| Tester +------------>| DUT +------------>| Tester | | Tester +------------>| DUT +------------>| Tester |
| (EA) | | | | (EA) | | (EA) | | | | (EA) |
| | Media | | Media | | | | Media | | Media | |
| |<===========>| |<===========>| | | |<===========>| |<===========>| |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
Figure 7: DUT/SUT performance benchmark for session Figure 7: DUT/SUT performance benchmark for session establishment
establishment with media traversing the DUT with media traversing the DUT
Figure 8 is to be used when performing those same benchmarks with Figure 8 is to be used when performing those same benchmarks with
Associated Media, but the media does not traverse the DUT/SUT. Associated Media, but the media does not traverse the DUT/SUT.
Again, the benchmarking of the media is not within the scope of this Again, the benchmarking of the media is not within the scope of this
work item. The SIP control signaling is benchmarked in the presence work item. The SIP control signaling is benchmarked in the presence
of Associated Media to determine if the SDP body of the signaling and of Associated Media to determine if the SDP body of the signaling and
the handling of media impacts the performance of the DUT/SUT. the handling of media impacts the performance of the DUT/SUT.
+--------+ Session +--------+ Session +--------+ +--------+ Session +--------+ Session +--------+
| | Attempt | | Attempt | | | | Attempt | | Attempt | |
skipping to change at page 12, line 18 skipping to change at page 12, line 18
| | | | | | | | | | | |
| | Response | | Response | | | | Response | | Response | |
| Tester +------------>| DUT +------------>| Tester | | Tester +------------>| DUT +------------>| Tester |
| (EA) | | | | (EA) | | (EA) | | | | (EA) |
| | | | | | | | | | | |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
/|\ /|\ /|\ /|\
| Media | | Media |
+=============================================+ +=============================================+
Figure 8: DUT/SUT performance benchmark for session Figure 8: DUT/SUT performance benchmark for session establishment
establishment with media external to the DUT with media external to the DUT
Figure 9 is used when performing benchmarks that require one or more Figure 9 is used when performing benchmarks that require one or more
intermediaries to be in the signaling path. The intent is to gather intermediaries to be in the signaling path. The intent is to gather
benchmarking statistics with a series of DUTs in place. In this benchmarking statistics with a series of DUTs in place. In this
topology, the media is delivered end-to-end and does not traverse the topology, the media is delivered end-to-end and does not traverse the
DUT. DUT.
SUT SUT
------------------^^^^^^^^------------- ------------------^^^^^^^^-------------
/ \ / \
skipping to change at page 12, line 43 skipping to change at page 12, line 43
| | | | | | | | | | | | | | | |
| | Response | | Response | | Response | | | | Response | | Response | | Response | |
|Tester+--------->|DUT+--------->|DUT|--------->|Tester| |Tester+--------->|DUT+--------->|DUT|--------->|Tester|
| (EA) | | | | | | (EA) | | (EA) | | | | | | (EA) |
| | | | | | | | | | | | | | | |
+------+ +---+ +---+ +------+ +------+ +---+ +---+ +------+
/|\ /|\ /|\ /|\
| Media | | Media |
+=============================================+ +=============================================+
Figure 9: DUT/SUT performance benchmark for session Figure 9: DUT/SUT performance benchmark for session establishment
establishment with multiple DUTs and end-to-end media with multiple DUTs and end-to-end media
Figure 10 is used when performing benchmarks that require one or more Figure 10 is used when performing benchmarks that require one or more
intermediaries to be in the signaling path. The intent is to gather intermediaries to be in the signaling path. The intent is to gather
benchmarking statistics with a series of DUTs in place. In this benchmarking statistics with a series of DUTs in place. In this
topology, the media is delivered hop-by-hop through each DUT. topology, the media is delivered hop-by-hop through each DUT.
SUT SUT
-----------------^^^^^^^^------------- -----------------^^^^^^^^-------------
/ \ / \
+------+ Session +---+ Session +---+ Session +------+ +------+ Session +---+ Session +---+ Session +------+
| | Attempt | | Attempt | | Attempt | | | | Attempt | | Attempt | | Attempt | |
| |<---------+ |<---------+ |<---------+ | | |<---------+ |<---------+ |<---------+ |
| | | | | | | | | | | | | | | |
| | Response | | Response | | Response | | | | Response | | Response | | Response | |
|Tester+--------->|DUT+--------->|DUT|--------->|Tester| |Tester+--------->|DUT+--------->|DUT|--------->|Tester|
| (EA) | | | | | | (EA) | | (EA) | | | | | | (EA) |
| | | | | | | | | | | | | | | |
| |<========>| |<========>| |<========>| | | |<========>| |<========>| |<========>| |
+------+ Media +---+ Media +---+ Media +------+ +------+ Media +---+ Media +---+ Media +------+
Figure 10: DUT/SUT performance benchmark for session Figure 10: DUT/SUT performance benchmark for session establishment
establishment with multiple DUTs and hop- by-hop with multiple DUTs and hop- by-hop media
media
Figure 11 illustrates the SIP signaling for an Established Session. Figure 11 illustrates the SIP signaling for an Established Session.
The Tester acts as the EAs and initiates a Session Attempt with the The Tester acts as the EAs and initiates a Session Attempt with the
DUT/SUT. When the Emulated Agent (EA) receives a 200 OK from the DUT/SUT. When the EA receives a 200 OK from the DUT/SUT that session
DUT/SUT that session is considered to be an Established Session. The is considered to be an Established Session. The illustration
illustration indicates three states of the session bring created by indicates three states of the session bring created by the EA - (1)
the EA - Attempting, Established, and Disconnecting. Sessions can be Attempting, (2) Established, and (3) Disconnecting. Sessions can be
one of two type: Invite-Initiated Session (IS) or Non-Invite one of two type: Invite-Initiated Session (IS) or Non-Invite
Initiated Session (NS). Failure for the DUT/SUT to successfully Initiated Session (NS). Failure for the DUT/SUT to successfully
respond within the Establishment Threshold Time is considered a respond within the Establishment Threshold Time is considered a
Session Attempt Failure. SIP Invite messages MUST include the SDP Session Attempt Failure. SIP Invite messages MUST include the SDP
body to specify the Associated Media. Use of Associated Media, to be body to specify the Associated Media. Use of Associated Media, to be
sourced from the EA, is optional. When Associated Media is used, it sourced from the EA, is optional. When Associated Media is used, it
may traverse the DUT/SUT depending upon the type of DUT/SUT. The may traverse the DUT/SUT depending upon the type of DUT/SUT. The
Associated Media is shown in Figure 11 as "Media" connected to media Associated Media is shown in Figure 11 as "Media" connected to media
ports M1 and M2 on the EA. After the EA sends a BYE, the session ports M1 and M2 on the EA. After the EA sends a BYE, the session
disconnects. Performance test cases for session disconnects are not disconnects. Performance test cases for session disconnects are not
skipping to change at page 17, line 43 skipping to change at page 17, line 43
3.1.2. Signaling Plane 3.1.2. Signaling Plane
Definition: Definition:
The plane in which SIP messages [RFC3261] are exchanged between The plane in which SIP messages [RFC3261] are exchanged between
SIP Agents [RFC3261]. SIP Agents [RFC3261].
Discussion: Discussion:
SIP messages are used to establish sessions in several ways: SIP messages are used to establish sessions in several ways:
directly between two User Agents [RFC3261], through a Proxy Server directly between two User Agents [RFC3261], through a Proxy Server
[RFC3261], or through a series of Proxy Servers. The Session [RFC3261], or through a series of Proxy Servers. The Session
Description Protocol is included in the Signaling Plane. (SDP). Description Protocol (SDP) is included in the Signaling Plane.
The Signaling Plane for a single Session is represented by The Signaling Plane for a single Session is represented by
session.sig. session.sig.
Measurement Units: Measurement Units:
N/A. N/A.
Issues: Issues:
None. None.
See Also: See Also:
skipping to change at page 30, line 14 skipping to change at page 30, line 14
Discussion: Discussion:
This is an optional process that a SIP proxy may employ; the This is an optional process that a SIP proxy may employ; the
process is described under Proxy Behavior in RFC 3261 [RFC3261] in process is described under Proxy Behavior in RFC 3261 [RFC3261] in
Section 16.3 Request Validation and that section also contains Section 16.3 Request Validation and that section also contains
suggestions as to how the option could be implemented. Any suggestions as to how the option could be implemented. Any
procedure to detect loops will use processor cycles and hence procedure to detect loops will use processor cycles and hence
could impact the performance of a proxy. could impact the performance of a proxy.
Measurement Units: Measurement Units:
NA N/A
Issues: Issues:
None. None.
See Also: See Also:
3.3.9. Forking Option 3.3.9. Forking Option
Definition: Definition:
An option that enables a Proxy to fork requests to more than one An option that enables a Proxy to fork requests to more than one
skipping to change at page 32, line 27 skipping to change at page 32, line 27
Definition: Definition:
The maximum value of Standing Sessions Count achieved by the DUT/ The maximum value of Standing Sessions Count achieved by the DUT/
SUT during a time period T in which the EA is sending session SUT during a time period T in which the EA is sending session
establishment messages at the Session Establishment Rate. establishment messages at the Session Establishment Rate.
Discussion: Discussion:
Sessions may be IS or NS. If they are IS they can be with or Sessions may be IS or NS. If they are IS they can be with or
without media. When benchmarking Session Capacity for sessions without media. When benchmarking Session Capacity for sessions
with media it is required that these sessions be permanently with media it is required that these sessions be permanently
established (i.e., they remain active for the duration of the established, i.e., they remain active for the duration of the
test.) This can be achieved by causing the EA not to send a BYE test. In the signaling plane, this requirement means that the
for the duration of the testing. In the signaling plane, this dialog lasts as long as the test lasts. When media is present,
requirement means that the dialog lasts as long as the test lasts. the Media Session Hold Time MUST be set to infinity so that
When media is present, the Media Session Hold Time MUST be set to sessions remain established for the duration of the test. If the
infinity so that sessions remain established for the duration of DUT/SUT is dialog-stateful, then we expect its performance will be
the test. If the DUT/SUT is dialog-stateful, then we expect its impacted by setting Media Session Hold Time to infinity, since the
performance will be impacted by setting Media Session Hold Time to DUT/SUT will need to allocate resources to process and store the
infinity, since the DUT/SUT will need to allocate resources to state information. The report of the Session Capacity must
process and store the state information. The report of the include the Session Establishment Rate at which it was measured.
Session Capacity must include the Session Establishment Rate at
which it was measured.
Measurement Units: Measurement Units:
sessions sessions
Issues: Issues:
None. None.
See Also: See Also:
Established Session Established Session
Session Attempt Rate Session Attempt Rate
skipping to change at page 33, line 20 skipping to change at page 33, line 18
The maximum number of Established Sessions that can exist The maximum number of Established Sessions that can exist
simultaneously on the DUT/SUT until it stops responding to Session simultaneously on the DUT/SUT until it stops responding to Session
Attempts. Attempts.
Discussion: Discussion:
Session Overload Capacity is measured after the Session Capacity Session Overload Capacity is measured after the Session Capacity
is measured. The Session Overload Capacity is greater than or is measured. The Session Overload Capacity is greater than or
equal to the Session Capacity. When benchmarking Session Overload equal to the Session Capacity. When benchmarking Session Overload
Capacity, continue to offer Session Attempts to the DUT/SUT after Capacity, continue to offer Session Attempts to the DUT/SUT after
the first Session Attempt Failure occurs and measure Established the first Session Attempt Failure occurs and measure Established
Sessions until no there is no SIP message response for the Sessions until there is no SIP message response for the duration
duration of the Establishment Threshold. Note that the Session of the Establishment Threshold. Note that the Session
Establishment Performance is expected to decrease after the first Establishment Performance is expected to decrease after the first
Session Attempt Failure occurs. Session Attempt Failure occurs.
Units: Units:
Sessions Sessions
Issues: Issues:
None. None.
See Also: See Also:
skipping to change at page 36, line 10 skipping to change at page 35, line 48
formalize a set of common terminology for benchmarking SIP networks. formalize a set of common terminology for benchmarking SIP networks.
Packets with unintended and/or unauthorized DSCP or IP precedence Packets with unintended and/or unauthorized DSCP or IP precedence
values may present security issues. Determining the security values may present security issues. Determining the security
consequences of such packets is out of scope for this document. consequences of such packets is out of scope for this document.
6. Acknowledgments 6. Acknowledgments
The authors would like to thank Keith Drage, Cullen Jennings, Daryl The authors would like to thank Keith Drage, Cullen Jennings, Daryl
Malas, Al Morton, and Henning Schulzrinne for invaluable Malas, Al Morton, and Henning Schulzrinne for invaluable
contributions to this document. Dale Worley provided an extensive contributions to this document. Dale Worley provided an extensive
review that lead to improvements in the documents. review that lead to improvements in the documents. We are grateful
to Barry Constantine for providing valuable comments during the
document's WGLC.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999. Network Interconnect Devices", RFC 2544, March 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[I-D.ietf-bmwg-sip-bench-meth] [I-D.ietf-bmwg-sip-bench-meth]
Davids, C., Gurbani, V., and S. Poretsky, "Methodology for Davids, C., Gurbani, V., and S. Poretsky, "Methodology for
Benchmarking SIP Networking Devices", Benchmarking SIP Networking Devices",
draft-ietf-bmwg-sip-bench-meth-06 (work in progress), draft-ietf-bmwg-sip-bench-meth-08 (work in progress),
November 2012. January 2013.
7.2. Informational References 7.2. Informational References
[RFC2285] Mandeville, R., "Benchmarking Terminology for LAN [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN
Switching Devices", RFC 2285, February 1998. Switching Devices", RFC 2285, February 1998.
[RFC1242] Bradner, S., "Benchmarking terminology for network [RFC1242] Bradner, S., "Benchmarking terminology for network
interconnection devices", RFC 1242, July 1991. interconnection devices", RFC 1242, July 1991.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
 End of changes. 24 change blocks. 
56 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/