draft-ietf-bmwg-sip-bench-meth-11.txt   draft-ietf-bmwg-sip-bench-meth-12.txt 
Benchmarking Methodology Working Group C. Davids Benchmarking Methodology Working Group C. Davids
Internet-Draft Illinois Institute of Technology Internet-Draft Illinois Institute of Technology
Intended status: Informational V. Gurbani Intended status: Informational V. Gurbani
Expires: January 3, 2015 Bell Laboratories, Expires: May 16, 2015 Bell Laboratories,
Alcatel-Lucent Alcatel-Lucent
S. Poretsky S. Poretsky
Allot Communications Allot Communications
July 2, 2014 November 12, 2014
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-11 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. Using these two documents, benchmarks can be
obtained and compared for different types of devices such as SIP obtained and compared for different types of devices such as SIP
Proxy Servers, Registrars and Session Border Controllers. The term Proxy Servers, Registrars and Session Border Controllers. The term
"performance" in this context means the capacity of the device-under- "performance" in this context means the capacity of the device-under-
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 January 3, 2015. This Internet-Draft will expire on May 16, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 23 skipping to change at page 3, line 23
4.3. Signaling Server . . . . . . . . . . . . . . . . . . . . . 8 4.3. Signaling Server . . . . . . . . . . . . . . . . . . . . . 8
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) . . . . . . . . . . . 9
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 . . . . . . . . . . . 13 5.2. Device Benchmarks for session setup . . . . . . . . . . . 12
5.3. Device Benchmarks for registrations . . . . . . . . . . . 13 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 test bed . . . 13
6.2. Session Establishment Rate without media . . . . . . . . . 14 6.2. Session Establishment Rate without media . . . . . . . . . 13
6.3. Session Establishment Rate with Media not on DUT . . . . . 14 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 . . . . 15 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 . . . . . . . . . . . . . . . . . . . . 16 6.7. Registration Rate . . . . . . . . . . . . . . . . . . . . 15
6.8. Re-Registration Rate . . . . . . . . . . . . . . . . . . . 16 6.8. Re-Registration Rate . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. R Code Component to simulate benchmarking Appendix A. R Code Component to simulate benchmarking
algorithm . . . . . . . . . . . . . . . . . . . . . . 18 algorithm . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Terminology 1. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, conforming to [RFC2119] and indicate requirement described in BCP 14, conforming to [RFC2119] and indicate requirement
skipping to change at page 5, line 30 skipping to change at page 5, line 30
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 Section 6.1 to Section 6.6 operate on
two test topologies: one in which the DUT does not process the media two test 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 EA sends traffic into the DUT and In both cases, the tester or emulated agent (EA) sends traffic into
absorbs traffic from the DUT. The diagrams in Figure 1 and Figure 2 the DUT and absorbs traffic from the DUT. The diagrams in Figure 1
represent the logical flow of information and do not dictate a and Figure 2 represent the logical flow of information and do not
particular physical arrangements of the entities. dictate a 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 9, line 33 skipping to change at page 9, line 33
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. Alternatively, in cases where the DUT vendor does not provide value. In cases where the DUT vendor does not provide a value for R,
a value for R, or in cases where the tester wants to ascertain a or where the tester wants to establish the R of a system using local
vendor provided value using local media characteristics, the media characteristics, the algorithm should be run by setting "r",
algorithm could be run by setting "r = R" and observing the value at the session attempt rate, equal to a value of the tester's choice.
convergence. For example the tester may initialize "r = 100" to start the
algorithm and observe the value at convergence. The algorithm
The algorithm proceeds by initializing "r = 100"; "r" is the session dynamically increases and decreases "r" as it converges to the a
attempt rate. The algorithm dynamically increases and decreases "r" maximum sps value for R. The dynamic increase and decrease rate is
as it converges to the a maximum sps value for R. The dynamic controlled by the weights "w" and "d", respectively.
increase and decrease rate is controlled by the weights "w" and "d",
respectively. If the DUT vendor provides a value for R, the tester
can use that value; however, because the requirements and media
characteristics are a function of the test environment, it is best
that the tester reflect these requirements during testing and allow
the algorithm to converge to R.
The pseudo-code corresponding to the description above follows, and a The pseudo-code 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
skipping to change at page 10, line 23 skipping to change at page 10, line 17
; 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)
d := max(0.10, w / 2) ; Traffic decrease weight d := max(0.10, w / 2) ; Traffic decrease weight
; ---- End of parameters of test ; ---- End of parameters of test
proc find_R proc find_R
R = max_sps(r, m, N) ; Setup r sps, each with m media R = max_sps(r, m, N) ; Setup r sps, each with m media
; characteristics until N sessions have been set up. ; characteristics until N sessions have been attempted.
; Note that if a DUT vendor provides this number, the tester ; Note that if a DUT vendor provides this number, the tester
; can use the number as a Session Attempt Rate, R, instead ; can use the number as a Session Attempt Rate, R, instead
; of invoking max_sps() ; of invoking max_sps()
end proc end proc
; Iterative process to figure out the largest number of ; Iterative process to figure out the largest number of
; sps that we can achieve in order to setup n sessions. ; sps that we can achieve in order to setup n sessions.
; 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 ; off to start with the defaults (w = 0.10 and
; r >= 10) ; 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 established. ; 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
skipping to change at page 12, line 4 skipping to change at page 11, line 23
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
Section 4.10)
Session Duration = _________________________________
(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 = ______________________ 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)
skipping to change at page 15, line 17 skipping to change at page 14, line 39
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. platform. It may be helpful for the tester to be aware of the
reasons for this degradation, although these reasons are not
parameters of the test. For example, the degree of performance
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.
data), and the codec used for the media. There may also be cases
where there is no performance impact, if the DUT has dedicated
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
skipping to change at page 17, line 31 skipping to change at page 17, line 18
methodology for benchmarking performance of SIP devices in a lab methodology for benchmarking performance of SIP devices in a lab
environment. environment.
9. Acknowledgments 9. Acknowledgments
The authors would like to thank Keith Drage and Daryl Malas for their The authors would like to thank Keith Drage and Daryl Malas for their
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. We are grateful review that lead to improvements in the documents. We are grateful
to Barry Constantine, William Cerveny and Robert Sparks for providing to Barry Constantine, William Cerveny and Robert Sparks for providing
valuable comments during the document's last calls and expert valuable comments during the document's last calls and expert
reviews. 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. References
10.1. Normative References 10.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.
[I-D.sip-bench-term] [I-D.sip-bench-term]
Davids, C., Gurbani, V., and S. Poretsky, "SIP Performance Davids, C., Gurbani, V., and S. Poretsky, "SIP Performance
Benchmarking Terminology", Benchmarking Terminology",
draft-ietf-bmwg-sip-bench-term-10 (work in progress), draft-ietf-bmwg-sip-bench-term-12 (work in progress),
May 2014. November 2014.
10.2. Informative References 10.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.
[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
skipping to change at page 19, line 34 skipping to change at page 19, line 21
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 # off to start with the defaults (w = 0.10 and
# r >= 10) # 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
} }
 End of changes. 29 change blocks. 
49 lines changed or deleted 57 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/