draft-ietf-rmcat-wireless-tests-00.txt | draft-ietf-rmcat-wireless-tests-01.txt | |||
---|---|---|---|---|
Network Working Group Z. Sarker | Network Working Group Z. Sarker | |||
Internet-Draft I. Johansson | Internet-Draft I. Johansson | |||
Intended status: Informational Ericsson AB | Intended status: Informational Ericsson AB | |||
Expires: December 13, 2015 June 11, 2015 | Expires: May 8, 2016 X. Zhu | |||
J. Fu | ||||
W. Tan | ||||
M. Ramalho | ||||
Cisco Systems | ||||
November 5, 2015 | ||||
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-00 | draft-ietf-rmcat-wireless-tests-01 | |||
Abstract | Abstract | |||
It is evident that to ensure seamless and robust user experience | It is evident that to ensure seamless and robust user experience | |||
across all type of access networks multimedia communication suits | across all type of access networks multimedia communication suits | |||
should adapt to the changing network conditions. There is an ongoing | should adapt to the changing network conditions. There is an ongoing | |||
effort in IETF RMCAT working group to standardize rate adaptive | effort in IETF RMCAT working group to standardize rate adaptive | |||
algorithm(s) to be used in the real-time interactive communication. | algorithm(s) to be used in the real-time interactive communication. | |||
In this document test cases are described to evaluate the | In this document test cases are described to evaluate the | |||
performances of the proposed endpoint adaptation solutions in LTE | performances of the proposed endpoint adaptation solutions in LTE | |||
networks and Wi-Fi networks. It is aimed that the proposed solutions | networks and Wi-Fi networks. The proposed algorithms should be | |||
should be evaluated using the test cases defined in this document to | evaluated using the test cases defined in this document to select | |||
select most optimal solutions. | most optimal solutions. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 December 13, 2015. | This Internet-Draft will expire on May 8, 2016. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Cellular Network Specific Test Cases . . . . . . . . . . . . 3 | 3. Cellular Network Specific Test Cases . . . . . . . . . . . . 3 | |||
3.1. Varying Network Load . . . . . . . . . . . . . . . . . . 5 | 3.1. Varying Network Load . . . . . . . . . . . . . . . . . . 6 | |||
3.1.1. Network Connection . . . . . . . . . . . . . . . . . 6 | 3.1.1. Network Connection . . . . . . . . . . . . . . . . . 6 | |||
3.1.2. Simulation Setup . . . . . . . . . . . . . . . . . . 6 | 3.1.2. Simulation Setup . . . . . . . . . . . . . . . . . . 7 | |||
3.2. Bad Radio Coverage . . . . . . . . . . . . . . . . . . . 8 | 3.2. Bad Radio Coverage . . . . . . . . . . . . . . . . . . . 8 | |||
3.2.1. Network connection . . . . . . . . . . . . . . . . . 8 | 3.2.1. Network connection . . . . . . . . . . . . . . . . . 9 | |||
3.2.2. Simulation Setup . . . . . . . . . . . . . . . . . . 8 | 3.2.2. Simulation Setup . . . . . . . . . . . . . . . . . . 9 | |||
3.3. Desired Evaluation Metrics for cellular test cases . . . 9 | 3.3. Desired Evaluation Metrics for cellular test cases . . . 10 | |||
4. Wi-Fi Networks Specific Test Cases . . . . . . . . . . . . . 9 | 4. Wi-Fi Networks Specific Test Cases . . . . . . . . . . . . . 10 | |||
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 4.1. Bottleneck in Wired Network . . . . . . . . . . . . . . . 12 | |||
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | 4.1.1. Network topology . . . . . . . . . . . . . . . . . . 12 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 4.1.2. Test setup . . . . . . . . . . . . . . . . . . . . . 13 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 4.1.3. Typical test scenarios . . . . . . . . . . . . . . . 14 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 4.1.4. Expected behavior . . . . . . . . . . . . . . . . . . 14 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 | 4.2. Bottleneck in Wi-Fi Network . . . . . . . . . . . . . . . 14 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 11 | 4.2.1. Network topology . . . . . . . . . . . . . . . . . . 15 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | 4.2.2. Test setup . . . . . . . . . . . . . . . . . . . . . 15 | |||
4.2.3. Typical test scenarios . . . . . . . . . . . . . . . 16 | ||||
4.2.4. Expected behavior . . . . . . . . . . . . . . . . . . 17 | ||||
4.3. Potential Potential Test Cases . . . . . . . . . . . . . 17 | ||||
4.3.1. EDCA/WMM usage . . . . . . . . . . . . . . . . . . . 17 | ||||
4.3.2. Legacy 802.11b Effects . . . . . . . . . . . . . . . 17 | ||||
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 18 | ||||
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 | ||||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 | ||||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 | ||||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 | ||||
9.1. Normative References . . . . . . . . . . . . . . . . . . 18 | ||||
9.2. Informative References . . . . . . . . . . . . . . . . . 19 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 | ||||
1. Introduction | 1. Introduction | |||
Wireless networks (both cellular and Wi-Fi [IEEE802.11] local area | Wireless networks (both cellular and Wi-Fi [IEEE802.11] local area | |||
network) are an integral part of the Internet. Mobile devices | network) are an integral part of the Internet. Mobile devices | |||
connected to the wireless networks produces huge amount of media | connected to the wireless networks produces huge amount of media | |||
traffic in the Internet. They covers the scenarios of having a video | traffic in the Internet. They covers the scenarios of having a video | |||
call in the bus to media consumption sitting on a couch in a living | call in the bus to media consumption sitting on a couch in a living | |||
room. It is a well known fact that the characteristic and challenges | room. It is a well known fact that the characteristic and challenges | |||
for offering service over wireless network are very different than | for offering service over wireless network are very different than | |||
skipping to change at page 3, line 12 | skipping to change at page 3, line 33 | |||
mobility in a cellular network is different than the user mobility in | mobility in a cellular network is different than the user mobility in | |||
a Wi-Fi network. Thus, It is important to evaluate the performance | a Wi-Fi network. Thus, It is important to evaluate the performance | |||
of the proposed RMCAT candidates separately in the cellular mobile | of the proposed RMCAT candidates separately in the cellular mobile | |||
networks and Wi-Fi local networks (IEEE 802.11xx protocol family ). | networks and Wi-Fi local networks (IEEE 802.11xx protocol family ). | |||
RMCAT evaluation criteria [I-D.ietf-rmcat-eval-criteria] document | RMCAT evaluation criteria [I-D.ietf-rmcat-eval-criteria] document | |||
provides the guideline to perform the evaluation on candidate | provides the guideline to perform the evaluation on candidate | |||
algorithms and recognizes wireless networks to be important access | algorithms and recognizes wireless networks to be important access | |||
link. However, it does not provides particular test cases to | link. However, it does not provides particular test cases to | |||
evaluate the performance of the candidate algorithm. In this | evaluate the performance of the candidate algorithm. In this | |||
document we device test cases specifically targeting cellular | document we describe test cases specifically targeting cellular | |||
networks such as LTE networks and Wi-Fi local networks. | networks such as LTE networks and Wi-Fi local networks. | |||
2. Terminologies | 2. Terminologies | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC2119 [RFC2119] | document are to be interpreted as described in RFC2119 [RFC2119] | |||
3. Cellular Network Specific Test Cases | 3. Cellular Network Specific Test Cases | |||
skipping to change at page 6, line 25 | skipping to change at page 7, line 5 | |||
(practically infinite bandwidth). The Internet and wired connection | (practically infinite bandwidth). The Internet and wired connection | |||
in this setup does not add any network impairments to the test, it | in this setup does not add any network impairments to the test, it | |||
only adds 10ms of one-way transport propagation delay. | only adds 10ms of one-way transport propagation delay. | |||
The path from the fixed user to mobile user is defines as "Downlink" | The path from the fixed user to mobile user is defines as "Downlink" | |||
and the path from mobile user to the fixed user is defined as | and the path from mobile user to the fixed user is defined as | |||
"Uplink". We assume that only uplink or downlink is congested for | "Uplink". We assume that only uplink or downlink is congested for | |||
the mobile users. Hence, we recommend that the uplink and downlink | the mobile users. Hence, we recommend that the uplink and downlink | |||
simulations are run separately. | simulations are run separately. | |||
uplink | uplink | |||
++))) +--------------------------> | ++))) +--------------------------> | |||
++-+ ((o)) | ++-+ ((o)) | |||
| | / \ +-------+ +------+ +---+ | | | / \ +-------+ +------+ +---+ | |||
+--+ / \----+ +-----+ +----+ | | +--+ / \----+ +-----+ +----+ | | |||
/ \ +-------+ +------+ +---+ | / \ +-------+ +------+ +---+ | |||
UE BS EPC Internet fixed | UE BS EPC Internet fixed | |||
<--------------------------+ | <--------------------------+ | |||
downlink | downlink | |||
Figure 1: Simulation Topology | Figure 1: Simulation Topology | |||
skipping to change at page 9, line 46 | skipping to change at page 10, line 31 | |||
o End to end Media frame delay. For video, this means the delay | o End to end Media frame delay. For video, this means the delay | |||
from capture to display. | from capture to display. | |||
o Transport delay. | o Transport delay. | |||
o Algorithm stability in terms of rate variation. | o Algorithm stability in terms of rate variation. | |||
4. Wi-Fi Networks Specific Test Cases | 4. Wi-Fi Networks Specific Test Cases | |||
TBD | Given the prevalence of Internet access links over Wi-Fi, it is | |||
important to evaluate candidate RMCAT congestion control solutions | ||||
over Wi-Fi test cases. Such evaluations should also highlight the | ||||
inherent different characteristics of Wi-Fi networks in contrast to | ||||
Wired networks: | ||||
o The wireless radio channel is subject to interference from nearby | ||||
transmitters, multi-path fading, and shadowing, causing | ||||
fluctuations in link throughput and sometimes an error-prone | ||||
communication environment | ||||
o Available network bandwidth is not only shared over the air | ||||
between concurrent users, but also between uplink and downlink | ||||
traffic due to the half duplex nature of wireless transmission | ||||
medium. | ||||
o Packet transmissions over Wi-Fi are susceptible to contentions and | ||||
collisions over the air. Consequently, traffic load beyond a | ||||
certain utilization level over a Wi-Fi network can introduce | ||||
frequent collisions and significant network overhead. This, in | ||||
turn, leads to excessive delay, retransmission, loss and lower | ||||
effective bandwidth for applications. | ||||
o The IEEE 802.11 standard (i.e., Wi-Fi) supports multi-rate | ||||
transmission capabilities by dynamically choosing the most | ||||
appropriate modulation scheme for a given received signal | ||||
strength. A different choice of Physical-layer rate will lead to | ||||
different application-layer throughput. | ||||
o Presence of legacy 802.11b networks can significantly slow down | ||||
the rest of a modern Wi-Fi Network, since it takes longer to | ||||
transmit the same packet over a slower link than over a faster | ||||
link. [Editor's note: maybe include a reference here instead.] | ||||
o Handover from one Wi-Fi Access Point (AP) to another may cause | ||||
packet delay and loss. | ||||
o IEEE 802.11e defined EDCA/WMM (Enhanced DCF Channel Access/Wi-Fi | ||||
Multi-Media) to give voice and video streams higher priority over | ||||
pure data applications (e.g., file transfers). | ||||
As we can see here, presence of Wi-Fi network in different network | ||||
topologies and traffic arrival can exert different impact on the | ||||
network performance in terms of video transport rate, packet loss and | ||||
delay that, in turn, effect end-to-end real-time multimedia | ||||
congestion control. | ||||
Throughout this draft, unless otherwise mentioned, test cases are | ||||
described using 802.11g due to its wide availability in network | ||||
simulation platform. In practice, however, statistics collected from | ||||
enterprise networks show that the dominant physical modes are 802.11n | ||||
and 802.11ac, accounting for 73.6% and 22.5% of enterprise network | ||||
users, respectively. Whenever possible, it is recommended to extend | ||||
some of the experiments to 802.11n and 802.11ac, so as to reflect a | ||||
more modern Wi-Fi network setting. | ||||
Since Wi-Fi network normally connects to a wired infrastructure, | ||||
either the wired network or the Wi-Fi network could be the | ||||
bottleneck. In the following section, we describe basic test cases | ||||
for both scenarios separately. The same set of performance metrics | ||||
as in [I-D.ietf-rmcat-eval-test]) should be collected for each test | ||||
case. | ||||
While all test cases described below can be carried out using | ||||
simulations, e.g. based on [ns-2] or [ns-3], it is also recommended | ||||
to perform testbed-based evaluations using Wi-Fi access points and | ||||
endpoints running up-to-date IEEE 802.11 protocols. [Editor's Note: | ||||
need to add some more discussions on the pros and cons of simulation- | ||||
based vs. testbed-based evaluations. It will be good to provide | ||||
recommended testbed configurations. ] | ||||
4.1. Bottleneck in Wired Network | ||||
The test scenarios below are intended to mimic the set up of video | ||||
conferencing over Wi-Fi connections from the home. Typically, the | ||||
Wi-Fi home network is not congested and the bottleneck is present | ||||
over the wired home access link. Although it is expected that test | ||||
evaluation results from this section are similar to those from test | ||||
cases defined for wired networks (see [I-D.ietf-rmcat-eval-test]), it | ||||
is worthwhile to run through these tests as sanity checks. | ||||
4.1.1. Network topology | ||||
Figure 2 shows topology of the network for Wi-Fi test cases. The | ||||
test contains multiple mobile nodes (MNs) connected to a common Wi-Fi | ||||
access point (AP) and their corresponding wired clients on fixed | ||||
nodes (FNs). Each connection carries either RMCAT or TCP traffic | ||||
flow. Directions of the flows can be uplink, downlink, or bi- | ||||
directional. | ||||
uplink | ||||
+----------------->+ | ||||
+------+ +------+ | ||||
| MN_1 |)))) /=====| FN_1 | | ||||
+------+ )) // +------+ | ||||
. )) // . | ||||
. )) // . | ||||
. )) // . | ||||
+------+ +----+ +-----+ +------+ | ||||
| MN_N | ))))))) | | | |========| FN_N | | ||||
+------+ | | | | +------+ | ||||
| AP |=========| FN0 | | ||||
+----------+ | | | | +----------+ | ||||
| MN_tcp_1 | )))) | | | |======| MN_tcp_1 | | ||||
+----------+ +----+ +-----+ +----------+ | ||||
. )) \\ . | ||||
. )) \\ . | ||||
. )) \\ . | ||||
+----------+ )) \\ +----------+ | ||||
| MN_tcp_M |))) \=====| MN_tcp_M | | ||||
+----------+ +----------+ | ||||
+<-----------------+ | ||||
downlink | ||||
Figure 2: Network topology for Wi-Fi test cases | ||||
4.1.2. Test setup | ||||
o Test duration: 120s | ||||
o Wi-Fi network characteristics: | ||||
* Radio propagation model: Log-distance path loss propagation | ||||
model [NS3WiFi] | ||||
* PHY- and MAC-layer configuration: IEEE 802.11g | ||||
* PHY-layer link rate: 54 Mbps | ||||
o Wired path characteristics: | ||||
* Path capacity: 1Mbps | ||||
* One-Way propagation delay: 50ms. | ||||
* Maximum end-to-end jitter: 30ms | ||||
* Bottleneck queue type: Drop tail. | ||||
* Bottleneck queue size: 300ms. | ||||
* Path loss ratio: 0%. | ||||
o Application characteristics: | ||||
* Media Traffic: | ||||
+ Media type: Video | ||||
+ Media direction: See Section 4.1.3 | ||||
+ Number of media sources (N): See Section 4.1.3 | ||||
+ Media timeline: | ||||
- Start time: 0s. | ||||
- End time: 119s. | ||||
* Competing traffic: | ||||
+ Type of sources: long-lived TCP | ||||
+ Traffic direction: See Section 4.1.3 | ||||
+ Number of sources (M): See Section 4.1.3 | ||||
+ Congestion control: Default TCP congestion control [TBD] | ||||
+ Traffic timeline: | ||||
- Start time: 0s | ||||
- End time: 119s | ||||
4.1.3. Typical test scenarios | ||||
o Single uplink RMCAT flow: N=1 with uplink direction and M=0. | ||||
o One pair of bi-directional RMCAT flows: N=2 (with one uplink flow | ||||
and one downlink flow); M=0. | ||||
o One RMCAT flow competing against one long-live TCP flow over | ||||
uplink: N=1 (uplink) and M = 1(uplink). | ||||
4.1.4. Expected behavior | ||||
o Single uplink RMCAT flow: the candidate algorithm is expected to | ||||
detect the path capacity constraint, converges to bottleneck | ||||
link's capacity and adapt the flow to avoid unwanted oscillation | ||||
when the sending bit rate is approaching the bottleneck link's | ||||
capacity. No excessive rate oscillations. | ||||
o Bi-directional RMCAT flows: It is expected that the candidate | ||||
algorithms is able to converge to the bottleneck capacity of the | ||||
wired path on both directions despite of the presence of | ||||
measurement noise over the Wi-Fi connection. | ||||
o One RMCAT flow competing with long-live TCP flow over uplink: the | ||||
candidate algorithm should be able to avoid congestion collapse, | ||||
and stabilize at a fair share of the bottleneck capacity over the | ||||
wired path. | ||||
4.2. Bottleneck in Wi-Fi Network | ||||
These test cases assume that the wired portion along the media path | ||||
are well-provisioned. The bottleneck is in the Wi-Fi network over | ||||
wireless. This is to mimic the enterprise/coffee-house scenarios. | ||||
4.2.1. Network topology | ||||
Same as defined in Section 4.1.1 | ||||
4.2.2. Test setup | ||||
o Test duration: 120s | ||||
o Wi-Fi network characteristics: | ||||
* Radio propagation model: Log-distance path loss propagation | ||||
model [NS3WiFi] | ||||
* PHY- and MAC-layer configuration: IEEE 802.11g | ||||
* PHY-layer link rate: 54 Mbps | ||||
o Wired path characteristics: | ||||
* Path capacity: 100Mbps | ||||
* One-Way propagation delay: 50ms. | ||||
* Maximum end-to-end jitter: 30ms | ||||
* Bottleneck queue type: Drop tail. | ||||
* Bottleneck queue size: 300ms. | ||||
* Path loss ratio: 0%. | ||||
o Application characteristics: | ||||
* Media Traffic: | ||||
+ Media type: Video | ||||
+ Media direction: See Section 4.2.3 | ||||
+ Number of media sources (N): See Section 4.2.3 | ||||
+ Media timeline: | ||||
- Start time: 0s. | ||||
- End time: 119s. | ||||
* Competing traffic: | ||||
+ Type of sources: long-lived TCP | ||||
+ Number of sources (M): See Section 4.2.3 | ||||
+ Traffic direction: See Section 4.2.3 | ||||
+ Congestion control: Default TCP congestion control [TBD] | ||||
+ Traffic timeline: | ||||
- Start time: 0s | ||||
- End time: 119s | ||||
4.2.3. Typical test scenarios | ||||
This sections describes a few specific test scenarios that are deemed | ||||
as important for understanding behavior of a RMCAT candidate solution | ||||
over a Wi-Fi network. | ||||
o Multiple RMCAT Flows Sharing the Wireless Downlink: N=16 (all | ||||
downlink); M = 0; This test case is for studying the impact of | ||||
contention on competing RMCAT flows. Specifications for IEEE | ||||
802.11g with a physical-layer transmission rate of 54 Mbps is | ||||
chosen. Note that retransmission and MAC-layer headers and | ||||
control packets may be sent at a lower link speed. The total | ||||
application-layer throughput (reasonable distance, low | ||||
interference and small number of contention stations) for 802.11g | ||||
is around 20 Mbps. Consequently, a total of N=16 RMCAT flows are | ||||
needed for saturating the wireless interface in this experiment. | ||||
Evaluation of a given candidate solution should focus on whether | ||||
downlink RMCAT flows can stabilize at a fair share of bandwidth. | ||||
o Multiple RMCAT Flows Sharing the Wireless Uplink: N = 16 (all | ||||
downlink); M = 0; When multiple clients attempt to transmit video | ||||
packets uplink over the wireless interface, they introduce more | ||||
frequent contentions and potentially collisions. Per-flow | ||||
throughput is expected to be lower than that in the previous | ||||
downlink-only scenario. Evaluation of a given candidate solution | ||||
should focus on whether uplink flows can stabilize at a fair share | ||||
of bandwidth. | ||||
o Multiple Bi-directional RMCAT Flows: N = 16 (8 uplink and 8 | ||||
downlink); M = 0. The goal of this test is to evaluate | ||||
performance of the candidate solution in terms of bandwidth | ||||
fairness between uplink and downlink flow. | ||||
o Multiple RMCAT flows in the presence of background TCP traffic: | ||||
the goal of this test is to evaluate how RMCAT flows compete | ||||
against TCP over a congested Wi-Fi network for a given candidate | ||||
solution. [Editor's Note: more detailed description will be added | ||||
in the next version in terms of directoin/number of RMCAT and TCP | ||||
flows. ] | ||||
o Varying number of RMCAT flows: the goal of this test is to | ||||
evaluate how a candidate RMCAT solution responds to varying | ||||
traffic load/demand over a congested Wi-Fi network. [Editor's | ||||
Note: more detailed description will be added in the next version | ||||
in terms of arrival/departure pattern of the flows.] | ||||
4.2.4. Expected behavior | ||||
o Multiple downlink RMCAT flows: All RMCAT flows should get fair | ||||
share of the bandwidth. Overall bandwidth usage should be no less | ||||
than same case with TCP flows (using TCP as performance | ||||
benchmark). The delay and loss should be within acceptable range | ||||
for real-time multimedia flow. | ||||
o Multiple uplink RMCAT flows: overall bandwidth usage shared by all | ||||
RMCAT flows should be no less than those shared by the same number | ||||
of TCP flows (i.e., benchmark performance using TCP flows). | ||||
o Multiple bi-directional RMCAT flows: overall bandwidth usage | ||||
shared by all RMCAT flows should be no less than those shared by | ||||
the same number of TCP flows (i.e., benchmark performance using | ||||
TCP flows). All downlink RMCAT flows are expected to obtain | ||||
similar bandwidth with respect to each other. | ||||
4.3. Potential Potential Test Cases | ||||
4.3.1. EDCA/WMM usage | ||||
EDCA/WMM is prioritized QoS with four traffic classes (or Access | ||||
Categories) with differing priorities. RMCAT flow should have better | ||||
performance (lower delay, less loss) with EDCA/WMM enabled when | ||||
competing against non-interactive background traffic (e.g., file | ||||
transfers). When most of the traffic over Wi-Fi is dominated by | ||||
media, however, turning on WMM may actually degrade performance. | ||||
This is a topic worthy of further investigation. | ||||
4.3.2. Legacy 802.11b Effects | ||||
When there is 802.11b devices connected to modern 802.11 network, it | ||||
may affect the performance of the whole network. Additional test | ||||
cases can be added to evaluate the affects of legacy devices on the | ||||
performance of RMCAT congestion control algorithm. | ||||
5. Conclusion | 5. Conclusion | |||
This document defines two test cases that are considered important | This document defines a collection of test cases that are considered | |||
for cellular networks. Moreover, this document also provides a | important for cellular and Wi-Fi networks. Moreover, this document | |||
framework to define more additional test cases for cellular network. | also provides a framework for defining additional test cases over | |||
wireless cellular/Wi-Fi networks. | ||||
6. Acknowledgements | 6. Acknowledgements | |||
We would like to thank Tomas Frankkila, Magnus Westerlund, Kristofer | We would like to thank Tomas Frankkila, Magnus Westerlund, Kristofer | |||
Sandlund for their valuable comments while writing this draft. | Sandlund for their valuable comments while writing this draft. | |||
7. IANA Considerations | 7. IANA Considerations | |||
This memo includes no request to IANA. | This memo includes no request to IANA. | |||
skipping to change at page 11, line 8 | skipping to change at page 19, line 14 | |||
[HO-UMTS-3GPP] | [HO-UMTS-3GPP] | |||
TS 25.331, 3GPP., "Radio Resource Control (RRC); Protocol | TS 25.331, 3GPP., "Radio Resource Control (RRC); Protocol | |||
specification", December 2011, | specification", December 2011, | |||
<http://www.3gpp.org/ftp/specs/ | <http://www.3gpp.org/ftp/specs/ | |||
archive/25_series/25.331/25331-990.zip>. | archive/25_series/25.331/25331-990.zip>. | |||
[I-D.ietf-rmcat-eval-criteria] | [I-D.ietf-rmcat-eval-criteria] | |||
Singh, V. and J. Ott, "Evaluating Congestion Control for | Singh, V. and J. Ott, "Evaluating Congestion Control for | |||
Interactive Real-time Media", draft-ietf-rmcat-eval- | Interactive Real-time Media", draft-ietf-rmcat-eval- | |||
criteria-03 (work in progress), March 2015. | criteria-04 (work in progress), October 2015. | |||
[NS3WiFi] "Wi-Fi Channel Model in NS3 Simulator", | ||||
<https://www.nsnam.org/doxygen/ | ||||
classns3_1_1_yans_wifi_channel.html>. | ||||
[QoS-3GPP] | [QoS-3GPP] | |||
TS 23.203, 3GPP., "Policy and charging control | TS 23.203, 3GPP., "Policy and charging control | |||
architecture", June 2011, <http://www.3gpp.org/ftp/specs/ | architecture", June 2011, <http://www.3gpp.org/ftp/specs/ | |||
archive/23_series/23.203/23203-990.zip>. | archive/23_series/23.203/23203-990.zip>. | |||
[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, | |||
DOI 10.17487/RFC2119, March 1997, | ||||
<http://www.rfc-editor.org/info/rfc2119>. | ||||
9.2. Informative References | 9.2. Informative References | |||
[I-D.ietf-rmcat-cc-requirements] | [I-D.ietf-rmcat-cc-requirements] | |||
Jesup, R. and Z. Sarker, "Congestion Control Requirements | Jesup, R. and Z. Sarker, "Congestion Control Requirements | |||
for Interactive Real-Time Media", draft-ietf-rmcat-cc- | for Interactive Real-Time Media", draft-ietf-rmcat-cc- | |||
requirements-09 (work in progress), December 2014. | requirements-09 (work in progress), December 2014. | |||
[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-01 (work in progress), March 2015. | eval-test-02 (work in progress), September 2015. | |||
[IEEE802.11] | [IEEE802.11] | |||
"Standard for Information technology--Telecommunications | "Standard for Information technology--Telecommunications | |||
and information exchange between systems Local and | and information exchange between systems Local and | |||
metropolitan area networks--Specific requirements Part 11: | metropolitan area networks--Specific requirements Part 11: | |||
Wireless LAN Medium Access Control (MAC) and Physical | Wireless LAN Medium Access Control (MAC) and Physical | |||
Layer (PHY) Specifications", 2012. | Layer (PHY) Specifications", 2012. | |||
[LTE-simulator] | [LTE-simulator] | |||
"NS-3, A discrete-Event Network Simulator", | "NS-3, A discrete-Event Network Simulator", | |||
<https://www.nsnam.org/docs/release/3.23/manual/html/ | <https://www.nsnam.org/docs/release/3.23/manual/html/ | |||
index.html>. | index.html>. | |||
[ns-2] "The Network Simulator - ns-2", | ||||
<http://www.isi.edu/nsnam/ns/>. | ||||
[ns-3] "The Network Simulator - ns-3", <https://www.nsnam.org/>. | ||||
Authors' Addresses | Authors' Addresses | |||
Zaheduzzaman Sarker | Zaheduzzaman Sarker | |||
Ericsson AB | Ericsson AB | |||
Laboratoriegraend 11 | Laboratoriegraend 11 | |||
Luleae 97753 | Luleae 97753 | |||
Sweden | Sweden | |||
Phone: +46 107173743 | Phone: +46 107173743 | |||
Email: zaheduzzaman.sarker@ericsson.com | Email: zaheduzzaman.sarker@ericsson.com | |||
skipping to change at page 12, line 4 | skipping to change at page 20, line 20 | |||
Authors' Addresses | Authors' Addresses | |||
Zaheduzzaman Sarker | Zaheduzzaman Sarker | |||
Ericsson AB | Ericsson AB | |||
Laboratoriegraend 11 | Laboratoriegraend 11 | |||
Luleae 97753 | Luleae 97753 | |||
Sweden | Sweden | |||
Phone: +46 107173743 | Phone: +46 107173743 | |||
Email: zaheduzzaman.sarker@ericsson.com | Email: zaheduzzaman.sarker@ericsson.com | |||
Ingemar Johansson | Ingemar Johansson | |||
Ericsson AB | Ericsson AB | |||
Laboratoriegraend 11 | Laboratoriegraend 11 | |||
Luleae 97753 | Luleae 97753 | |||
Sweden | Sweden | |||
Phone: +46 10 7143042 | Phone: +46 10 7143042 | |||
Email: ingemar.s.johansson@ericsson.com | Email: ingemar.s.johansson@ericsson.com | |||
Xiaoqing Zhu | ||||
Cisco Systems | ||||
12515 Research Blvd., Building 4 | ||||
Austin, TX 78759 | ||||
USA | ||||
Email: xiaoqzhu@cisco.com | ||||
Jiantao Fu | ||||
Cisco Systems | ||||
707 Tasman Drive | ||||
Milpitas, CA 95035 | ||||
USA | ||||
Email: jianfu@cisco.com | ||||
Wei-Tian Tan | ||||
Cisco Systems | ||||
725 Alder Drive | ||||
Milpitas, CA 95035 | ||||
USA | ||||
Email: dtan2@cisco.com | ||||
Michael A. Ramalho | ||||
Cisco Systems | ||||
8000 Hawkins Road | ||||
Sarasota, FL 34241 | ||||
USA | ||||
Phone: +1 919 476 2038 | ||||
Email: mramalho@cisco.com | ||||
End of changes. 18 change blocks. | ||||
30 lines changed or deleted | 414 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/ |