draft-ietf-rmcat-wireless-tests-10.txt   draft-ietf-rmcat-wireless-tests-11.txt 
Network Working Group Z. Sarker Network Working Group Z. Sarker
Internet-Draft Ericsson AB Internet-Draft Ericsson AB
Intended status: Informational X. Zhu Intended status: Informational X. Zhu
Expires: September 10, 2020 J. Fu Expires: September 14, 2020 J. Fu
W. Tan
Cisco Systems Cisco Systems
M. Ramalho March 13, 2020
AcousticComms
March 9, 2020
Evaluation Test Cases for Interactive Real-Time Media over Wireless Evaluation Test Cases for Interactive Real-Time Media over Wireless
Networks Networks
draft-ietf-rmcat-wireless-tests-10 draft-ietf-rmcat-wireless-tests-11
Abstract Abstract
The Real-time Transport Protocol (RTP) is a common transport choice The Real-time Transport Protocol (RTP) is a common transport choice
for interactive multimedia communication applications. The for interactive multimedia communication applications. The
performance of these applications typically depends on a well- performance of these applications typically depends on a well-
functioning congestion control algorithm. To ensure a seamless and functioning congestion control algorithm. To ensure a seamless and
robust user experience, a well-designed RTP-based congestion control robust user experience, a well-designed RTP-based congestion control
algorithm should work well across all access network types. This algorithm should work well across all access network types. This
document describes test cases for evaluating performances of document describes test cases for evaluating performances of
skipping to change at page 1, line 44 skipping to change at page 1, line 41
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 September 10, 2020. This Internet-Draft will expire on September 14, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 2, line 27 skipping to change at page 2, line 19
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Cellular Network Specific Test Cases . . . . . . . . . . . . 3 2. Cellular Network Specific Test Cases . . . . . . . . . . . . 3
2.1. Varying Network Load . . . . . . . . . . . . . . . . . . 6 2.1. Varying Network Load . . . . . . . . . . . . . . . . . . 6
2.1.1. Network Connection . . . . . . . . . . . . . . . . . 6 2.1.1. Network Connection . . . . . . . . . . . . . . . . . 6
2.1.2. Simulation Setup . . . . . . . . . . . . . . . . . . 7 2.1.2. Simulation Setup . . . . . . . . . . . . . . . . . . 7
2.1.3. Expected behavior . . . . . . . . . . . . . . . . . . 9
2.2. Bad Radio Coverage . . . . . . . . . . . . . . . . . . . 9 2.2. Bad Radio Coverage . . . . . . . . . . . . . . . . . . . 9
2.2.1. Network connection . . . . . . . . . . . . . . . . . 9 2.2.1. Network connection . . . . . . . . . . . . . . . . . 9
2.2.2. Simulation Setup . . . . . . . . . . . . . . . . . . 9 2.2.2. Simulation Setup . . . . . . . . . . . . . . . . . . 9
2.2.3. Expected behavior . . . . . . . . . . . . . . . . . . 10
2.3. Desired Evaluation Metrics for cellular test cases . . . 10 2.3. Desired Evaluation Metrics for cellular test cases . . . 10
3. Wi-Fi Networks Specific Test Cases . . . . . . . . . . . . . 10 3. Wi-Fi Networks Specific Test Cases . . . . . . . . . . . . . 10
3.1. Bottleneck in Wired Network . . . . . . . . . . . . . . . 12 3.1. Bottleneck in Wired Network . . . . . . . . . . . . . . . 12
3.1.1. Network topology . . . . . . . . . . . . . . . . . . 12 3.1.1. Network topology . . . . . . . . . . . . . . . . . . 12
3.1.2. Test setup . . . . . . . . . . . . . . . . . . . . . 13 3.1.2. Test/simulation setup . . . . . . . . . . . . . . . . 13
3.1.3. Typical test scenarios . . . . . . . . . . . . . . . 14 3.1.3. Typical test scenarios . . . . . . . . . . . . . . . 14
3.1.4. Expected behavior . . . . . . . . . . . . . . . . . . 15 3.1.4. Expected behavior . . . . . . . . . . . . . . . . . . 15
3.2. Bottleneck in Wi-Fi Network . . . . . . . . . . . . . . . 15 3.2. Bottleneck in Wi-Fi Network . . . . . . . . . . . . . . . 15
3.2.1. Network topology . . . . . . . . . . . . . . . . . . 15 3.2.1. Network topology . . . . . . . . . . . . . . . . . . 15
3.2.2. Test setup . . . . . . . . . . . . . . . . . . . . . 15 3.2.2. Test/simulation setup . . . . . . . . . . . . . . . . 16
3.2.3. Typical test scenarios . . . . . . . . . . . . . . . 17 3.2.3. Typical test scenarios . . . . . . . . . . . . . . . 17
3.2.4. Expected behavior . . . . . . . . . . . . . . . . . . 18 3.2.4. Expected behavior . . . . . . . . . . . . . . . . . . 18
3.3. Other Potential Test Cases . . . . . . . . . . . . . . . 19 3.3. Other Potential Test Cases . . . . . . . . . . . . . . . 19
3.3.1. EDCA/WMM usage . . . . . . . . . . . . . . . . . . . 19 3.3.1. EDCA/WMM usage . . . . . . . . . . . . . . . . . . . 19
3.3.2. Effect of heterogeneous link rates . . . . . . . . . 19 3.3.2. Effect of heterogeneous link rates . . . . . . . . . 19
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Wireless networks (both cellular and Wi-Fi [IEEE802.11]) are an Wireless networks (both cellular and Wi-Fi [IEEE802.11]) are an
integral and increasingly more significant part of the Internet. integral and increasingly more significant part of the Internet.
Typical application scenarios for interactive multimedia Typical application scenarios for interactive multimedia
communication over wireless include from video conferencing calls in communication over wireless include from video conferencing calls in
a bus or train as well as live media streaming at home. It is well a bus or train as well as live media streaming at home. It is well
known that the characteristics and technical challenges for known that the characteristics and technical challenges for
skipping to change at page 6, line 29 skipping to change at page 6, line 29
the network. This is to avoid running the evaluation in an empty the network. This is to avoid running the evaluation in an empty
network where network nodes are having empty buffers, low network where network nodes are having empty buffers, low
interference at the beginning of the simulation. This network interference at the beginning of the simulation. This network
initialization period should be excluded from the evaluation period. initialization period should be excluded from the evaluation period.
Typically, the evaluation period starts 30 seconds after test Typically, the evaluation period starts 30 seconds after test
initialization. initialization.
This test case also includes user mobility and some competing This test case also includes user mobility and some competing
traffic. The latter includes both the same types of flows (with same traffic. The latter includes both the same types of flows (with same
adaptation algorithms) and different types of flows (with different adaptation algorithms) and different types of flows (with different
services and congestion control schemes). The investigated services and congestion control schemes).
congestion control algorithms should show maximum possible network
utilization and stability in terms of rate variations, lowest
possible end to end frame latency, network latency and Packet Loss
Rate (PLR) at different cell load level.
2.1.1. Network Connection 2.1.1. Network Connection
Each mobile user is connected to a fixed user. The connection Each mobile user is connected to a fixed user. The connection
between the mobile user and fixed user consists of a cellular radio between the mobile user and fixed user consists of a cellular radio
access, an Evolved Packet Core (EPC) and an Internet connection. The access, an Evolved Packet Core (EPC) and an Internet connection. The
mobile user is connected to the EPC using cellular radio access mobile user is connected to the EPC using cellular radio access
technology which is further connected to the Internet. At the other technology which is further connected to the Internet. At the other
end, the fixed user is connected to the Internet via wired connection end, the fixed user is connected to the Internet via wired connection
with sufficiently high bandwidth, for instance, 10 Gbps, so that the with sufficiently high bandwidth, for instance, 10 Gbps, so that the
skipping to change at page 9, line 5 skipping to change at page 9, line 5
8. Other traffic models: 8. Other traffic models:
* Downlink simulation: Maximum of 4Mbps/cell (web browsing or * Downlink simulation: Maximum of 4Mbps/cell (web browsing or
FTP traffic following default TCP congestion control FTP traffic following default TCP congestion control
[RFC5681]) [RFC5681])
* Unlink simulation: Maximum of 2Mbps/cell (web browsing or FTP * Unlink simulation: Maximum of 2Mbps/cell (web browsing or FTP
traffic following default TCP congestion control [RFC5681]) traffic following default TCP congestion control [RFC5681])
2.1.3. Expected behavior
The investigated congestion control algorithms should result in
maximum possible network utilization and stability in terms of rate
variations, lowest possible end to end frame latency, network latency
and Packet Loss Rate (PLR) at different cell load levels.
2.2. Bad Radio Coverage 2.2. Bad Radio Coverage
The goal of this test is to evaluate the performance of candidate The goal of this test is to evaluate the performance of candidate
congestion control algorithm when users visit part of the network congestion control algorithm when users visit part of the network
with bad radio coverage. The scenario is created by using a larger with bad radio coverage. The scenario is created by using a larger
cell radius than that in the previous test case. In this test case, cell radius than that in the previous test case. In this test case,
each user/UE in the media session is an endpoint following RTP-based each user/UE in the media session is an endpoint following RTP-based
congestion control. User arrivals follow a Poisson distribution congestion control. User arrivals follow a Poisson distribution
proportional to the length of the call, to keep the number of users proportional to the length of the call, to keep the number of users
per cell fairly constant during the evaluation period. At the per cell fairly constant during the evaluation period. At the
beginning of the simulation, there should be enough amount of time to beginning of the simulation, there should be enough amount of time to
warm-up the network. This is to avoid running the evaluation in an warm-up the network. This is to avoid running the evaluation in an
empty network where network nodes are having empty buffers, low empty network where network nodes are having empty buffers, low
interference at the beginning of the simulation. This network interference at the beginning of the simulation. This network
initialization period should be excluded from the evaluation period. initialization period should be excluded from the evaluation period.
Typically, the evaluation period starts 30 seconds after test Typically, the evaluation period starts 30 seconds after test
initialization. initialization.
This test case also includes user mobility and some competing This test case also includes user mobility and some competing
traffic. The latter includes the same kind of flows (with same traffic. The latter includes the same kind of flows (with same
adaptation algorithms). The investigated congestion control adaptation algorithms).
algorithms should result in maximum possible network utilization and
stability in terms of rate variations, lowest possible end to end
frame latency, network latency and Packet Loss Rate (PLR) at
different cell load levels.
2.2.1. Network connection 2.2.1. Network connection
Same as defined in Section 2.1.1 Same as defined in Section 2.1.1
2.2.2. Simulation Setup 2.2.2. Simulation Setup
The desired simulation setup is the same as the Varying Network Load The desired simulation setup is the same as the Varying Network Load
test case defined in Section 2.1 except the following changes: test case defined in Section 2.1 except the following changes:
skipping to change at page 10, line 16 skipping to change at page 10, line 19
4. Other traffic models: 4. Other traffic models:
* Downlink simulation: Maximum of 2Mbps/cell (web browsing or * Downlink simulation: Maximum of 2Mbps/cell (web browsing or
FTP traffic following default TCP congestion control FTP traffic following default TCP congestion control
[RFC5681]) [RFC5681])
* Unlink simulation: Maximum of 1Mbps/cell (web browsing or FTP * Unlink simulation: Maximum of 1Mbps/cell (web browsing or FTP
traffic following default TCP congestion control [RFC5681]) traffic following default TCP congestion control [RFC5681])
2.2.3. Expected behavior
The investigated congestion control algorithms should result in
maximum possible network utilization and stability in terms of rate
variations, lowest possible end to end frame latency, network latency
and Packet Loss Rate (PLR) at different cell load levels.
2.3. Desired Evaluation Metrics for cellular test cases 2.3. Desired Evaluation Metrics for cellular test cases
The evaluation criteria document [I-D.ietf-rmcat-eval-criteria] The evaluation criteria document [I-D.ietf-rmcat-eval-criteria]
defines the metrics to be used to evaluate candidate algorithms. defines the metrics to be used to evaluate candidate algorithms.
Considering the nature and distinction of cellular networks we Considering the nature and distinction of cellular networks we
recommend that at least the following metrics be used to evaluate the recommend that at least the following metrics be used to evaluate the
performance of the candidate algorithms: performance of the candidate algorithms:
o Average cell throughput (for all cells), shows cell utilizations. o Average cell throughput (for all cells), shows cell utilizations.
skipping to change at page 13, line 31 skipping to change at page 13, line 36
. )) \\ . . )) \\ .
. )) \\ . . )) \\ .
+----------+ )) \\ +----------+ +----------+ )) \\ +----------+
| MN_tcp_M |))) \=====| FN_tcp_M | | MN_tcp_M |))) \=====| FN_tcp_M |
+----------+ +----------+ +----------+ +----------+
+<-----------------+ +<-----------------+
Downlink Downlink
Figure 2: Network topology for Wi-Fi test cases Figure 2: Network topology for Wi-Fi test cases
3.1.2. Test setup 3.1.2. Test/simulation setup
o Test duration: 120s o Test duration: 120s
o Wi-Fi network characteristics: o Wi-Fi network characteristics:
* Radio propagation model: Log-distance path loss propagation * Radio propagation model: Log-distance path loss propagation
model (see [NS3WiFi]) model (see [NS3WiFi])
* PHY- and MAC-layer configuration: IEEE 802.11n * PHY- and MAC-layer configuration: IEEE 802.11n
skipping to change at page 15, line 42 skipping to change at page 16, line 5
The test cases in this section assume that the wired segment along The test cases in this section assume that the wired segment along
the media path is well-provisioned whereas the bottleneck exists over the media path is well-provisioned whereas the bottleneck exists over
the Wi-Fi access network. This is to mimic the application scenarios the Wi-Fi access network. This is to mimic the application scenarios
typically encountered by users in an enterprise environment or at a typically encountered by users in an enterprise environment or at a
coffee house. coffee house.
3.2.1. Network topology 3.2.1. Network topology
Same as defined in Section 3.1.1 Same as defined in Section 3.1.1
3.2.2. Test setup 3.2.2. Test/simulation setup
o Test duration: 120s o Test duration: 120s
o Wi-Fi network characteristics: o Wi-Fi network characteristics:
* Radio propagation model: Log-distance path loss propagation * Radio propagation model: Log-distance path loss propagation
model (see [NS3WiFi]) model (see [NS3WiFi])
* PHY- and MAC-layer configuration: IEEE 802.11n * PHY- and MAC-layer configuration: IEEE 802.11n
* MCS Index at 11: 16-QAM 1/2, Raw Data Rate at 52Mbps * MCS Index at 11: 16-QAM 1/2, Raw Data Rate at 52Mbps
o Wired path characteristics: o Wired path characteristics:
* Path capacity: 100Mbps. * Path capacity: 100Mbps.
* One-Way propagation delay: 50ms. * One-Way propagation delay: 50ms.
* Maximum end-to-end jitter: 30ms. * Maximum end-to-end jitter: 30ms.
skipping to change at page 20, line 27 skipping to change at page 20, line 33
Given the difficulty of deterministic wireless testing, it is Given the difficulty of deterministic wireless testing, it is
recommended and expected that the tests described in this document recommended and expected that the tests described in this document
would be done via simulations. However, in the case where these test would be done via simulations. However, in the case where these test
cases are carried out in a testbed setting, the evaluation should cases are carried out in a testbed setting, the evaluation should
take place in a controlled lab environment. In the testbed, the take place in a controlled lab environment. In the testbed, the
applications, simulators and network nodes ought to be well-behaved applications, simulators and network nodes ought to be well-behaved
and should not impact the desired results. It is important to take and should not impact the desired results. It is important to take
appropriate caution to avoid leaking non-responsive traffic with appropriate caution to avoid leaking non-responsive traffic with
unproven congestion avoidance behavior onto the open Internet. unproven congestion avoidance behavior onto the open Internet.
6. Acknowledgments 6. Contributors
The authors would like to thank Ingemar Johansson for contributing to The following individuals contributed to the design, implementation,
the cellular test cases during the earlier stage of this draft. and verification of the proposed test cases during earlier stages of
this work. They have helped to validate and substantially improve
this specification.
Ingemar Johansson, <ingemar.s.johansson@ericsson.com> of Ericsson AB
contributing to the description and validation of cellular test cases
during the earlier stage of this draft.
Wei-Tian Tan, <dtan2@cisco.com>, of Cisco Systems designed and set up
a Wi-Fi testbed for evaluating parallel video conferencing streams,
based upon which proposed Wi-Fi test cases are described. He also
recommended additional test cases to consider, such as the impact of
EDCA/WMM usage.
Michael A. Ramalho, <mar42@cornell.edu> of AcousticComms Consulting
(previously at Cisco Systems) applied learnings from Cisco's internal
experimentation to the early versions of the draft. He also worked
on validating the proposed test cases in a VM-based lab setting.
7. Acknowledgments
The authors would like to thank Tomas Frankkila, Magnus Westerlund, The authors would like to thank Tomas Frankkila, Magnus Westerlund,
Kristofer Sandlund, Sergio Mena de la Cruz, and Mirja Kuehlewind for Kristofer Sandlund, Sergio Mena de la Cruz, and Mirja Kuehlewind for
their valuable inputs and review comments regarding this draft. their valuable inputs and review comments regarding this draft.
7. References 8. References
7.1. Normative References 8.1. Normative References
[HO-deploy-3GPP] [HO-deploy-3GPP]
TS 25.814, 3GPP., "Physical layer aspects for evolved TS 25.814, 3GPP., "Physical layer aspects for evolved
Universal Terrestrial Radio Access (UTRA)", October 2006, Universal Terrestrial Radio Access (UTRA)", October 2006,
<http://www.3gpp.org/ftp/specs/ <http://www.3gpp.org/ftp/specs/
archive/25_series/25.814/25814-710.zip>. archive/25_series/25.814/25814-710.zip>.
[I-D.ietf-rmcat-eval-criteria] [I-D.ietf-rmcat-eval-criteria]
Singh, V., Ott, J., and S. Holmer, "Evaluating Congestion Singh, V., Ott, J., and S. Holmer, "Evaluating Congestion
Control for Interactive Real-time Media", draft-ietf- Control for Interactive Real-time Media", draft-ietf-
rmcat-eval-criteria-11 (work in progress), February 2020. rmcat-eval-criteria-13 (work in progress), March 2020.
[I-D.ietf-rmcat-eval-test] [I-D.ietf-rmcat-eval-test]
Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test
Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat- Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat-
eval-test-10 (work in progress), May 2019. eval-test-10 (work in progress), May 2019.
[IEEE802.11] [IEEE802.11]
IEEE, "Standard for Information technology-- IEEE, "Standard for Information technology--
Telecommunications and information exchange between Telecommunications and information exchange between
systems Local and metropolitan area networks--Specific systems Local and metropolitan area networks--Specific
skipping to change at page 21, line 29 skipping to change at page 22, line 5
classns3_1_1_yans_wifi_channel.html>. classns3_1_1_yans_wifi_channel.html>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>. <https://www.rfc-editor.org/info/rfc5681>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References 8.2. Informative References
[Heusse2003] [Heusse2003]
Heusse, M., Rousseau, F., Berger-Sabbatel, G., and A. Heusse, M., Rousseau, F., Berger-Sabbatel, G., and A.
Duda, "Performance anomaly of 802.11b", in Proc. 23th Duda, "Performance anomaly of 802.11b", in Proc. 23th
Annual Joint Conference of the IEEE Computer and Annual Joint Conference of the IEEE Computer and
Communications Societies, (INFOCOM'03), March 2003. Communications Societies, (INFOCOM'03), March 2003.
[HO-def-3GPP] [HO-def-3GPP]
TR 21.905, 3GPP., "Vocabulary for 3GPP Specifications", TR 21.905, 3GPP., "Vocabulary for 3GPP Specifications",
December 2009, <http://www.3gpp.org/ftp/specs/ December 2009, <http://www.3gpp.org/ftp/specs/
skipping to change at page 23, line 4 skipping to change at line 1061
Email: xiaoqzhu@cisco.com Email: xiaoqzhu@cisco.com
Jiantao Fu Jiantao Fu
Cisco Systems Cisco Systems
771 Alder Drive 771 Alder Drive
Milpitas, CA 95035 Milpitas, CA 95035
USA USA
Email: jianfu@cisco.com Email: jianfu@cisco.com
Wei-Tian Tan
Cisco Systems
510 McCarthy Blvd
Milpitas, CA 95035
USA
Email: dtan2@cisco.com
Michael A. Ramalho
AcousticComms Consulting
6310 Watercrest Way Unit 203
Lakewood Ranch, FL 34202-5211
USA
Phone: +1 732 832 9723
Email: mar42@cornell.edu
 End of changes. 23 change blocks. 
32 lines changed or deleted 58 lines changed or added

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