Network Working Group J. Fu Internet-Draft X. Zhu Intended status: Informational M. Ramalho Expires: January 4, 2016 W. Tan Cisco Systems July 3, 2015 Evaluation Test Cases for Interactive Real-Time Media over Wi-Fi Networks draft-fu-rmcat-wifi-test-case-00 Abstract Wireless network is becoming the dominiant mode of Internet access nowadays. According to statisics gathered by Cisco regarding usage of interactive real-time interactive media (e.g., video conferencing calls) across different types of clients, 76.12% of the calls are over Wi-Fi networks, 23.84% are over cellular, and only 0.04% are over Ethernet. [Editor's note: need some clarification/reference regarding source of this data]. It is therefore important to evaluate candidate congestion control schemes designed for real-time interactive media 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 4, 2016. Fu, et al. Expires January 4, 2016 [Page 1] Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015 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 (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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Test Scenarios with Wired Bottlenecks . . . . . . . . . . . . 4 3.1. Single RMCAT Flow over Wired Bottleneck . . . . . . . . . 4 3.2. Bidirectional RMCAT Flows 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 Uplink . . . . 10 4.3. Multiple RMCAT Flows Sharing the Wireless Downlink . . . 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 Fu, et al. Expires January 4, 2016 [Page 2] Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015 1. Introduction Given the prevalence of Internet acess 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 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 that Wi-Fi network has different senarios which has impact on the network performance, and affects packet delay and packet loss which real-time multimedia congestion control rely on. Fu, et al. Expires January 4, 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 these two 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 4, 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 Flows 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 4, 2016 [Page 5] Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015 +----+ +----+ | R1 |)))))) /=====| S1 | +----+ )) uplink // +----+ )) +-------------->+ // +----+ +----+ +----+ +----+ | S2 |))))))))))| AP |==========| B |========| R2 | +----+ +----+ +----+ +----+ +<--------------+ downlink Figure 2: Two Bidirectional Flows 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 4, 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 4, 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. Currently the widely used IEEE 802.11 standards are 802.11g and 802.11n, 802.11ac. IEEE 802.11b is legency standard, and 802.11a is not widely adopted. 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 Fu, et al. Expires January 4, 2016 [Page 8] Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015 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. [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. Fu, et al. Expires January 4, 2016 [Page 9] Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015 + Number of media sources: One (1) + Media timeline: - 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 Uplink 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. 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 4, 2016 [Page 10] Internet-Draft RMCAT Wi-Fi Evaluation Test Cases July 2015 uplink +----------------->+ +----+ +----+ | S1 |)))))) /=====| R1 | +----+ )) // +----+ )) // +----+ +----+ +----+ +----+ | S2 |))))))))))| AP |==========| B |========| R2 | +----+ +----+ +----+ +----+ ...... ...... )) \\ +----+ )) \\ +----+ |S16 |)))))) \=====|R16 | +----+ +----+ +<-----------------+ downlink Figure 6: Multiple RMCAT 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) * 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. Fu, et al. Expires January 4, 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, 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.3. Multiple RMCAT Flows Sharing the Wireless Downlink This test case is different with the uplink one in the previous section because here, most of the time the access point (AP) is transmission, whereas individual stations only need to send feedback messages. As a result, this test case will incur less contention than the uplink case. uplink +----------------->+ +----+ +----+ | R1 |)))))) /=====| S1 | +----+ )) // +----+ )) // +----+ +----+ +----+ +----+ | R2 |))))))))))| AP |==========| B |========| S2 | +----+ +----+ +----+ +----+ ...... ...... )) \\ +----+ )) \\ +----+ |R16 |)))))) \=====|S16 | +----+ +----+ +<-----------------+ downlink Figure 7: Multiple RMCAT Flows Sharing the Wireless Downlink Testbed attributes: Fu, et al. Expires January 4, 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) * 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. + 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. Fu, et al. Expires January 4, 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 4, 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 4, 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 4, 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 4, 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 4, 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 4, 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 4, 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 4, 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) when EDCA/WMM enabled. 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 4, 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", . 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 Jian 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 4, 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 4, 2016 [Page 24]