Internet DRAFT - draft-fu-rmcat-wifi-test-case
draft-fu-rmcat-wifi-test-case
Network Working Group J. Fu
Internet-Draft X. Zhu
Intended status: Informational M. Ramalho
Expires: January 7, 2016 W. Tan
Cisco Systems
July 6, 2015
Evaluation Test Cases for Interactive Real-Time Media over Wi-Fi
Networks
draft-fu-rmcat-wifi-test-case-01
Abstract
An increasing proportion of multimedia communication applications,
including real-time interactive voice and video, are transported over
Wi-Fi networks (i.e., wireless local area networks following IEEE
802.11 standards) today. It is therefore important to evaluate
candidate congestion control schemes designed in the RMCAT Working
Group over test cases that include Wi-Fi access links. This draft
serves such a purpose, and is complementary to
[I-D.ietf-rmcat-eval-test] and
[I-D.draft-sarker-rmcat-cellular-eval-test-cases]
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Fu, et al. Expires January 7, 2016 [Page 1]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Test Scenarios with Wired Bottlenecks . . . . . . . . . . . . 4
3.1. Single RMCAT Flow over Wired Bottleneck . . . . . . . . . 4
3.2. Bidirectional RMCAT Flow over Wired Bottleneck . . . . . 5
3.3. RMCAT Flow Competing with Long TCP over Wired Bottleneck 7
4. Bottleneck over Wireless Network . . . . . . . . . . . . . . 8
4.1. Adaptive rate selection with single RMCAT flow . . . . . 8
4.2. Multiple RMCAT Flows Sharing the Wireless Downlink . . . 10
4.3. Multiple RMCAT Flows Sharing the Wireless Uplink . . . . 12
4.4. Multiple Bi-Directional RMCAT Flows Sharing the Wireless
Bottleneck . . . . . . . . . . . . . . . . . . . . . . . 14
4.5. Multiple RMCAT and TCP Flows Sharing the Wireless Uplink 15
4.6. Multiple RMCAT and TCP Flows Sharing the Wireless
Downlink . . . . . . . . . . . . . . . . . . . . . . . . 17
4.7. Multiple Bi-Directional RMCAT and TCP Flows Sharing the
Wireless Bottleneck . . . . . . . . . . . . . . . . . . . 19
5. Other potential test cases . . . . . . . . . . . . . . . . . 21
5.1. Wi-Fi Roaming . . . . . . . . . . . . . . . . . . . . . . 21
5.2. Wi-Fi/Cellular Switch . . . . . . . . . . . . . . . . . . 22
5.3. EDCA/WMM usage . . . . . . . . . . . . . . . . . . . . . 22
5.4. Legacy 802.11b Effects . . . . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
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, multipath fading, and shadowing, causing
Fu, et al. Expires January 7, 2016 [Page 2]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
fluctuations in link throughput and sometimes an error-prone
communication environment
o Available network bandwidth is not only shared over the air
between cocurrent users, but also between uplink and downlink
traffic due to the half duplex nature of wireless transmission
medium.
o Packet transmessions 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 singal
strength. A different choice of Physical-layer rate will lead to
different application-layer throughput.
o Presence of legancy 802.11b networks can significantly slow down
the 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 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.
Currently, the most widely used IEEE 802.11 standards are 802.11g and
802.11n. The industry is moving towards 802.11ac and, potentially,
802.11ad. IEEE 802.11b is legency standard, and 802.11a has not been
widely adopted. Throughout this draft, unless otherwise mentioned,
test cases are described using 802.11g mostly due to its wide
availability both in test equipments and network simulation platform.
Whenever possible, it is recommended to extend some of the
experiments to 802.11ac so as to reflect a more mordent Wi-Fi network
setting.
Fu, et al. Expires January 7, 2016 [Page 3]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
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.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described RFC2119 [RFC2119].
3. Test Scenarios with Wired Bottlenecks
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 the
all-wired test cases (draft-sarker-rmcat-eval-test), it is worthwhile
to run through these tests as sanity checks.
3.1. Single RMCAT Flow over Wired Bottleneck
This test case is designed to measure the responsiveness of the
candidate algorithm when the Wi-Fi hop of the connection is
uncongested.
Figure 1 illustrates topology of this test.
uplink
+-------------->+
+----+ +----+ +----+ +----+
| S |))))))))))| AP |==========| B |=========| R |
+----+ +----+ +----+ +----+
Figure 1: Single Flow over Wired Bottleneck
Testbed attributes:
o Test duration: 100s
o Path characteristics:
* Uplink capacity: 1Mbps
* One-Way propagation delay: 50ms.
Fu, et al. Expires January 7, 2016 [Page 4]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
* Maximum end-to-end jitter: 30ms
* Bottleneck queue type: Drop tail.
* Bottleneck queue size: 300ms.
* Path loss ratio: 0%.
o Application-related:
* Media Traffic:
+ Media type: Video
+ Media direction: forward.
+ Number of media sources: One (1)
+ Media timeline:
- Start time: 0s.
- End time: 99s.
* Competing traffic:
+ Number of sources : Zero (0)
Expected behavior: 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. Oscillations
occur when the media flow(s) attempts to reach its maximum bit rate,
overshoots the usage of the available bottleneck capacity, to rectify
it reduces the bit rate and starts to ramp up again.
3.2. Bidirectional RMCAT Flow over Wired Bottleneck
This test case is designed to evaluate performance of the candidate
algorithm when lack of enough feedback.
Fu, et al. Expires January 7, 2016 [Page 5]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
+----+ +----+
| R1 |)))))) /=====| S1 |
+----+ )) uplink // +----+
)) +-------------->+ //
+----+ +----+ +----+ +----+
| S2 |))))))))))| AP |==========| B |========| R2 |
+----+ +----+ +----+ +----+
+<--------------+
downlink
Figure 2: One Bi-directional Flow over Wired Bottleneck
Testbed attributes:
o Test duration: 100s
o Path characteristics:
* uplink 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: forward and backward.
+ Number of media sources: Two (2)
+ Media timeline:
- Start time: 0s.
- End time: 99s.
Fu, et al. Expires January 7, 2016 [Page 6]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
* Competing traffic:
+ Number and Types of sources : zero (0)
Expected behavior: It is expected that the candidate algorithms is
able to cope with the lack/noise of feedback information and adapt to
minimize the performance degradation of media flows in the forward
channel.
3.3. RMCAT Flow Competing with Long TCP over Wired Bottleneck
This test case is designed to measure the performance of the
candidate algorithm when lack of enough feedback.
+----+ +----+
| S1 |)))))) /=====| R1 |
+----+ )) uplink // +----+
)) +-------------->+ //
+-------+ +----+ +----+ +-------+
| S_tcp |))))))))))| AP |==========| B |========| R_tcp |
+-------+ +----+ +----+ +-------+
+<--------------+
downlink
Figure 3: RMCAT vs. TCP over Wired Bottleneck
Testbed attributes:
Test duratiion: 100s
Path characteristics:
* uplink 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%.
Application-related:
Fu, et al. Expires January 7, 2016 [Page 7]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
* Media Traffic:
+ Media type: Video
+ Media direction: forward.
+ Number of media sources: One (1)
+ Media timeline:
- Start time: 0s.
- End time: 99s.
* Competing traffic:
+ Types of sources : long-lived TCP
+ Number of sources: One (1)
+ Traffic direction : forward
+ Congestion control: Default TCP congestion control [TBD].
+ Traffic timeline:
- Start time: 0s.
- End time: 119s.
Expected behavior: the candidate algorithm should be able to avoid
congestion collapse, and get fair share of the bandwidth. In the
worst case, the media stream will fall to the minimum media bit rate.
4. Bottleneck over Wireless 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.1. Adaptive rate selection with single RMCAT flow
Since morden IEEE 802.11 standards supports far higher data rates
than the maximum requirements of individual RMCAT flows, in this test
the legacy standard 802.11b is chosen to test the single RMCAT flow
case. 802.11b Adaptive rate selection can operate at 11 Mbps in terms
of PHY-layer transmission rate, and falls back to 5.5 Mbps, 2 Mbps,
and 1 Mbps when the wireless client moves away from the access point.
Fu, et al. Expires January 7, 2016 [Page 8]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
[Editor's Note: we may want to move this section to Section 5.4
instead.]
uplink
+-------------->+
+----+ +----+ +----+ +----+
| S |))))))))))| AP |==========| B |=========| R |
+----+ +----+ +----+ +----+
Figure 4: One RMCAT Flow over Wireless Bottleneck
Testbed attributes:
Test duratiion: 100s
Path characteristics:
* Wired path capacity: 100Mbps
* Wi-Fi PHY Rate: 1Mbps (PHY rate)
* One-Way propagation delay: 50ms.
* Maximum end-to-end jitter: 30ms
* Bottleneck queue type: Drop tail.
* Bottleneck queue size: 300ms.
* Path loss ratio: 0%.
Application characteristics:
* Media Traffic:
+ Media type: Video
+ Media direction: forward and backward.
+ Number of media sources: One (1)
+ Media timeline:
Fu, et al. Expires January 7, 2016 [Page 9]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
- Start time: 0s.
- End time: 99s.
* Competing traffic:
+ Number and Types of sources : zero (0)
Test Specific Information:
* This test will change the distance between station and AP (need
some experiment), and incur the adaptive rate selection
variation as listed in Figure 5.
+---------------------+----------------+------------+----------------+
| Variation pattern | Path direction | Start time | PHY-layer rate |
| index | | | |
+---------------------+----------------+------------+----------------+
| One | Forward | 0s | 5.5 Mbps |
| Two | Forward | 40s | 2 Mbps |
| Three | Forward | 60s | 1 Mbps |
| Four | Forward | 80s | 2 Mbps |
+---------------------+----------------+------------+---------------+
Figure 5: Adaptive rate variation pattern for uplink direction
Expected behavior: The rate adaptation algorithm run at application
level should follow the adaptation in 802.11 mac layer.
4.2. Multiple RMCAT Flows Sharing the Wireless Downlink
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. Not 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 16 RMCAT flows are
needed for saturating the wireless interface in this experiment.
Fu, et al. Expires January 7, 2016 [Page 10]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
uplink
+----------------->+
+----+ +----+
| R1 |)))))) /=====| S1 |
+----+ )) // +----+
)) //
+----+ +----+ +----+ +----+
| R2 |))))))))))| AP |==========| B |========| S2 |
+----+ +----+ +----+ +----+
...... ......
)) \\
+----+ )) \\ +----+
|R16 |)))))) \=====|S16 |
+----+ +----+
+<-----------------+
downlink
Figure 6: Multiple RMCAT Flows Sharing the Wireless Downlink
Testbed attributes:
o Test duratiion: 100s
o Path characteristics:
* Wired path capacity: 100Mbps
* Wi-Fi PHY Rate: 54Mbps (PHY rate)
* 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: backward.
Fu, et al. Expires January 7, 2016 [Page 11]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
+ Number of media sources: Sixteen (16)
+ Media timeline:
- Start time: 0s.
- End time: 99s.
* Competing traffic:
+ Number and Types of sources : Zero (0)
Expected behavior: All RMCAT flow 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.
4.3. Multiple RMCAT Flows Sharing the Wireless Uplink
This test case is different with the previous section with mostly
downlink transmissions. When multiple clients attempt to transmit
video packets uplink over the wireless interface, they introduce more
frequent contentions and potentially collisions. As a results, the
per-client throught is expected to be lower than the downlink-only
scenario.
uplink
+----------------->+
+----+ +----+
| S1 |)))))) /=====| R1 |
+----+ )) // +----+
)) //
+----+ +----+ +----+ +----+
| S2 |))))))))))| AP |==========| B |========| R2 |
+----+ +----+ +----+ +----+
...... ......
)) \\
+----+ )) \\ +----+
|S16 |)))))) \=====|R16 |
+----+ +----+
+<-----------------+
downlink
Figure 7: Multiple RMCAT Flows Sharing the Wireless Uplink
Testbed attributes:
Fu, et al. Expires January 7, 2016 [Page 12]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
o Test duratiion: 100s
o Path characteristics:
* Wired path capacity: 100Mbps
* Wi-Fi PHY Rate: 54Mbps (PHY rate)
* Maximum end-to-end jitter: 30ms
* One-Way propagation delay: 50ms.
* Bottleneck queue type: Drop tail.
* Bottleneck queue size: 300ms.
* Path loss ratio: 0%.
o Application characteristics:
* Media Traffic:
+ Media type: Video
+ Media direction: forward and backward.
+ Number of media sources: Sixteen (16)
+ Media timeline:
- Start time: 0s.
- End time: 99s.
* Competing traffic:
+ Number and Types of sources : Zero (0)
Expected behavior: All RMCAT flow should get fair share of the
bandwidth, and the overall bandwidth usage should no less than same
case with TCP flows (use TCP as performance benchmark). The delay
and loss should be in acceptable range for real-time multimedia flow
(might need rtp circuit breaker to guarantee that?).
Fu, et al. Expires January 7, 2016 [Page 13]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
4.4. Multiple Bi-Directional RMCAT Flows Sharing the Wireless
Bottleneck
This one differs with previous contention cases because Wi-Fi share
bandwdith between uplink and downlink.
uplink
+----------------->+
+----+ +----+
| R1 |)))))) /=====| S1 |
+----+ )) // +----+
)) //
...... ......
+----+ +----+ +----+ +----+
| R8 |))))))))))| AP |==========| B |========| S8 |
+----+ +----+ +----+ +----+
...... ......
)) \\
+----+ )) \\ +----+
|S16 |)))))) \=====|R16 |
+----+ +----+
+<-----------------+
downlink
Figure 8: Multiple Bi-Directional RMCAT Flows Sharing the Wireless
Bottleneck
Testbed attributes:
o Test duratiion: 100s
o Path characteristics:
* Wired path capacity: 100Mbps
* Wi-Fi PHY Rate: 54Mbps (PHY rate)
* One-Way propagation delay: 50ms.
* Maximum end-to-end jitter: 30ms
* Bottleneck queue type: Drop tail.
* Bottleneck queue size: 300ms.
Fu, et al. Expires January 7, 2016 [Page 14]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
* Path loss ratio: 0%.
o Application characteristics:
* Media Traffic:
+ Media type: Video
+ Media direction: forward and backward.
+ Number of media sources: Sixteen (16), 8 for uplink, 8 for
downlink.
+ Media timeline:
- Start time: 0s.
- End time: 99s.
* Competing traffic:
+ Number and Types of sources : zero (0)
Expected behavior: All (uplink/downlink) RMCAT flow should get fair
share of the bandwidth, and the overall bandwidth usage should no
less than same case with TCP flows (use TCP as performance
benchmark). The delay and loss should be in acceptable range for
real-time multimedia flow (might need rtp circuit breaker to
guarantee that?).
4.5. Multiple RMCAT and TCP Flows Sharing the Wireless Uplink
This case having both long lived TCP and RMCAT sharing the uplink at
the same time. This is for testing how RMCAT competing with long
lived TCP flow in a congested Wi-Fi network.
Fu, et al. Expires January 7, 2016 [Page 15]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
uplink
+----------------->+
+----+ +----+
| S1 |)))))) /=====| R1 |
+----+ )) // +----+
)) //
...... ......
+----+ +----+ +----+ +----+
| S8 |))))))))))| |==========| |========| R8 |
+----+ | | | | +----+
| AP | | B |
+--------+ | | | | +--------+
| S1_tcp |))))))| | | |========| R1_tcp |
+--------+ +----+ +----+ +--------+
...... ......
)) \\
+--------+ )) \\ +--------+
| S8_tcp |)))) \=====| R8_tcp |
+--------+ +--------+
+<-----------------+
downlink
Figure 9: Multiple RMCAT and TCP Flows Sharing the Wireless Uplink
Testbed attributes:
o Test duratiion: 100s
o Path characteristics:
* Wired path capacity: 100Mbps
* Wi-Fi PHY Rate: 54Mbps (PHY rate)
* 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:
Fu, et al. Expires January 7, 2016 [Page 16]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
* Media Traffic:
+ Media type: Video
+ Media direction: forward.
+ Number of media sources: Eigth (8).
+ Media timeline:
- Start time: 0s.
- End time: 99s.
* Competing traffic:
+ Type of sources: long-live TCP.
+ Number of sources : Eight (8)
+ Traffic direction : forward
+ Congestion control: Default TCP congestion control [TBD].
+ Traffic timeline:
- Start time: 0s.
- End time: 99s.
Expected behavior: All RMCAT flows should get comparable share of the
network bandwidth with respect to competing TCP flows. The overall
bandwidth usage should no less than same case with TCP flows (use TCP
as performance benchmark). The delay and loss should be in
acceptable range for real-time multimedia flow (might need rtp
circuit breaker to guarantee that?).
4.6. Multiple RMCAT and TCP Flows Sharing the Wireless Downlink
This case having both long lived TCP and RMCAT on the downlink at the
same time. This is for testing how RMCAT competing with long lived
TCP flow in crowed Wi-Fi network. This differs from test scenario in
the previous section becauase less contention on the Wi-Fi network
because most media data is sent from AP to stations.
Fu, et al. Expires January 7, 2016 [Page 17]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
uplink
+----------------->+
+----+ +----+
| R1 |)))))) /=====| S1 |
+----+ )) // +----+
)) //
...... ......
+----+ +----+ +----+ +----+
| R8 |))))))))))| |==========| |========| S8 |
+----+ | | | | +----+
| AP | | B |
+--------+ | | | | +--------+
| R1_tcp |))))))| | | |========| S1_tcp |
+--------+ +----+ +----+ +--------+
...... ......
)) \\
+--------+ )) \\ +--------+
| R8_tcp |)))) \=====| S8_tcp |
+--------+ +--------+
+<-----------------+
downlink
Figure 10: Multiple RMCAT and TCP Flows Sharing the Wireless Downlink
Testbed attributes:
o Test duratiion: 100s
o Path characteristics:
* Wired path capacity: 100Mbps
* Wi-Fi PHY Rate: 54Mbps (PHY rate)
* One-Way propagation delay: 50ms.
* Maximum end-to-end jitter: 30ms
* Bottleneck queue type: Drop tail.
* Bottleneck queue depth: 300ms.
* Path loss ratio: 0%.
o Application characteristics:
Fu, et al. Expires January 7, 2016 [Page 18]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
* Media Traffic:
+ Media type: Video
+ Media direction: backward.
+ Number of media sources: Eight (8).
+ Media timeline:
- Start time: 0s.
- End time: 99s.
* Competing traffic:
+ Number of sources: Eight (8).
+ Types of sources : long-lived TCP.
+ Traffic direction : forward
+ Congestion control: Default TCP congestion control.
+ Traffic timeline:
- Start time: 0s.
- End time: 99s.
Expected behavior: All RMCAT flows should get comparable share of the
network bandwidth with respect to competing TCP flows. The overall
bandwidth usage should no less than same case with TCP flows (use TCP
as performance benchmark). The delay and loss should be in
acceptable range for real-time multimedia flow (might need rtp
circuit breaker to guarantee that?).
4.7. Multiple Bi-Directional RMCAT and TCP Flows Sharing the Wireless
Bottleneck
This case having both long lived TCP and RMCAT on the both direction
at the same time. This is for testing how RMCAT competing with long
lived TCP flow in a congested Wi-Fi network. This differs from
previouss cases as both uplink and downlink flows share the same
wireless bottleneck.
Fu, et al. Expires January 7, 2016 [Page 19]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
uplink
+----------------->+
+----+ +----+
| S1 |)))))) /=====| R1 |
+----+ )) // +----+
)) //
...... ......
+----+ +----+ +----+ +----+
| R8 |))))))))))| |==========| |========| S8 |
+----+ | | | | +----+
| AP | | B |
+--------+ | | | | +--------+
| S1_tcp |))))))| | | |========| R1_tcp |
+--------+ +----+ +----+ +--------+
...... ......
)) \\
+--------+ )) \\ +--------+
| R8_tcp |)))) \=====| S8_tcp |
+--------+ +--------+
+<-----------------+
downlink
Figure 11: Multiple Bi-Directional RMCAT and TCP Flows Sharing the
Wireless Bottleneck
Testbed attributes:
o Test duratiion: 100s
o Path characteristics:
* Wired path capacity: 100Mbps
* Wi-Fi PHY Rate: 54Mbps (PHY rate)
* 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:
Fu, et al. Expires January 7, 2016 [Page 20]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
* Media Traffic:
+ Media type: Video
+ Media direction: forward and backward.
+ Number of media sources: Eight (8). Four (4) forward, Four
(4) backward
+ Media timeline:
- Start time: 0s.
- End time: 99s.
* Competing traffic:
+ Number of sources : Eight (8). Four (4) forward, Four (4)
backward.
+ Type of sources: long-live TCP.
+ Traffic direction : forward and backward.
+ Congestion control: Default TCP congestion control.
+ Traffic timeline:
- Start time: 0s.
- End time: 99s.
Expected behavior: All RMCAT flows should get comparable share of the
network bandwidth with respect to competing TCP flows. The overall
bandwidth usage should no less than same case with TCP flows (use TCP
as performance benchmark). The delay and loss should be in
acceptable range for real-time multimedia flow (might need rtp
circuit breaker to guarantee that?).
5. Other potential test cases
5.1. Wi-Fi Roaming
Wi-Fi roaming need scanning, authentication and re-association which
will cause packet drops and delay, and interrupt the network
connection. RMCAT congestion control algorithms should at least
recover (if affected by the transition process) after roaming.
Fu, et al. Expires January 7, 2016 [Page 21]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
5.2. Wi-Fi/Cellular Switch
The phone can switch automatically between Wi-Fi and Cellular network
when the other is not available, and some phones like "Samsung
Galaxy" have smart network switch to switching to network has better
connectivity automatically. Unlike Wi-Fi Roaming, such kind of
switch might or might not interrupt the network connection, and might
change the route. RMCAT congestion control should be able to cope
with the changes.
5.3. 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.
5.4. 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 legancy devices on the
performance of RMCAT congestion control algorithm.
6. IANA Considerations
There are no IANA impacts in this memo.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-avtcore-rtp-circuit-breakers]
Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", draft-ietf-
avtcore-rtp-circuit-breakers-05 (work in progress),
February 2014.
[I-D.ietf-rmcat-eval-criteria]
Singh, V. and J. Ott, "Evaluating Congestion Control for
Interactive Real-time Media", draft-ietf-rmcat-eval-
criteria-01 (work in progress), March 2014.
Fu, et al. Expires January 7, 2016 [Page 22]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
[I-D.ietf-rmcat-eval-test]
Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test
Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat-
eval-test-01 (work in progress), March 2015.
[I-D.ietf-rmcat-cc-requirements]
Jesup, R., "Congestion Control Requirements For RMCAT",
draft-ietf-rmcat-cc-requirements-04 (work in progress),
April 2014.
[I-D.draft-sarker-rmcat-cellular-eval-test-cases]
Sarker, Z., "Evaluation Test Cases for Interactive Real-
Time Media over Cellular Networks", <https://tools.ietf
.org/html/draft-sarker-rmcat-cellular-eval-test-cases-02>.
7.2. Informative References
[I-D.ietf-rtcweb-use-cases-and-requirements]
Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Time Communication Use-cases and Requirements", draft-
ietf-rtcweb-use-cases-and-requirements-14 (work in
progress), February 2014.
Authors' Addresses
Jiantao Fu
Cisco Systems
707 Tasman Drive
Milpitas, CA 95035
USA
Email: jianfu@cisco.com
Xiaoqing Zhu
Cisco Systems
12515 Research Blvd., Building 4
Austin, TX 78759
USA
Email: xiaoqzhu@cisco.com
Fu, et al. Expires January 7, 2016 [Page 23]
Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015
Michael A. Ramalho
Cisco Systems
8000 Hawkins Road
Sarasota, FL 34241
USA
Phone: +1 919 476 2038
Email: mramalho@cisco.com
Wei-Tian Tan
Cisco Systems
725 Alder Drive
Milpitas, CA 95035
USA
Email: dtan2@cisco.com
Fu, et al. Expires January 7, 2016 [Page 24]
