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]