draft-ietf-bmwg-sip-bench-meth-12.txt   rfc7502.txt 
Benchmarking Methodology Working Group C. Davids Internet Engineering Task Force (IETF) C. Davids
Internet-Draft Illinois Institute of Technology Request for Comments: 7502 Illinois Institute of Technology
Intended status: Informational V. Gurbani Category: Informational V. Gurbani
Expires: May 16, 2015 Bell Laboratories, ISSN: 2070-1721 Bell Laboratories, Alcatel-Lucent
Alcatel-Lucent
S. Poretsky S. Poretsky
Allot Communications Allot Communications
November 12, 2014 April 2015
Methodology for Benchmarking Session Initiation Protocol (SIP) Devices: Methodology for Benchmarking Session Initiation Protocol (SIP) Devices:
Basic session setup and registration Basic Session Setup and Registration
draft-ietf-bmwg-sip-bench-meth-12
Abstract Abstract
This document provides a methodology for benchmarking the Session This document provides a methodology for benchmarking the Session
Initiation Protocol (SIP) performance of devices. Terminology Initiation Protocol (SIP) performance of devices. Terminology
related to benchmarking SIP devices is described in the companion related to benchmarking SIP devices is described in the companion
terminology document. Using these two documents, benchmarks can be terminology document (RFC 7501). Using these two documents,
obtained and compared for different types of devices such as SIP benchmarks can be obtained and compared for different types of
Proxy Servers, Registrars and Session Border Controllers. The term devices such as SIP Proxy Servers, Registrars, and Session Border
"performance" in this context means the capacity of the device-under- Controllers. The term "performance" in this context means the
test (DUT) to process SIP messages. Media streams are used only to capacity of the Device Under Test (DUT) to process SIP messages.
study how they impact the signaling behavior. The intent of the two Media streams are used only to study how they impact the signaling
documents is to provide a normalized set of tests that will enable an behavior. The intent of the two documents is to provide a normalized
objective comparison of the capacity of SIP devices. Test setup set of tests that will enable an objective comparison of the capacity
parameters and a methodology are necessary because SIP allows a wide of SIP devices. Test setup parameters and a methodology are
range of configuration and operational conditions that can influence necessary because SIP allows a wide range of configurations and
performance benchmark measurements. operational conditions that can influence performance benchmark
measurements.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on May 16, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7502.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Benchmarking Topologies . . . . . . . . . . . . . . . . . . . 5 3. Benchmarking Topologies . . . . . . . . . . . . . . . . . . . 5
4. Test Setup Parameters . . . . . . . . . . . . . . . . . . . . 7 4. Test Setup Parameters . . . . . . . . . . . . . . . . . . . . 7
4.1. Selection of SIP Transport Protocol . . . . . . . . . . . 7 4.1. Selection of SIP Transport Protocol . . . . . . . . . . . 7
4.2. Connection-oriented Transport Management . . . . . . . . . 7 4.2. Connection-Oriented Transport Management . . . . . . . . 7
4.3. Signaling Server . . . . . . . . . . . . . . . . . . . . . 8 4.3. Signaling Server . . . . . . . . . . . . . . . . . . . . 7
4.4. Associated Media . . . . . . . . . . . . . . . . . . . . . 8 4.4. Associated Media . . . . . . . . . . . . . . . . . . . . 8
4.5. Selection of Associated Media Protocol . . . . . . . . . . 8 4.5. Selection of Associated Media Protocol . . . . . . . . . 8
4.6. Number of Associated Media Streams per SIP Session . . . . 8 4.6. Number of Associated Media Streams per SIP Session . . . 8
4.7. Codec Type . . . . . . . . . . . . . . . . . . . . . . . . 8 4.7. Codec Type . . . . . . . . . . . . . . . . . . . . . . . 8
4.8. Session Duration . . . . . . . . . . . . . . . . . . . . . 8 4.8. Session Duration . . . . . . . . . . . . . . . . . . . . 8
4.9. Attempted Sessions per Second (sps) . . . . . . . . . . . 9 4.9. Attempted Sessions per Second (sps) . . . . . . . . . . . 8
4.10. Benchmarking algorithm . . . . . . . . . . . . . . . . . . 9 4.10. Benchmarking Algorithm . . . . . . . . . . . . . . . . . 9
5. Reporting Format . . . . . . . . . . . . . . . . . . . . . . . 11 5. Reporting Format . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Test Setup Report . . . . . . . . . . . . . . . . . . . . 11 5.1. Test Setup Report . . . . . . . . . . . . . . . . . . . . 11
5.2. Device Benchmarks for session setup . . . . . . . . . . . 12 5.2. Device Benchmarks for Session Setup . . . . . . . . . . . 12
5.3. Device Benchmarks for registrations . . . . . . . . . . . 12 5.3. Device Benchmarks for Registrations . . . . . . . . . . . 12
6. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Baseline Session Establishment Rate of the test bed . . . 13 6.1. Baseline Session Establishment Rate of the Testbed . . . 13
6.2. Session Establishment Rate without media . . . . . . . . . 13 6.2. Session Establishment Rate without Media . . . . . . . . 13
6.3. Session Establishment Rate with Media not on DUT . . . . . 13 6.3. Session Establishment Rate with Media Not on DUT . . . . 13
6.4. Session Establishment Rate with Media on DUT . . . . . . . 14 6.4. Session Establishment Rate with Media on DUT . . . . . . 14
6.5. Session Establishment Rate with TLS Encrypted SIP . . . . 14 6.5. Session Establishment Rate with TLS-Encrypted SIP . . . . 14
6.6. Session Establishment Rate with IPsec Encrypted SIP . . . 15 6.6. Session Establishment Rate with IPsec-Encrypted SIP . . . 15
6.7. Registration Rate . . . . . . . . . . . . . . . . . . . . 15 6.7. Registration Rate . . . . . . . . . . . . . . . . . . . . 15
6.8. Re-Registration Rate . . . . . . . . . . . . . . . . . . . 16 6.8. Re-registration Rate . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 Appendix A. R Code Component to Simulate Benchmarking Algorithm 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 17 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix A. R Code Component to simulate benchmarking Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
algorithm . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, conforming to [RFC2119] and indicate requirement
levels for compliant implementations.
RFC 2119 defines the use of these key words to help make the intent
of standards track documents as clear as possible. While this
document uses these keywords, this document is not a standards track
document. The term Throughput is defined in [RFC2544].
Terms specific to SIP [RFC3261] performance benchmarking are defined
in [I-D.sip-bench-term].
2. Introduction 1. Introduction
This document describes the methodology for benchmarking Session This document describes the methodology for benchmarking Session
Initiation Protocol (SIP) performance as described in the Terminology Initiation Protocol (SIP) performance as described in the Terminology
document [I-D.sip-bench-term]. The methodology and terminology are document [RFC7501]. The methodology and terminology are to be used
to be used for benchmarking signaling plane performance with varying for benchmarking signaling plane performance with varying signaling
signaling and media load. Media streams, when used, are used only to and media load. Media streams, when used, are used only to study how
study how they impact the signaling behavior. This document they impact the signaling behavior. This document concentrates on
concentrates on benchmarking SIP session setup and SIP registrations benchmarking SIP session setup and SIP registrations only.
only.
The device-under-test (DUT) is a RFC3261-capable [RFC3261] network The Device Under Test (DUT) is a network intermediary that is RFC
intermediary that plays the role of a registrar, redirect server, 3261 [RFC3261] capable and that plays the role of a registrar,
stateful proxy, a Session Border Controller (SBC) or a B2BUA. This redirect server, stateful proxy, a Session Border Controller (SBC) or
document does not require the intermediary to assume the role of a a B2BUA. This document does not require the intermediary to assume
stateless proxy. Benchmarks can be obtained and compared for the role of a stateless proxy. Benchmarks can be obtained and
different types of devices such as a SIP proxy server, Session Border compared for different types of devices such as a SIP proxy server,
Controllers (SBC), SIP registrars and a SIP proxy server paired with Session Border Controllers (SBC), SIP registrars and a SIP proxy
a media relay. server paired with a media relay.
The test cases provide metrics for benchmarking the maximum 'SIP The test cases provide metrics for benchmarking the maximum 'SIP
Registration Rate' and maximum 'SIP Session Establishment Rate' that Registration Rate' and maximum 'SIP Session Establishment Rate' that
the DUT can sustain over an extended period of time without failures the DUT can sustain over an extended period of time without failures
(extended period of time is defined in the algorithm in (extended period of time is defined in the algorithm in
Section 4.10). Some cases are included to cover encrypted SIP. The Section 4.10). Some cases are included to cover encrypted SIP. The
test topologies that can be used are described in the Test Setup test topologies that can be used are described in the Test Setup
section. Topologies in which the DUT handles media as well as those section. Topologies in which the DUT handles media as well as those
in which the DUT does not handle media are both considered. The in which the DUT does not handle media are both considered. The
measurement of the performance characteristics of the media itself is measurement of the performance characteristics of the media itself is
skipping to change at page 5, line 21 skipping to change at page 5, line 5
Attempts. Attempts.
Finally, the overall value of these tests is to serve as a comparison Finally, the overall value of these tests is to serve as a comparison
function between multiple SIP implementations. One way to use these function between multiple SIP implementations. One way to use these
tests is to derive benchmarks with SIP devices from Vendor-A, derive tests is to derive benchmarks with SIP devices from Vendor-A, derive
a new set of benchmarks with similar SIP devices from Vendor-B and a new set of benchmarks with similar SIP devices from Vendor-B and
perform a comparison on the results of Vendor-A and Vendor-B. This perform a comparison on the results of Vendor-A and Vendor-B. This
document does not make any claims on the interpretation of such document does not make any claims on the interpretation of such
results. results.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, conforming to [RFC2119] and indicate requirement
levels for compliant implementations.
RFC 2119 defines the use of these key words to help make the intent
of Standards Track documents as clear as possible. While this
document uses these keywords, this document is not a Standards Track
document.
Terms specific to SIP [RFC3261] performance benchmarking are defined
in [RFC7501].
3. Benchmarking Topologies 3. Benchmarking Topologies
Test organizations need to be aware that these tests generate large Test organizations need to be aware that these tests generate large
volumes of data and consequently ensure that networking devices like volumes of data and consequently ensure that networking devices like
hubs, switches or routers are able to handle the generated volume. hubs, switches, or routers are able to handle the generated volume.
The test cases enumerated in Section 6.1 to Section 6.6 operate on The test cases enumerated in Sections 6.1 to 6.6 operate on two test
two test topologies: one in which the DUT does not process the media topologies: one in which the DUT does not process the media
(Figure 1) and the other in which it does process media (Figure 2). (Figure 1) and the other in which it does process media (Figure 2).
In both cases, the tester or emulated agent (EA) sends traffic into In both cases, the tester or Emulated Agent (EA) sends traffic into
the DUT and absorbs traffic from the DUT. The diagrams in Figure 1 the DUT and absorbs traffic from the DUT. The diagrams in Figures 1
and Figure 2 represent the logical flow of information and do not and 2 represent the logical flow of information and do not dictate a
dictate a particular physical arrangement of the entities. particular physical arrangement of the entities.
Figure 1 depicts a layout in which the DUT is an intermediary between Figure 1 depicts a layout in which the DUT is an intermediary between
the two interfaces of the EA. If the test case requires the exchange the two interfaces of the EA. If the test case requires the exchange
of media, the media does not flow through the DUT but rather passes of media, the media does not flow through the DUT but rather passes
directly between the two endpoints. Figure 2 shows the DUT as an directly between the two endpoints. Figure 2 shows the DUT as an
intermediary between the two interfaces of the EA. If the test case intermediary between the two interfaces of the EA. If the test case
requires the exchange of media, the media flows through the DUT requires the exchange of media, the media flows through the DUT
between the endpoints. between the endpoints.
+--------+ Session +--------+ Session +--------+ +--------+ Session +--------+ Session +--------+
skipping to change at page 6, line 18 skipping to change at page 6, line 18
| | | | | | | | | | | |
| | Response | | Response | | | | Response | | Response | |
| Tester +<------------| DUT +<------------| Tester | | Tester +<------------| DUT +<------------| Tester |
| (EA) | | | | (EA) | | (EA) | | | | (EA) |
| | | | | | | | | | | |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
/|\ /|\ /|\ /|\
| Media (optional) | | Media (optional) |
+==============================================+ +==============================================+
Figure 1: DUT as an intermediary, end-to-end media Figure 1: DUT as an Intermediary, End-to-End Media
+--------+ 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 +--------+
(Optional) (Optional) (Optional) (Optional)
Figure 2: DUT as an intermediary forwarding media Figure 2: DUT as an Intermediary Forwarding Media
The test cases enumerated in Section 6.7 and Section 6.8 use the The test cases enumerated in Sections 6.7 and 6.8 use the topology in
topology in Figure 3 below. Figure 3 below.
+--------+ Registration +--------+ +--------+ Registration +--------+
| | request | | | | request | |
| |------------->+ | | |------------->+ |
| | | | | | | |
| | Response | | | | Response | |
| Tester +<-------------| DUT | | Tester +<-------------| DUT |
| (EA) | | | | (EA) | | |
| | | | | | | |
+--------+ +--------+ +--------+ +--------+
Figure 3: Registration and Re-registration tests Figure 3: Registration and Re-registration Tests
During registration or re-registration, the DUT may involve backend During registration or re-registration, the DUT may involve backend
network elements and data stores. These network elements and data network elements and data stores. These network elements and data
stores are not shown in Figure 3, but it is understood that they will stores are not shown in Figure 3, but it is understood that they will
impact the time required for the DUT to generate a response. impact the time required for the DUT to generate a response.
This document explicitly separates a registration test (Section 6.7) This document explicitly separates a registration test (Section 6.7)
from a re-registration test (Section 6.8) because in certain from a re-registration test (Section 6.8) because in certain
networks, the time to re-register may vary from the time to perform networks, the time to re-register may vary from the time to perform
an initial registration due to the backend processing involved. It an initial registration due to the backend processing involved. It
is expected that the registration tests and the re-registration test is expected that the registration tests and the re-registration test
will be performed with the same set of backend network elements in will be performed with the same set of backend network elements in
order to derive a stable metric. order to derive a stable metric.
4. Test Setup Parameters 4. Test Setup Parameters
4.1. Selection of SIP Transport Protocol 4.1. Selection of SIP Transport Protocol
Test cases may be performed with any transport protocol supported by Test cases may be performed with any transport protocol supported by
SIP. This includes, but is not limited to, TCP, UDP, TLS and SIP. This includes, but is not limited to, TCP, UDP, TLS, and
websockets. The protocol used for the SIP transport protocol must be websockets. The protocol used for the SIP transport protocol must be
reported with benchmarking results. reported with benchmarking results.
SIP allows a DUT to use different transports for signaling on either SIP allows a DUT to use different transports for signaling on either
side of the connection to the EAs. Therefore, this document assumes side of the connection to the EAs. Therefore, this document assumes
that the same transport is used on both sides of the connection; if that the same transport is used on both sides of the connection; if
this is not the case in any of the tests, the transport on each side this is not the case in any of the tests, the transport on each side
of the connection MUST be reported in the test reporting template. of the connection MUST be reported in the test-reporting template.
4.2. Connection-oriented Transport Management 4.2. Connection-Oriented Transport Management
SIP allows a device to open one connection and send multiple requests SIP allows a device to open one connection and send multiple requests
over the same connection (responses are normally received over the over the same connection (responses are normally received over the
same connection that the request was sent out on). The protocol also same connection that the request was sent out on). The protocol also
allows a device to open a new connection for each individual request. allows a device to open a new connection for each individual request.
A connection management strategy will have an impact on the results A connection management strategy will have an impact on the results
obtained from the test cases, especially for connection-oriented obtained from the test cases, especially for connection-oriented
transports such as TLS. For such transports, the cryptographic transports such as TLS. For such transports, the cryptographic
handshake must occur every time a connection is opened. handshake must occur every time a connection is opened.
The connection management strategy, i.e., use of one connection to The connection management strategy, i.e., use of one connection to
send all requests or closing an existing connection and opening a new send all requests or closing an existing connection and opening a new
connection to send each request, MUST be reported with the connection to send each request, MUST be reported with the
benchmarking result. benchmarking result.
4.3. Signaling Server 4.3. Signaling Server
The Signaling Server is defined in the companion terminology The Signaling Server is defined in the companion terminology document
document, ([I-D.sip-bench-term], Section 3.2.2). The Signaling ([RFC7501], Section 3.2.2). The Signaling Server is a DUT.
Server is a DUT.
4.4. Associated Media 4.4. Associated Media
Some tests require Associated Media to be present for each SIP Some tests require Associated Media to be present for each SIP
session. The test topologies to be used when benchmarking DUT session. The test topologies to be used when benchmarking DUT
performance for Associated Media are shown in Figure 1 and Figure 2. performance for Associated Media are shown in Figure 1 and Figure 2.
4.5. Selection of Associated Media Protocol 4.5. Selection of Associated Media Protocol
The test cases specified in this document provide SIP performance The test cases specified in this document provide SIP performance
independent of the protocol used for the media stream. Any media independent of the protocol used for the media stream. Any media
protocol supported by SIP may be used. This includes, but is not protocol supported by SIP may be used. This includes, but is not
limited to, RTP, and SRTP. The protocol used for Associated Media limited to, RTP and SRTP. The protocol used for Associated Media
MUST be reported with benchmarking results. MUST be reported with benchmarking results.
4.6. Number of Associated Media Streams per SIP Session 4.6. Number of Associated Media Streams per SIP Session
Benchmarking results may vary with the number of media streams per Benchmarking results may vary with the number of media streams per
SIP session. When benchmarking a DUT for voice, a single media SIP session. When benchmarking a DUT for voice, a single media
stream is used. When benchmarking a DUT for voice and video, two stream is used. When benchmarking a DUT for voice and video, two
media streams are used. The number of Associated Media Streams MUST media streams are used. The number of Associated Media Streams MUST
be reported with benchmarking results. be reported with benchmarking results.
skipping to change at page 8, line 49 skipping to change at page 8, line 43
4.8. Session Duration 4.8. Session Duration
The value of the DUT's performance benchmarks may vary with the The value of the DUT's performance benchmarks may vary with the
duration of SIP sessions. Session Duration MUST be reported with duration of SIP sessions. Session Duration MUST be reported with
benchmarking results. A Session Duration of zero seconds indicates benchmarking results. A Session Duration of zero seconds indicates
transmission of a BYE immediately following a successful SIP transmission of a BYE immediately following a successful SIP
establishment. Setting this parameter to the value '0' indicates establishment. Setting this parameter to the value '0' indicates
that a BYE will be sent by the EA immediately after the EA receives a that a BYE will be sent by the EA immediately after the EA receives a
200 OK to the INVITE. Setting this parameter to a time value greater 200 OK to the INVITE. Setting this parameter to a time value greater
than the duration of the test indicates that a BYE is never sent. than the duration of the test indicates that a BYE will never be
sent. Setting this parameter to a time value greater than the
duration of the test indicates that a BYE is never sent.
4.9. Attempted Sessions per Second (sps) 4.9. Attempted Sessions per Second (sps)
The value of the DUT's performance benchmarks may vary with the The value of the DUT's performance benchmarks may vary with the
Session Attempt Rate offered by the tester. Session Attempt Rate Session Attempt Rate offered by the tester. Session Attempt Rate
MUST be reported with the benchmarking results. MUST be reported with the benchmarking results.
The test cases enumerated in Section 6.1 to Section 6.6 require that The test cases enumerated in Sections 6.1 to 6.6 require that the EA
the EA is configured to send the final 2xx-class response as quickly is configured to send the final 2xx-class response as quickly as it
as it can. This document does not require the tester to add any can. This document does not require the tester to add any delay
delay between receiving a request and generating a final response. between receiving a request and generating a final response.
4.10. Benchmarking algorithm 4.10. Benchmarking Algorithm
In order to benchmark the test cases uniformly in Section 6, the In order to benchmark the test cases uniformly in Section 6, the
algorithm described in this section should be used. A prosaic algorithm described in this section should be used. A prosaic
description of the algorithm and a pseudo-code description are description of the algorithm and a pseudocode description are
provided below, and a simulation written in the R statistical provided below, and a simulation written in the R statistical
language [Rtool] is provided in Appendix A. language [Rtool] is provided in Appendix A.
The goal is to find the largest value, R, a SIP Session Attempt Rate, The goal is to find the largest value, R, a SIP Session Attempt Rate,
measured in sessions-per-second (sps), which the DUT can process with measured in sessions per second (sps), which the DUT can process with
zero errors over a defined, extended period. This period is defined zero errors over a defined, extended period. This period is defined
as the amount of time needed to attempt N SIP sessions, where N is a as the amount of time needed to attempt N SIP sessions, where N is a
parameter of test, at the attempt rate, R. An iterative process is parameter of test, at the attempt rate, R. An iterative process is
used to find this rate. The algorithm corresponding to this process used to find this rate. The algorithm corresponding to this process
converges to R. converges to R.
If the DUT vendor provides a value for R, the tester can use this If the DUT vendor provides a value for R, the tester can use this
value. In cases where the DUT vendor does not provide a value for R, value. In cases where the DUT vendor does not provide a value for R,
or where the tester wants to establish the R of a system using local or where the tester wants to establish the R of a system using local
media characteristics, the algorithm should be run by setting "r", media characteristics, the algorithm should be run by setting "r",
the session attempt rate, equal to a value of the tester's choice. the session attempt rate, equal to a value of the tester's choice.
For example the tester may initialize "r = 100" to start the For example, the tester may initialize "r = 100" to start the
algorithm and observe the value at convergence. The algorithm algorithm and observe the value at convergence. The algorithm
dynamically increases and decreases "r" as it converges to the a dynamically increases and decreases "r" as it converges to the
maximum sps value for R. The dynamic increase and decrease rate is maximum sps value for R. The dynamic increase and decrease rate is
controlled by the weights "w" and "d", respectively. controlled by the weights "w" and "d", respectively.
The pseudo-code corresponding to the description above follows, and a The pseudocode corresponding to the description above follows, and a
simulation written in the R statistical language is provided in simulation written in the R statistical language is provided in
Appendix A. Appendix A.
; ---- Parameters of test, adjust as needed ; ---- Parameters of test; adjust as needed
N := 50000 ; Global maximum; once largest session rate has N := 50000 ; Global maximum; once largest session rate has
; been established, send this many requests before ; been established, send this many requests before
; calling the test a success ; calling the test a success
m := {...} ; Other attributes that affect testing, such m := {...} ; Other attributes that affect testing, such
; as media streams, etc. ; as media streams, etc.
r := 100 ; Initial session attempt rate (in sessions/sec). r := 100 ; Initial session attempt rate (in sessions/sec).
; Adjust as needed (for example, if DUT can handle ; Adjust as needed (for example, if DUT can handle
; thousands of calls in steady state, set to ; thousands of calls in steady state, set to
; appropriate value in the thousands). ; appropriate value in the thousands).
w := 0.10 ; Traffic increase weight (0 < w <= 1.0) w := 0.10 ; Traffic increase weight (0 < w <= 1.0)
skipping to change at page 10, line 36 skipping to change at page 10, line 42
; This function converges to R, the Session Attempt Rate. ; This function converges to R, the Session Attempt Rate.
proc max_sps(r, m, n) proc max_sps(r, m, n)
s := 0 ; session setup rate s := 0 ; session setup rate
old_r := 0 ; old session setup rate old_r := 0 ; old session setup rate
h := 0 ; Return value, R h := 0 ; Return value, R
count := 0 count := 0
; Note that if w is small (say, 0.10) and r is small ; Note that if w is small (say, 0.10) and r is small
; (say, <= 9), the algorithm will not converge since it ; (say, <= 9), the algorithm will not converge since it
; uses floor() to increment r dynamically. It is best ; uses floor() to increment r dynamically. It is best
; off to start with the defaults (w = 0.10 and ; to start with the defaults (w = 0.10 and r >= 100).
; r >= 100)
while (TRUE) { while (TRUE) {
s := send_traffic(r, m, n) ; Send r sps, with m media s := send_traffic(r, m, n) ; Send r sps, with m media
; characteristics until n sessions have been attempted. ; characteristics until n sessions have been attempted.
if (s == n) { if (s == n) {
if (r > old_r) { if (r > old_r) {
old_r = r old_r = r
} }
else { else {
count = count + 1 count = count + 1
if (count >= 10) { if (count >= 10) {
# We've converged. # We've converged.
h := max(r, old_r) h := max(r, old_r)
break break
}
} }
}
r := floor(r + (w * r)) r := floor(r + (w * r))
} }
else { else {
r := floor(r - (d * r)) r := floor(r - (d * r))
d := max(0.10, d / 2) d := max(0.10, d / 2)
w := max(0.10, w / 2) w := max(0.10, w / 2)
} }
} }
return h return h
end proc end proc
5. Reporting Format 5. Reporting Format
5.1. Test Setup Report 5.1. Test Setup Report
SIP Transport Protocol = ___________________________ SIP Transport Protocol = ___________________________
(valid values: TCP|UDP|TLS|SCTP|websockets|specify-other) (valid values: TCP|UDP|TLS|SCTP|websockets|specify-other)
(specify if same transport used for connections to the DUT (Specify if same transport used for connections to the DUT
and connections from the DUT. If different transports and connections from the DUT. If different transports
used on each connection, enumerate the transports used) used on each connection, enumerate the transports used.)
Connection management strategy for connection oriented Connection management strategy for connection oriented
transports transports
DUT receives requests on one connection = _______ DUT receives requests on one connection = _______
(Yes or no. If no, DUT accepts a new connection for (Yes or no. If no, DUT accepts a new connection for
every incoming request, sends a response on that every incoming request, sends a response on that
connection and closes the connection) connection, and closes the connection.)
DUT sends requests on one connection = __________ DUT sends requests on one connection = __________
(yes or no. If no, DUT initiates a new connection to (Yes or no. If no, DUT initiates a new connection to
send out each request, gets a response on that send out each request, gets a response on that
connection and closes the connection) connection, and closes the connection.)
Session Attempt Rate _______________________________ Session Attempt Rate _______________________________
(Session attempts/sec) (Session attempts/sec)
(The initial value for "r" in Benchmarking Algorithm of (The initial value for "r" in benchmarking algorithm in
Section 4.10) Section 4.10.)
Session Duration = _________________________________ Session Duration = _________________________________
(In seconds) (In seconds)
Total Sessions Attempted = _________________________ Total Sessions Attempted = _________________________
(Total sessions to be created over duration of test) (Total sessions to be created over duration of test)
Media Streams Per Session = _______________________ Media Streams per Session = _______________________
(number of streams per session) (number of streams per session)
Associated Media Protocol = _______________________ Associated Media Protocol = _______________________
(RTP|SRTP|specify-other) (RTP|SRTP|specify-other)
Codec = ____________________________________________ Codec = ____________________________________________
(Codec type as identified by the organization that (Codec type as identified by the organization that
specifies the codec) specifies the codec)
Media Packet Size (audio only) = __________________ Media Packet Size (audio only) = __________________
(Number of bytes in an audio packet) (Number of bytes in an audio packet)
Establishment Threshold time = ____________________ Establishment Threshold time = ____________________
(Seconds) (Seconds)
TLS ciphersuite used TLS ciphersuite used
(for tests involving TLS) = ________________________ (for tests involving TLS) = ________________________
(E.g., TLS_RSA_WITH_AES_128_CBC_SHA) (e.g., TLS_RSA_WITH_AES_128_CBC_SHA)
IPSec profile used IPsec profile used
(For tests involving IPSEC) = _____________________ (For tests involving IPsec) = _____________________
5.2. Device Benchmarks for session setup 5.2. Device Benchmarks for Session Setup
Session Establishment Rate, "R" = __________________ Session Establishment Rate, "R" = __________________
(sessions per second) (sessions per second)
Is DUT acting as a media relay (yes/no) = _________ Is DUT acting as a media relay? (yes/no) = _________
5.3. Device Benchmarks for registrations 5.3. Device Benchmarks for Registrations
Registration Rate = ____________________________ Registration Rate = ____________________________
(registrations per second) (registrations per second)
Re-registration Rate = ____________________________ Re-registration Rate = ____________________________
(registrations per second) (registrations per second)
Notes = ____________________________________________ Notes = ____________________________________________
(List any specific backend processing required or (List any specific backend processing required or
other parameters that may impact the rate) other parameters that may impact the rate)
6. Test Cases 6. Test Cases
6.1. Baseline Session Establishment Rate of the test bed 6.1. Baseline Session Establishment Rate of the Testbed
Objective: Objective:
To benchmark the Session Establishment Rate of the Emulated Agent To benchmark the Session Establishment Rate of the Emulated Agent
(EA) with zero failures. (EA) with zero failures.
Procedure: Procedure:
1. Configure the DUT in the test topology shown in Figure 1. 1. Configure the DUT in the test topology shown in Figure 1.
2. Set media streams per session to 0. 2. Set Media Streams per Session to 0.
3. Execute benchmarking algorithm as defined in Section 4.10 to 3. Execute benchmarking algorithm as defined in Section 4.10 to
get the baseline session establishment rate. This rate MUST get the baseline Session Establishment Rate. This rate MUST
be recorded using any pertinent parameters as shown in the be recorded using any pertinent parameters as shown in the
reporting format of Section 5.1. reporting format of Section 5.1.
Expected Results: This is the scenario to obtain the maximum Session Expected Results: This is the scenario to obtain the maximum Session
Establishment Rate of the EA and the test bed when no DUT is Establishment Rate of the EA and the testbed when no DUT is
present. The results of this test might be used to normalize test present. The results of this test might be used to normalize test
results performed on different test beds or simply to better results performed on different testbeds or simply to better
understand the impact of the DUT on the test bed in question. understand the impact of the DUT on the testbed in question.
6.2. Session Establishment Rate without media 6.2. Session Establishment Rate without Media
Objective: Objective:
To benchmark the Session Establishment Rate of the DUT with no To benchmark the Session Establishment Rate of the DUT with no
associated media and zero failures. Associated Media and zero failures.
Procedure: Procedure:
1. Configure a DUT according to the test topology shown in 1. Configure a DUT according to the test topology shown in
Figure 1 or Figure 2. Figure 1 or Figure 2.
2. Set media streams per session to 0. 2. Set Media Streams per Session to 0.
3. Execute benchmarking algorithm as defined in Section 4.10 to 3. Execute benchmarking algorithm as defined in Section 4.10 to
get the session establishment rate. This rate MUST be get the Session Establishment Rate. This rate MUST be
recorded using any pertinent parameters as shown in the recorded using any pertinent parameters as shown in the
reporting format of Section 5.1. reporting format of Section 5.1.
Expected Results: Find the Session Establishment Rate of the DUT Expected Results: Find the Session Establishment Rate of the DUT
when the EA is not sending media streams. when the EA is not sending media streams.
6.3. Session Establishment Rate with Media not on DUT 6.3. Session Establishment Rate with Media Not on DUT
Objective: Objective:
To benchmark the Session Establishment Rate of the DUT with zero To benchmark the Session Establishment Rate of the DUT with zero
failures when Associated Media is included in the benchmark test failures when Associated Media is included in the benchmark test
but the media is not running through the DUT. but the media is not running through the DUT.
Procedure: Procedure:
1. Configure a DUT according to the test topology shown in 1. Configure a DUT according to the test topology shown in
Figure 1. Figure 1.
2. Set media streams per session to 1. 2. Set Media Streams per Session to 1.
3. Execute benchmarking algorithm as defined in Section 4.10 to 3. Execute benchmarking algorithm as defined in Section 4.10 to
get the session establishment rate with media. This rate MUST get the session establishment rate with media. This rate MUST
be recorded using any pertinent parameters as shown in the be recorded using any pertinent parameters as shown in the
reporting format of Section 5.1. reporting format of Section 5.1.
Expected Results: Session Establishment Rate results obtained with Expected Results: Session Establishment Rate results obtained with
Associated Media with any number of media streams per SIP session Associated Media with any number of media streams per SIP session
are expected to be identical to the Session Establishment Rate are expected to be identical to the Session Establishment Rate
results obtained without media in the case where the DUT is results obtained without media in the case where the DUT is
running on a platform separate from the Media Relay. running on a platform separate from the Media Relay.
skipping to change at page 14, line 30 skipping to change at page 14, line 30
6.4. Session Establishment Rate with Media on DUT 6.4. Session Establishment Rate with Media on DUT
Objective: Objective:
To benchmark the Session Establishment Rate of the DUT with zero To benchmark the Session Establishment Rate of the DUT with zero
failures when Associated Media is included in the benchmark test failures when Associated Media is included in the benchmark test
and the media is running through the DUT. and the media is running through the DUT.
Procedure: Procedure:
1. Configure a DUT according to the test topology shown in 1. Configure a DUT according to the test topology shown in
Figure 2. Figure 2.
2. Set media streams per session to 1. 2. Set Media Streams per Session to 1.
3. Execute benchmarking algorithm as defined in Section 4.10 to 3. Execute benchmarking algorithm as defined in Section 4.10 to
get the session establishment rate with media. This rate MUST get the Session Establishment Rate with media. This rate MUST
be recorded using any pertinent parameters as shown in the be recorded using any pertinent parameters as shown in the
reporting format of Section 5.1. reporting format of Section 5.1.
Expected Results: Session Establishment Rate results obtained with Expected Results: Session Establishment Rate results obtained with
Associated Media may be lower than those obtained without media in Associated Media may be lower than those obtained without media in
the case where the DUT and the Media Relay are running on the same the case where the DUT and the Media Relay are running on the same
platform. It may be helpful for the tester to be aware of the platform. It may be helpful for the tester to be aware of the
reasons for this degradation, although these reasons are not reasons for this degradation, although these reasons are not
parameters of the test. For example, the degree of performance parameters of the test. For example, the degree of performance
degradation may be due to what the DUT does with the media (e.g., degradation may be due to what the DUT does with the media (e.g.,
relaying vs. transcoding), the type of media (audio vs. video vs. relaying vs. transcoding), the type of media (audio vs. video vs.
data), and the codec used for the media. There may also be cases data), and the codec used for the media. There may also be cases
where there is no performance impact, if the DUT has dedicated where there is no performance impact, if the DUT has dedicated
media-path hardware. media-path hardware.
6.5. Session Establishment Rate with TLS Encrypted SIP 6.5. Session Establishment Rate with TLS-Encrypted SIP
Objective: Objective:
To benchmark the Session Establishment Rate of the DUT with zero To benchmark the Session Establishment Rate of the DUT with zero
failures when using TLS encrypted SIP signaling. failures when using TLS-encrypted SIP signaling.
Procedure: Procedure:
1. If the DUT is being benchmarked as a proxy or B2BUA, then 1. If the DUT is being benchmarked as a proxy or B2BUA, then
configure the DUT in the test topology shown in Figure 1 or configure the DUT in the test topology shown in Figure 1 or
Figure 2. Figure 2.
2. Configure the tester to enable TLS over the transport being 2. Configure the tester to enable TLS over the transport being
used during benchmarking. Note the ciphersuite being used for used during benchmarking. Note the ciphersuite being used for
TLS and record it in Section 5.1. TLS and record it in Section 5.1.
3. Set media streams per session to 0 (media is not used in this 3. Set Media Streams per Session to 0 (media is not used in this
test). test).
4. Execute benchmarking algorithm as defined in Section 4.10 to 4. Execute benchmarking algorithm as defined in Section 4.10 to
get the session establishment rate with TLS encryption. get the Session Establishment Rate with TLS encryption.
Expected Results: Session Establishment Rate results obtained with Expected Results: Session Establishment Rate results obtained with
TLS Encrypted SIP may be lower than those obtained with plaintext TLS-encrypted SIP may be lower than those obtained with plaintext
SIP. SIP.
6.6. Session Establishment Rate with IPsec Encrypted SIP 6.6. Session Establishment Rate with IPsec-Encrypted SIP
Objective: Objective:
To benchmark the Session Establishment Rate of the DUT with zero To benchmark the Session Establishment Rate of the DUT with zero
failures when using IPsec Encrypted SIP signaling. failures when using IPsec-encrypted SIP signaling.
Procedure: Procedure:
1. Configure a DUT according to the test topology shown in 1. Configure a DUT according to the test topology shown in
Figure 1 or Figure 2. Figure 1 or Figure 2.
2. Set media streams per session to 0 (media is not used in this 2. Set Media Streams per Session to 0 (media is not used in this
test). test).
3. Configure tester for IPSec. Note the IPSec profile being used 3. Configure tester for IPsec. Note the IPsec profile being used
for and record it in Section 5.1. for IPsec and record it in Section 5.1.
4. Execute benchmarking algorithm as defined in Section 4.10 to 4. Execute benchmarking algorithm as defined in Section 4.10 to
get the session establishment rate with encryption. get the Session Establishment Rate with encryption.
Expected Results: Session Establishment Rate results obtained with Expected Results: Session Establishment Rate results obtained with
IPSec Encrypted SIP may be lower than those obtained with IPsec-encrypted SIP may be lower than those obtained with
plaintext SIP. plaintext SIP.
6.7. Registration Rate 6.7. Registration Rate
Objective: Objective:
To benchmark the maximum registration rate the DUT can handle over To benchmark the maximum registration rate the DUT can handle over
an extended time period with zero failures. an extended time period with zero failures.
Procedure: Procedure:
1. Configure a DUT according to the test topology shown in 1. Configure a DUT according to the test topology shown in
Figure 3. Figure 3.
2. Set the registration timeout value to at least 3600 seconds. 2. Set the registration timeout value to at least 3600 seconds.
3. Each register request MUST be made to a distinct address of 3. Each register request MUST be made to a distinct Address of
record (AoR). Execute benchmarking algorithm as defined in Record (AoR). Execute benchmarking algorithm as defined in
Section 4.10 to get the maximum registration rate. This rate Section 4.10 to get the maximum registration rate. This rate
MUST be recorded using any pertinent parameters as shown in MUST be recorded using any pertinent parameters as shown in
the reporting format of Section 5.1. For example, the use of the reporting format of Section 5.1. For example, the use of
TLS or IPSec during registration must be noted in the TLS or IPsec during registration must be noted in the
reporting format. In the same vein, any specific backend reporting format. In the same vein, any specific backend
processing (use of databases, authentication servers, etc.) processing (use of databases, authentication servers, etc.)
SHOULD be recorded as well. SHOULD be recorded as well.
Expected Results: Provides a maximum registration rate. Expected Results: Provides a maximum registration rate.
6.8. Re-Registration Rate 6.8. Re-registration Rate
Objective: Objective:
To benchmark the re-registration rate of the DUT with zero To benchmark the re-registration rate of the DUT with zero
failures using the same backend processing and parameters used failures using the same backend processing and parameters used
during Section 6.7. during Section 6.7.
Procedure: Procedure:
1. Configure a DUT according to the test topology shown in 1. Configure a DUT according to the test topology shown in
Figure 3. Figure 3.
2. First, execute test detailed in Section 6.7 to register the 2. Execute the test detailed in Section 6.7 to register the
endpoints with the registrar and obtain the registration rate. endpoints with the registrar and obtain the registration rate.
3. After at least 5 minutes of Step 2, but no more than 10 3. After at least 5 minutes of performing Step 2, but no more
minutes after Step 2 has been performed, re-register the same than 10 minutes after Step 2 has been performed, re-register
AoRs used in Step 3 of Section 6.7. This will count as a re- the same AoRs used in Step 3 of Section 6.7. This will count
registration because the SIP AoRs have not yet expired. as a re-registration because the SIP AoRs have not yet
expired.
Expected Results: Note the rate obtained through this test for Expected Results: Note the rate obtained through this test for
comparison with the rate obtained in Section 6.7. comparison with the rate obtained in Section 6.7.
7. IANA Considerations 7. Security Considerations
This document does not requires any IANA considerations.
8. Security Considerations
Documents of this type do not directly affect the security of Documents of this type do not directly affect the security of the
Internet or corporate networks as long as benchmarking is not Internet or corporate networks as long as benchmarking is not
performed on devices or systems connected to production networks. performed on devices or systems connected to production networks.
Security threats and how to counter these in SIP and the media layer Security threats and how to counter these in SIP and the media layer
is discussed in RFC3261, RFC3550, and RFC3711 and various other is discussed in RFC 3261, RFC 3550, and RFC 3711, and various other
drafts. This document attempts to formalize a set of common documents. This document attempts to formalize a set of common
methodology for benchmarking performance of SIP devices in a lab methodology for benchmarking performance of SIP devices in a lab
environment. environment.
9. Acknowledgments 8. References
The authors would like to thank Keith Drage and Daryl Malas for their
contributions to this document. Dale Worley provided an extensive
review that lead to improvements in the documents. We are grateful
to Barry Constantine, William Cerveny and Robert Sparks for providing
valuable comments during the document's last calls and expert
reviews. Al Morton and Sarah Banks have been exemplary working group
chairs, we thank them for tracking this work to completion. Tom
Taylor provided an in-depth review and subsequent comments on the
benchmarking convergence algorithm in Section 4.10.
10. References
10.1. Normative References 8.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,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999.
[I-D.sip-bench-term] [RFC7501] Davids, C., Gurbani, V., and S. Poretsky, "Terminology for
Davids, C., Gurbani, V., and S. Poretsky, "SIP Performance Benchmarking Session Initiation Protocol (SIP) Devices:
Benchmarking Terminology", Basic Session Setup and Registration", RFC 7501, April
draft-ietf-bmwg-sip-bench-term-12 (work in progress), 2015, <http://www.rfc-editor.org/info/rfc7501>.
November 2014.
10.2. Informative References 8.2. Informative References
[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, <http://www.rfc-editor.org/info/rfc3261>.
[Rtool] R Development Core Team, "R: A language and environment [Rtool] R Development Core Team, "R: A Language and Environment
for statistical computing. R Foundation for Statistical for Statistical Computing", R Foundation for Statistical
Computing, Vienna, Austria. ISBN 3-900051-07-0, URL Computing Vienna, Austria, ISBN 3-900051-07-0, 2011,
http://www.R-project.org/", , 2011. <http://www.R-project.org>.
Appendix A. R Code Component to simulate benchmarking algorithm Appendix A. R Code Component to Simulate Benchmarking Algorithm
# Copyright (c) 2014 IETF Trust and Vijay K. Gurbani. All # Copyright (c) 2015 IETF Trust and the persons identified as
# rights reserved. # authors of the code. All rights reserved.
# #
# Redistribution and use in source and binary forms, with # Redistribution and use in source and binary forms, with or
# or without modification, are permitted provided that the # without modification, are permitted provided that the following
# following conditions are met: # conditions are met:
# #
# * Redistributions of source code must retain the above # The author of this code is Vijay K. Gurbani.
# copyright notice, this list of conditions and the following #
# disclaimer. # - Redistributions of source code must retain the above copyright
# * Redistributions in binary form must reproduce the above # notice, this list of conditions and
# the following disclaimer.
#
# - Redistributions in binary form must reproduce the above
# copyright notice, this list of conditions and the following # copyright notice, this list of conditions and the following
# disclaimer in the documentation and/or other materials # disclaimer in the documentation and/or other materials
# provided with the distribution. # provided with the distribution.
# * Neither the name of Internet Society, IETF or IETF Trust, #
# nor the names of specific contributors, may be used # - Neither the name of Internet Society, IETF or IETF Trust,
# to endorse or promote products derived from this software # nor the names of specific contributors, may be used to
# endorse or promote products derived from this software
# without specific prior written permission. # without specific prior written permission.
# #
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
# CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, # CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
# INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF # INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE # MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
# DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR # DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
# CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, # CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, # INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR # (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
# SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS # GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, # INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
# WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING # WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
# NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE # NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
# USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
# OF SUCH DAMAGE. # DAMAGE.
w = 0.10 w = 0.10
d = max(0.10, w / 2) d = max(0.10, w / 2)
DUT_max_sps = 460 # Change as needed to set the max sps value DUT_max_sps = 460 # Change as needed to set the max sps value
# for a DUT # for a DUT
# Returns R, given r (initial session attempt rate). # Returns R, given r (initial session attempt rate).
# E.g., assume that a DUT handles 460 sps in steady state # E.g., assume that a DUT handles 460 sps in steady state
# and you have saved this code in a file simulate.r. Then, # and you have saved this code in a file simulate.r. Then,
# start an R session and do the following: # start an R session and do the following:
skipping to change at page 19, line 20 skipping to change at page 19, line 27
# do. # do.
find_R <- function(r) { find_R <- function(r) {
s = 0 s = 0
old_r = 0 old_r = 0
h = 0 h = 0
count = 0 count = 0
# Note that if w is small (say, 0.10) and r is small # Note that if w is small (say, 0.10) and r is small
# (say, <= 9), the algorithm will not converge since it # (say, <= 9), the algorithm will not converge since it
# uses floor() to increment r dynamically. It is best # uses floor() to increment r dynamically. It is best
# off to start with the defaults (w = 0.10 and # to start with the defaults (w = 0.10 and r >= 100).
# r >= 100)
cat("r old_r w d \n") cat("r old_r w d \n")
while (TRUE) { while (TRUE) {
cat(r, ' ', old_r, ' ', w, ' ', d, '\n') cat(r, ' ', old_r, ' ', w, ' ', d, '\n')
s = send_traffic(r) s = send_traffic(r)
if (s == TRUE) { # All sessions succeeded if (s == TRUE) { # All sessions succeeded
if (r > old_r) { if (r > old_r) {
old_r = r old_r = r
} }
skipping to change at page 20, line 17 skipping to change at page 20, line 24
send_traffic <- function(r) { send_traffic <- function(r) {
n = TRUE n = TRUE
if (r > DUT_max_sps) { if (r > DUT_max_sps) {
n = FALSE n = FALSE
} }
n n
} }
Acknowledgments
The authors would like to thank Keith Drage and Daryl Malas for their
contributions to this document. Dale Worley provided an extensive
review that led to improvements in the documents. We are grateful to
Barry Constantine, William Cerveny, and Robert Sparks for providing
valuable comments during the documents' last calls and expert
reviews. Al Morton and Sarah Banks have been exemplary working group
chairs; we thank them for tracking this work to completion. Tom
Taylor provided an in-depth review and subsequent comments on the
benchmarking convergence algorithm in Section 4.10.
Authors' Addresses Authors' Addresses
Carol Davids Carol Davids
Illinois Institute of Technology Illinois Institute of Technology
201 East Loop Road 201 East Loop Road
Wheaton, IL 60187 Wheaton, IL 60187
USA United States
Phone: +1 630 682 6024 Phone: +1 630 682 6024
Email: davids@iit.edu EMail: davids@iit.edu
Vijay K. Gurbani Vijay K. Gurbani
Bell Laboratories, Alcatel-Lucent Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane 1960 Lucent Lane
Rm 9C-533 Rm 9C-533
Naperville, IL 60566 Naperville, IL 60566
USA United States
Phone: +1 630 224 0216 Phone: +1 630 224 0216
Email: vkg@bell-labs.com EMail: vkg@bell-labs.com
Scott Poretsky Scott Poretsky
Allot Communications Allot Communications
300 TradeCenter, Suite 4680 300 TradeCenter, Suite 4680
Woburn, MA 08101 Woburn, MA 08101
USA United States
Phone: +1 508 309 2179 Phone: +1 508 309 2179
Email: sporetsky@allot.com EMail: sporetsky@allot.com
 End of changes. 112 change blocks. 
304 lines changed or deleted 295 lines changed or added

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