One document matched: draft-fu-rmcat-wifi-test-case-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY I-D.ietf-rmcat-cc-requirements PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rmcat-cc-requirements.xml">
<!ENTITY I-D.ietf-avtcore-rtp-circuit-breakers PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-avtcore-rtp-circuit-breakers.xml">
<!ENTITY I-D.ietf-rmcat-eval-criteria PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rmcat-eval-criteria.xml">
<!ENTITY I-D.ietf-rmcat-eval-test PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rmcat-eval-test.xml">
<!ENTITY I-D.ietf-rtcweb-use-cases-and-requirements PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-use-cases-and-requirements.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes" ?>
<rfc category="info" docName="draft-fu-rmcat-wifi-test-case-01"
ipr="trust200902">
<!-- What is the category field value-->
<front>
<title abbrev="RMCAT Wi-Fi Evaluation Test Cases">
Evaluation Test Cases for Interactive Real-Time Media
over Wi-Fi Networks</title>
<author fullname="Jiantao Fu" initials="J." surname="Fu">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>707 Tasman Drive</street>
<city>Milpitas</city>
<region>CA</region>
<code>95035</code>
<country>USA</country>
</postal>
<email>jianfu@cisco.com</email>
</address>
</author>
<author fullname="Xiaoqing Zhu" initials="X" surname="Zhu">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>12515 Research Blvd., Building 4</street>
<city>Austin</city>
<region>TX</region>
<code>78759</code>
<country>USA</country>
</postal>
<email>xiaoqzhu@cisco.com</email>
</address>
</author>
<author fullname="Michael A. Ramalho" initials="M. A." surname="Ramalho">
<organization abbrev="Cisco Systems">Cisco Systems</organization>
<address>
<postal>
<street>8000 Hawkins Road</street>
<city>Sarasota</city>
<region>FL</region>
<code>34241</code>
<country>USA</country>
</postal>
<phone>+1 919 476 2038</phone>
<email>mramalho@cisco.com</email>
</address>
</author>
<author fullname="Wei-Tian Tan" initials="W.-T." surname="Tan">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>725 Alder Drive </street>
<city>Milpitas</city>
<region>CA</region>
<code>95035</code>
<country>USA</country>
</postal>
<email>dtan2@cisco.com</email>
</address>
</author>
<date year="2015"/>
<area>TSV</area>
<keyword>Multimedia</keyword>
<keyword>Congestion Control</keyword>
<abstract>
<t>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
<xref target="I-D.ietf-rmcat-eval-test"></xref> and
<xref target="I-D.draft-sarker-rmcat-cellular-eval-test-cases"></xref>
</t>
</abstract>
</front>
<middle>
<section anchor="sec-intro" title="Introduction">
<t>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: </t>
<t><list style="symbols">
<t>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</t>
<t>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. </t>
<t>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.</t>
<t>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.</t>
<t>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.]</t>
<t>Handover from one Wi-Fi Access Point (AP) to another
may cause packet delay and loss.</t>
<t>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).</t>
</list></t>
<t>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.</t>
<t>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. </t>
<t>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.
</t>
</section>
<section anchor="sec-term" title="Terminology">
<t>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 <xref
target="RFC2119">RFC2119</xref>.</t>
</section>
<section anchor="sec-wired-bottleneck"
title="Test Scenarios with Wired Bottlenecks">
<t>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.</t>
<section anchor="sec-3-1"
title="Single RMCAT Flow over Wired Bottleneck">
<t>This test case is designed to measure the
responsiveness of the candidate algorithm when
the Wi-Fi hop of the connection is uncongested.</t>
<t>
<xref target="fig-wired-bottleneck-single-flow"></xref>
illustrates topology of this test.</t>
<t><figure anchor="fig-wired-bottleneck-single-flow"
title="Single Flow over Wired Bottleneck">
<artwork><![CDATA[
uplink
+-------------->+
+----+ +----+ +----+ +----+
| S |))))))))))| AP |==========| B |=========| R |
+----+ +----+ +----+ +----+
]]></artwork>
</figure></t>
<t>Testbed attributes:</t>
<t><list style="symbols">
<t>Test duration: 100s</t>
<t>Path characteristics:
<list style="symbols">
<t>Uplink capacity: 1Mbps</t>
<t>One-Way propagation delay: 50ms.</t>
<t>Maximum end-to-end jitter: 30ms</t>
<t>Bottleneck queue type: Drop tail.</t>
<t>Bottleneck queue size: 300ms.</t>
<t>Path loss ratio: 0%.</t>
</list></t>
<t>Application-related:
<list style="symbols">
<t>Media Traffic:
<list style="symbols">
<t>Media type: Video</t>
<t>Media direction: forward.</t>
<t>Number of media sources: One (1)</t>
<t>Media timeline:<list style="symbols">
<t>Start time: 0s.</t>
<t>End time: 99s.</t>
</list></t>
</list></t>
<t>Competing traffic: <list style="symbols">
<t>Number of sources : Zero (0)</t>
</list></t>
</list></t>
</list></t>
<t>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.</t>
</section>
<section anchor="sec-3-2"
title="Bidirectional RMCAT Flow over Wired Bottleneck">
<t>This test case is designed to evaluate performance of the
candidate algorithm when lack of enough feedback.</t>
<t><figure anchor="fig-wired-bottleneck-two-flows"
title="One Bi-directional Flow over Wired Bottleneck">
<artwork><![CDATA[
+----+ +----+
| R1 |)))))) /=====| S1 |
+----+ )) uplink // +----+
)) +-------------->+ //
+----+ +----+ +----+ +----+
| S2 |))))))))))| AP |==========| B |========| R2 |
+----+ +----+ +----+ +----+
+<--------------+
downlink
]]></artwork>
</figure></t>
<t>Testbed attributes:</t>
<t><list style="symbols">
<t>Test duration: 100s</t>
<t>Path characteristics:
<list style="symbols">
<t>uplink capacity: 1Mbps</t>
<t>One-Way propagation delay: 50ms.</t>
<t>Maximum end-to-end jitter: 30ms</t>
<t>Bottleneck queue type: Drop tail.</t>
<t>Bottleneck queue size: 300ms.</t>
<t>Path loss ratio: 0%.</t>
</list>
</t>
<t>Application characteristics:
<list style="symbols">
<t>Media Traffic:
<list style="symbols">
<t>Media type: Video</t>
<t>Media direction: forward and backward.</t>
<t>Number of media sources: Two (2)</t>
<t>Media timeline: <list style="symbols">
<t>Start time: 0s.</t>
<t>End time: 99s.</t>
</list></t>
</list></t>
<t>Competing traffic:
<list style="symbols">
<t>Number and Types of sources : zero (0)</t>
</list></t>
</list></t>
</list></t>
<t>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.</t>
</section>
<section anchor="sec-3-3"
title="RMCAT Flow Competing with Long TCP over Wired Bottleneck">
<t>This test case is designed to measure the performance of
the candidate algorithm when lack of enough feedback.</t>
<t><figure anchor="fig-wired-bottleneck-rmcat-vs-tcp"
title="RMCAT vs. TCP over Wired Bottleneck">
<artwork><![CDATA[
+----+ +----+
| S1 |)))))) /=====| R1 |
+----+ )) uplink // +----+
)) +-------------->+ //
+-------+ +----+ +----+ +-------+
| S_tcp |))))))))))| AP |==========| B |========| R_tcp |
+-------+ +----+ +----+ +-------+
+<--------------+
downlink
]]></artwork>
</figure></t>
<t>Testbed attributes:</t>
<t><list>
<t>Test duratiion: 100s</t>
<t>Path characteristics:
<list style="symbols">
<t>uplink capacity: 1Mbps</t>
<t>One-Way propagation delay: 50ms.</t>
<t>Maximum end-to-end jitter: 30ms</t>
<t>Bottleneck queue type: Drop tail.</t>
<t>Bottleneck queue size: 300ms.</t>
<t>Path loss ratio: 0%.</t>
</list></t>
<t>Application-related:
<list style="symbols">
<t>Media Traffic:
<list style="symbols">
<t>Media type: Video</t>
<t>Media direction: forward.</t>
<t>Number of media sources: One (1)</t>
<t>Media timeline:
<list style="symbols">
<t>Start time: 0s.</t>
<t>End time: 99s.</t>
</list></t>
</list></t>
<t>Competing traffic:
<list style="symbols">
<t>Types of sources : long-lived TCP</t>
<t>Number of sources: One (1)</t>
<t>Traffic direction : forward</t>
<t>Congestion control: Default TCP congestion control [TBD].</t>
<t>Traffic timeline:
<list style="symbols">
<t>Start time: 0s.</t>
<t>End time: 119s.</t>
</list></t>
</list></t>
</list></t>
</list>
</t>
<t>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.</t>
</section>
</section>
<section anchor="sec-wireless-bottleneck"
title="Bottleneck over Wireless Network">
<t>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.</t>
<section anchor="sec-4-1"
title="Adaptive rate selection with single RMCAT flow">
<t>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. </t>
<t>[Editor's Note: we may want to move this section to
<xref target="sec-legacy-effects"></xref> instead.]</t>
<t><figure anchor="fig-wireless-bottleneck-one-flow"
title="One RMCAT Flow over Wireless Bottleneck">
<artwork><![CDATA[
uplink
+-------------->+
+----+ +----+ +----+ +----+
| S |))))))))))| AP |==========| B |=========| R |
+----+ +----+ +----+ +----+
]]>
</artwork>
</figure></t>
<t>Testbed attributes:</t>
<t><list>
<t>Test duratiion: 100s</t>
<t>Path characteristics:
<list style="symbols">
<t>Wired path capacity: 100Mbps</t>
<t>Wi-Fi PHY Rate: 1Mbps (PHY rate)</t>
<t>One-Way propagation delay: 50ms.</t>
<t>Maximum end-to-end jitter: 30ms</t>
<t>Bottleneck queue type: Drop tail.</t>
<t>Bottleneck queue size: 300ms.</t>
<t>Path loss ratio: 0%.</t>
</list></t>
<t>Application characteristics:
<list style="symbols">
<t>Media Traffic:
<list style="symbols">
<t>Media type: Video</t>
<t>Media direction: forward and backward.</t>
<t>Number of media sources: One (1)</t>
<t>Media timeline:
<list style="symbols">
<t>Start time: 0s.</t>
<t>End time: 99s.</t>
</list></t>
</list></t>
<t>Competing traffic:
<list style="symbols">
<t>Number and Types of sources : zero (0)</t>
</list></t>
</list></t>
<t>Test Specific Information:
<list style="symbols">
<t>This test will change the distance between station
and AP (need some experiment), and incur the adaptive
rate selection variation as listed in
<xref target="tab-wifi-rate-adaptation"></xref>.
</t>
</list></t>
</list></t>
<t><figure anchor="tab-wifi-rate-adaptation"
title="Adaptive rate variation pattern for uplink direction">
<artwork><![CDATA[
+---------------------+----------------+------------+----------------+
| 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 |
+---------------------+----------------+------------+---------------+
]]></artwork>
</figure></t>
<t>Expected behavior: The rate adaptation algorithm run at
application level should follow the adaptation in 802.11
mac layer.</t>
</section>
<section anchor="sec-4-3"
title="Multiple RMCAT Flows Sharing the Wireless Downlink">
<t>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. </t>
<t><figure anchor="fig-wireless-downlink-multi-flow"
title="Multiple RMCAT Flows Sharing the Wireless Downlink">
<artwork><![CDATA[
uplink
+----------------->+
+----+ +----+
| R1 |)))))) /=====| S1 |
+----+ )) // +----+
)) //
+----+ +----+ +----+ +----+
| R2 |))))))))))| AP |==========| B |========| S2 |
+----+ +----+ +----+ +----+
...... ......
)) \\
+----+ )) \\ +----+
|R16 |)))))) \=====|S16 |
+----+ +----+
+<-----------------+
downlink
]]></artwork>
</figure></t>
<t>Testbed attributes:
<list style="symbols">
<t>Test duratiion: 100s</t>
<t>Path characteristics:
<list style="symbols">
<t>Wired path capacity: 100Mbps</t>
<t>Wi-Fi PHY Rate: 54Mbps (PHY rate)</t>
<t>One-Way propagation delay: 50ms.</t>
<t>Maximum end-to-end jitter: 30ms</t>
<t>Bottleneck queue type: Drop tail.</t>
<t>Bottleneck queue size: 300ms.</t>
<t>Path loss ratio: 0%.</t>
</list></t>
<t>Application characteristics:
<list style="symbols">
<t>Media Traffic:
<list style="symbols">
<t>Media type: Video</t>
<t>Media direction: backward.</t>
<t>Number of media sources: Sixteen (16)</t>
<t>Media timeline:
<list style="symbols">
<t>Start time: 0s.</t>
<t>End time: 99s.</t>
</list></t>
</list></t>
<t>Competing traffic:
<list style="symbols">
<t>Number and Types of sources : Zero (0)</t>
</list></t>
</list></t>
</list></t>
<t>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.</t>
</section>
<section anchor="sec-4-2"
title="Multiple RMCAT Flows Sharing the Wireless Uplink">
<t>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. </t>
<t><figure anchor="fig-wireless-bottleneck-multi-flow"
title="Multiple RMCAT Flows Sharing the Wireless Uplink">
<artwork><![CDATA[
uplink
+----------------->+
+----+ +----+
| S1 |)))))) /=====| R1 |
+----+ )) // +----+
)) //
+----+ +----+ +----+ +----+
| S2 |))))))))))| AP |==========| B |========| R2 |
+----+ +----+ +----+ +----+
...... ......
)) \\
+----+ )) \\ +----+
|S16 |)))))) \=====|R16 |
+----+ +----+
+<-----------------+
downlink
]]></artwork>
</figure></t>
<t>Testbed attributes:
<list style="symbols">
<t>Test duratiion: 100s</t>
<t>Path characteristics:
<list style="symbols">
<t>Wired path capacity: 100Mbps</t>
<t>Wi-Fi PHY Rate: 54Mbps (PHY rate)</t>
<t>Maximum end-to-end jitter: 30ms</t>
<t>One-Way propagation delay: 50ms.</t>
<t>Bottleneck queue type: Drop tail.</t>
<t>Bottleneck queue size: 300ms.</t>
<t>Path loss ratio: 0%.</t>
</list></t>
<t>Application characteristics:
<list style="symbols">
<t>Media Traffic:
<list style="symbols">
<t>Media type: Video</t>
<t>Media direction: forward and backward.</t>
<t>Number of media sources: Sixteen (16)</t>
<t>Media timeline:
<list style="symbols">
<t>Start time: 0s.</t>
<t>End time: 99s.</t>
</list></t>
</list></t>
<t>Competing traffic:
<list style="symbols">
<t>Number and Types of sources : Zero (0)</t>
</list></t>
</list></t>
</list></t>
<t>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?).</t>
</section>
<section anchor="sec-4-4"
title="Multiple Bi-Directional RMCAT Flows Sharing the Wireless Bottleneck">
<t>This one differs with previous contention cases
because Wi-Fi share bandwdith between uplink and downlink.</t>
<t><figure anchor="fig-wireless-bidirectional-multi-flow"
title="Multiple Bi-Directional RMCAT Flows Sharing the Wireless Bottleneck">
<artwork><![CDATA[
uplink
+----------------->+
+----+ +----+
| R1 |)))))) /=====| S1 |
+----+ )) // +----+
)) //
...... ......
+----+ +----+ +----+ +----+
| R8 |))))))))))| AP |==========| B |========| S8 |
+----+ +----+ +----+ +----+
...... ......
)) \\
+----+ )) \\ +----+
|S16 |)))))) \=====|R16 |
+----+ +----+
+<-----------------+
downlink
]]></artwork>
</figure></t>
<t>Testbed attributes:
<list style="symbols">
<t>Test duratiion: 100s</t>
<t>Path characteristics:
<list style="symbols">
<t>Wired path capacity: 100Mbps</t>
<t>Wi-Fi PHY Rate: 54Mbps (PHY rate)</t>
<t>One-Way propagation delay: 50ms.</t>
<t>Maximum end-to-end jitter: 30ms</t>
<t>Bottleneck queue type: Drop tail.</t>
<t>Bottleneck queue size: 300ms.</t>
<t>Path loss ratio: 0%.</t>
</list></t>
<t>Application characteristics:
<list style="symbols">
<t>Media Traffic:
<list style="symbols">
<t>Media type: Video</t>
<t>Media direction: forward and backward.</t>
<t>Number of media sources: Sixteen (16), 8 for uplink, 8 for downlink.</t>
<t>Media timeline:
<list style="symbols">
<t>Start time: 0s.</t>
<t>End time: 99s.</t>
</list></t>
</list></t>
<t>Competing traffic:
<list style="symbols">
<t>Number and Types of sources : zero (0)</t>
</list></t>
</list></t>
</list></t>
<t>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?).</t>
</section>
<section anchor="sec-4-5"
title="Multiple RMCAT and TCP Flows Sharing the Wireless Uplink">
<t>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.</t>
<t><figure anchor="fig-wireless-uplink-with-tcp"
title="Multiple RMCAT and TCP Flows Sharing the Wireless Uplink">
<artwork><![CDATA[
uplink
+----------------->+
+----+ +----+
| S1 |)))))) /=====| R1 |
+----+ )) // +----+
)) //
...... ......
+----+ +----+ +----+ +----+
| S8 |))))))))))| |==========| |========| R8 |
+----+ | | | | +----+
| AP | | B |
+--------+ | | | | +--------+
| S1_tcp |))))))| | | |========| R1_tcp |
+--------+ +----+ +----+ +--------+
...... ......
)) \\
+--------+ )) \\ +--------+
| S8_tcp |)))) \=====| R8_tcp |
+--------+ +--------+
+<-----------------+
downlink
]]></artwork>
</figure></t>
<t>Testbed attributes:
<list style="symbols">
<t>Test duratiion: 100s</t>
<t>Path characteristics:
<list style="symbols">
<t>Wired path capacity: 100Mbps</t>
<t>Wi-Fi PHY Rate: 54Mbps (PHY rate)</t>
<t>One-Way propagation delay: 50ms.</t>
<t>Maximum end-to-end jitter: 30ms</t>
<t>Bottleneck queue type: Drop tail.</t>
<t>Bottleneck queue size: 300ms.</t>
<t>Path loss ratio: 0%.</t>
</list></t>
<t>Application characteristics:
<list style="symbols">
<t>Media Traffic:
<list style="symbols">
<t>Media type: Video</t>
<t>Media direction: forward.</t>
<t>Number of media sources: Eigth (8).</t>
<t>Media timeline:
<list style="symbols">
<t>Start time: 0s.</t>
<t>End time: 99s.</t>
</list></t>
</list></t>
<t>Competing traffic:
<list style="symbols">
<t>Type of sources: long-live TCP.</t>
<t>Number of sources : Eight (8)</t>
<t>Traffic direction : forward</t>
<t>Congestion control: Default TCP congestion control [TBD].</t>
<t>Traffic timeline:
<list style="symbols">
<t>Start time: 0s.</t>
<t>End time: 99s.</t>
</list></t>
</list></t>
</list></t>
</list></t>
<t>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?).
</t>
</section>
<section anchor="sec-4-6"
title="Multiple RMCAT and TCP Flows Sharing the Wireless Downlink">
<t>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.</t>
<t><figure anchor="fig-wireless-downlink-with-tcp"
title="Multiple RMCAT and TCP Flows Sharing the Wireless Downlink">
<artwork><![CDATA[
uplink
+----------------->+
+----+ +----+
| R1 |)))))) /=====| S1 |
+----+ )) // +----+
)) //
...... ......
+----+ +----+ +----+ +----+
| R8 |))))))))))| |==========| |========| S8 |
+----+ | | | | +----+
| AP | | B |
+--------+ | | | | +--------+
| R1_tcp |))))))| | | |========| S1_tcp |
+--------+ +----+ +----+ +--------+
...... ......
)) \\
+--------+ )) \\ +--------+
| R8_tcp |)))) \=====| S8_tcp |
+--------+ +--------+
+<-----------------+
downlink
]]></artwork>
</figure></t>
<t>Testbed attributes:
<list style="symbols">
<t>Test duratiion: 100s</t>
<t>Path characteristics:
<list style="symbols">
<t>Wired path capacity: 100Mbps</t>
<t>Wi-Fi PHY Rate: 54Mbps (PHY rate)</t>
<t>One-Way propagation delay: 50ms.</t>
<t>Maximum end-to-end jitter: 30ms</t>
<t>Bottleneck queue type: Drop tail.</t>
<t>Bottleneck queue depth: 300ms.</t>
<t>Path loss ratio: 0%.</t>
</list></t>
<t>Application characteristics:
<list style="symbols">
<t>Media Traffic:
<list style="symbols">
<t>Media type: Video</t>
<t>Media direction: backward.</t>
<t>Number of media sources: Eight (8).</t>
<t>Media timeline:
<list style="symbols">
<t>Start time: 0s.</t>
<t>End time: 99s.</t>
</list></t>
</list></t>
<t>Competing traffic:
<list style="symbols">
<t>Number of sources: Eight (8).</t>
<t>Types of sources : long-lived TCP.</t>
<t>Traffic direction : forward</t>
<t>Congestion control: Default TCP congestion control.</t>
<t>Traffic timeline:
<list style="symbols">
<t>Start time: 0s.</t>
<t>End time: 99s.</t>
</list></t>
</list></t>
</list></t>
</list></t>
<t>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?).</t>
</section>
<section anchor="sec-4-7"
title="Multiple Bi-Directional RMCAT and TCP Flows Sharing the Wireless Bottleneck">
<t>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.</t>
<t><figure anchor="fig-wireless-bidirectional-with-tcp"
title="Multiple Bi-Directional RMCAT and TCP Flows Sharing the Wireless Bottleneck">
<artwork><![CDATA[
uplink
+----------------->+
+----+ +----+
| S1 |)))))) /=====| R1 |
+----+ )) // +----+
)) //
...... ......
+----+ +----+ +----+ +----+
| R8 |))))))))))| |==========| |========| S8 |
+----+ | | | | +----+
| AP | | B |
+--------+ | | | | +--------+
| S1_tcp |))))))| | | |========| R1_tcp |
+--------+ +----+ +----+ +--------+
...... ......
)) \\
+--------+ )) \\ +--------+
| R8_tcp |)))) \=====| S8_tcp |
+--------+ +--------+
+<-----------------+
downlink
]]></artwork>
</figure></t>
<t>Testbed attributes:
<list style="symbols">
<t>Test duratiion: 100s</t>
<t>Path characteristics:
<list style="symbols">
<t>Wired path capacity: 100Mbps</t>
<t>Wi-Fi PHY Rate: 54Mbps (PHY rate)</t>
<t>One-Way propagation delay: 50ms.</t>
<t>Maximum end-to-end jitter: 30ms</t>
<t>Bottleneck queue type: Drop tail.</t>
<t>Bottleneck queue size: 300ms.</t>
<t>Path loss ratio: 0%.</t>
</list></t>
<t>Application characteristics:
<list style="symbols">
<t>Media Traffic:
<list style="symbols">
<t>Media type: Video</t>
<t>Media direction: forward and backward.</t>
<t>Number of media sources: Eight (8). Four (4) forward, Four (4) backward</t>
<t>Media timeline:
<list style="symbols">
<t>Start time: 0s.</t>
<t>End time: 99s.</t>
</list></t>
</list></t>
<t>Competing traffic:
<list style="symbols">
<t>Number of sources : Eight (8). Four (4) forward, Four (4) backward.</t>
<t>Type of sources: long-live TCP.</t>
<t>Traffic direction : forward and backward.</t>
<t>Congestion control: Default TCP congestion control.</t>
<t>Traffic timeline:
<list style="symbols">
<t>Start time: 0s.</t>
<t>End time: 99s.</t>
</list></t>
</list></t>
</list></t>
</list></t>
<t>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?).</t>
</section>
</section>
<section anchor="sec-other-tests"
title=" Other potential test cases">
<section anchor="sec-wifi-roaming"
title ="Wi-Fi Roaming">
<t>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.</t>
</section>
<section anchor="sec-wifi-cellular-switch"
title ="Wi-Fi/Cellular Switch">
<t>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.</t>
</section>
<section anchor="sec-edca-wmm-usage"
title ="EDCA/WMM usage">
<t>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.
</t>
</section>
<section anchor="sec-legacy-effects"
title =" Legacy 802.11b Effects">
<t>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.
</t>
</section>
</section>
<section title="IANA Considerations">
<t>There are no IANA impacts in this memo.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
<!-- RTP related -->
<!--RMCAT related -->
&I-D.ietf-avtcore-rtp-circuit-breakers;
&I-D.ietf-rmcat-eval-criteria;
&I-D.ietf-rmcat-eval-test;
&I-D.ietf-rmcat-cc-requirements;
<reference anchor="I-D.draft-sarker-rmcat-cellular-eval-test-cases"
target="https://tools.ietf.org/html/draft-sarker-rmcat-cellular-eval-test-cases-02">
<front>
<title>Evaluation Test Cases for Interactive Real-Time Media over
Cellular Networks</title>
<author fullname="Zaheduzzaman Sarker" initials="Z" surname="Sarker">
<organization></organization>
</author>
<date />
</front>
</reference>
</references>
<references title="Informative References">
&I-D.ietf-rtcweb-use-cases-and-requirements;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:34:45 |