draft-ietf-rmcat-eval-test-01.txt   draft-ietf-rmcat-eval-test-02.txt 
Network Working Group Z. Sarker Network Working Group Z. Sarker
Internet-Draft Ericsson AB Internet-Draft Ericsson AB
Intended status: Informational V. Singh Intended status: Informational V. Singh
Expires: September 11, 2015 Aalto University Expires: March 11, 2016 Aalto University
X. Zhu X. Zhu
M. Ramalho M. Ramalho
Cisco Systems Cisco Systems
March 10, 2015 September 8, 2015
Test Cases for Evaluating RMCAT Proposals Test Cases for Evaluating RMCAT Proposals
draft-ietf-rmcat-eval-test-01 draft-ietf-rmcat-eval-test-02
Abstract Abstract
The Real-time Transport Protocol (RTP) is used to transmit media in The Real-time Transport Protocol (RTP) is used to transmit media in
multimedia telephony applications, these applications are typically multimedia telephony applications, these applications are typically
required to implement congestion control. The RMCAT working group is required to implement congestion control. The RMCAT working group is
currently working on candidate algorithms for such interactive real- currently working on candidate algorithms for such interactive real-
time multimedia applications. This document describes the test cases time multimedia applications. This document describes the test cases
to be used in the performance evaluation of those candidate to be used in the performance evaluation of those candidate
algorithms. algorithms.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 11, 2015. This Internet-Draft will expire on March 11, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Structure of Test cases . . . . . . . . . . . . . . . . . . . 3 3. Structure of Test cases . . . . . . . . . . . . . . . . . . . 3
4. Recommended Evaluation Settings . . . . . . . . . . . . . . . 7 4. Recommended Evaluation Settings . . . . . . . . . . . . . . . 7
4.1. Evaluation metircs . . . . . . . . . . . . . . . . . . . 7 4.1. Evaluation metircs . . . . . . . . . . . . . . . . . . . 7
4.2. Path characteristics . . . . . . . . . . . . . . . . . . 8 4.2. Path characteristics . . . . . . . . . . . . . . . . . . 8
4.3. Media source . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Media source . . . . . . . . . . . . . . . . . . . . . . 9
5. Basic Test Cases . . . . . . . . . . . . . . . . . . . . . . 10 5. Basic Test Cases . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Variable Available Capacity with Single RMCAT flow . . . 10 5.1. Variable Available Capacity with Single RMCAT flow . . . 10
5.2. Variable Available Capacity with Multiple RMCAT flows . . 12 5.2. Variable Available Capacity with Multiple RMCAT flows . . 13
5.3. Congested Feedback Link with Bi-directional RMCAT flows . 13 5.3. Congested Feedback Link with Bi-directional RMCAT flows . 14
5.4. Competing Flows with Same RMCAT Algorithm . . . . . . . . 16 5.4. Competing Flows with Same RMCAT Algorithm . . . . . . . . 16
5.5. Round Trip Time Fairness . . . . . . . . . . . . . . . . 18 5.5. Round Trip Time Fairness . . . . . . . . . . . . . . . . 19
5.6. RMCAT Flow competing with a long TCP Flow . . . . . . . . 20 5.6. RMCAT Flow competing with a long TCP Flow . . . . . . . . 20
5.7. RMCAT Flow competing with short TCP Flows . . . . . . . . 22 5.7. RMCAT Flow competing with short TCP Flows . . . . . . . . 23
5.8. Media Pause and Resume . . . . . . . . . . . . . . . . . 24 5.8. Media Pause and Resume . . . . . . . . . . . . . . . . . 25
6. Other potential test cases . . . . . . . . . . . . . . . . . 26 6. Other potential test cases . . . . . . . . . . . . . . . . . 26
6.1. Explicit Congestion Notification Usage . . . . . . . . . 26 6.1. Explicit Congestion Notification Usage . . . . . . . . . 26
6.2. Multiple Bottlenecks . . . . . . . . . . . . . . . . . . 26 6.2. Multiple Bottlenecks . . . . . . . . . . . . . . . . . . 26
7. Wireless Access Links . . . . . . . . . . . . . . . . . . . . 28 7. Wireless Access Links . . . . . . . . . . . . . . . . . . . . 29
7.1. Cellular Network Specific Test Cases . . . . . . . . . . 28
7.2. Wi-Fi Network Specific Test Cases . . . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Normative References . . . . . . . . . . . . . . . . . . 29 11.1. Normative References . . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . 30 11.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
skipping to change at page 3, line 14 skipping to change at page 3, line 12
modeling of different path characteristics. It is the intention of modeling of different path characteristics. It is the intention of
this work to capture the consensus of the RMCAT working group this work to capture the consensus of the RMCAT working group
participants regarding the test cases upon which the performance of participants regarding the test cases upon which the performance of
the candidate RMCAT proposals should be evaluated. the candidate RMCAT proposals should be evaluated.
2. Terminology 2. Terminology
The terminology defined in RTP [RFC3550], RTP Profile for Audio and The terminology defined in RTP [RFC3550], RTP Profile for Audio and
Video Conferences with Minimal Control [RFC3551], RTCP Extended Video Conferences with Minimal Control [RFC3551], RTCP Extended
Report (XR) [RFC3611], Extended RTP Profile for RTCP-based Feedback Report (XR) [RFC3611], Extended RTP Profile for RTCP-based Feedback
(RTP/AVPF) [RFC4585], Support for Reduced-Size RTCP [RFC5506], and (RTP/AVPF) [RFC4585], and Support for Reduced-Size RTCP [RFC5506]
RTP Circuit Breaker algorithm [I-D.ietf-avtcore-rtp-circuit-breakers]
apply. apply.
3. Structure of Test cases 3. Structure of Test cases
All test cases in this document follow a basic structure allowing All test cases in this document follow a basic structure allowing
implementers to describe a new test scenario without repeatedly implementers to describe a new test scenario without repeatedly
explaining common attributes. The structure includes a general explaining common attributes. The structure includes a general
description section that describes the test case and its motivation. description section that describes the test case and its motivation.
Additionally the test case defines a set of attributes that Additionally the test case defines a set of attributes that
characterize the testbed, i.e., the network path between characterize the testbed, i.e., the network path between
skipping to change at page 5, line 20 skipping to change at page 5, line 16
applicable to all the Sources "S" sending traffic on that path. applicable to all the Sources "S" sending traffic on that path.
If only one attribute is specified, it is used for both path If only one attribute is specified, it is used for both path
directions, however, unless specified the reverse path has no directions, however, unless specified the reverse path has no
capacity restrictions and no path loss. capacity restrictions and no path loss.
+ Path direction: forward or backward. + Path direction: forward or backward.
+ Bottleneck-link capacity: defines minimum capacity of the + Bottleneck-link capacity: defines minimum capacity of the
end-to-end path end-to-end path
+ Reference bottleneck capacity: defines a reference value for
the bottleneck capacity for test cases with time-varying
bottleneck capacities. All bottleneck capacities will be
specified as a ratio with respect to the reference capacity
value.
+ One-way propagation delay: describes the end-to-end latency + One-way propagation delay: describes the end-to-end latency
along the path when network queues are empty, i.e., the time along the path when network queues are empty, i.e., the time
it takes for a packet to go from the sender to the receiver it takes for a packet to go from the sender to the receiver
without encountering any queuing delay. without encountering any queuing delay.
+ Maximum end-to-end jitter: defines the maximum jitter that + Maximum end-to-end jitter: defines the maximum jitter that
can be observed along the path. can be observed along the path.
+ Bottleneck queue type: for example, Droptail, FQ-CoDel, or + Bottleneck queue type: for example, Droptail, FQ-CoDel, or
PIE. PIE.
skipping to change at page 5, line 50 skipping to change at page 6, line 5
[I-D.ietf-rmcat-eval-criteria]. [I-D.ietf-rmcat-eval-criteria].
* Application-related: defines the traffic source behaviour for * Application-related: defines the traffic source behaviour for
implementing the test case implementing the test case
+ Media traffic Source: defines the characteristics of the + Media traffic Source: defines the characteristics of the
media sources. When using more than one media source, the media sources. When using more than one media source, the
different attributes are enumerated separately for each different attributes are enumerated separately for each
different media source. different media source.
- Media type: Video/Voice/Application/Text - Media type: Video/Voice
- Media flow direction: forward, backward or both. - Media flow direction: forward, backward or both.
- Number of media sources: defines the total number of - Number of media sources: defines the total number of
media sources media sources
- Media codec: Constant Bit Rate (CBR) or Variable Bit Rate - Media codec: Constant Bit Rate (CBR) or Variable Bit Rate
(VBR) (VBR)
- Media source behaviour: describes the media encoder - Media source behaviour: describes the media encoder
skipping to change at page 8, line 34 skipping to change at page 8, line 38
+ median, maximum, minimum + median, maximum, minimum
4.2. Path characteristics 4.2. Path characteristics
Each path between a sender and receiver as described in Figure 1 have Each path between a sender and receiver as described in Figure 1 have
the following characteristics unless otherwise specified in the test the following characteristics unless otherwise specified in the test
case. case.
o Path direction: forward and backward. o Path direction: forward and backward.
o Bottleneck-link capacity: 4Mbps. o Reference bottleneck capacity: 1Mbps.
o One-Way propagation delay: 50ms. It is encouraged to test with o One-Way propagation delay: 50ms. Implementers are encouraged to
additional propagation delays mentioned in run the experiment with additional propagation delays mentioned in
[I-D.ietf-rmcat-eval-criteria] [I-D.ietf-rmcat-eval-criteria]
o Maximum end-to-end jitter: 30ms. Jitter models are described in o Maximum end-to-end jitter: 30ms. Jitter models are described in
[I-D.ietf-rmcat-eval-criteria] [I-D.ietf-rmcat-eval-criteria]
o Bottleneck queue type: Drop tail. It is encouraged to test with o Bottleneck queue type: Drop tail. Implementers are encouraged to
other AQM schemes, such as FQ-CoDel and PIE. run the experiment with other AQM schemes, such as FQ-CoDel and
PIE.
o Bottleneck queue size: 300ms. o Bottleneck queue size: 300ms.
o Path loss ratio: 0%. o Path loss ratio: 0%.
Examples of additional network parameters are discussed in Examples of additional network parameters are discussed in
[I-D.ietf-rmcat-eval-criteria]. [I-D.ietf-rmcat-eval-criteria].
For test cases involving time-varying bottleneck capacity, all
capacity values are specified as a ratio with respect to a reference
capacity value, so as to allow flexible scaling of capacity values
along with media source rate range. There exist two different
mechanisms for inducing path capacity variation: a) by explicitly
modifying the value of physical link capacity; or b) by introducing
background non-adaptive UDP traffic with time-varying traffic rate.
Implementers are encouraged run the experiments with both mechanisms
for test cases specified in Section 5.1, Section 5.2, and
Section 5.3.
4.3. Media source 4.3. Media source
Unless otherwise specified, each test case will include one or more Unless otherwise specified, each test case will include one or more
media sources as described below. media sources as described below.
o Media type: Video o Media type: Video
* Media codec: VBR * Media codec: VBR
* Media source behaviour: * Media source behaviour:
skipping to change at page 10, line 25 skipping to change at page 10, line 42
In this test case the bottleneck-link capacity between the two In this test case the bottleneck-link capacity between the two
endpoints varies over time. This test is designed to measure the endpoints varies over time. This test is designed to measure the
responsiveness of the candidate algorithm. This test tries to responsiveness of the candidate algorithm. This test tries to
address the requirements in [I-D.ietf-rmcat-cc-requirements], which address the requirements in [I-D.ietf-rmcat-cc-requirements], which
requires the algorithm to adapt the flow(s) and provide lower end-to- requires the algorithm to adapt the flow(s) and provide lower end-to-
end latency when there exists: end latency when there exists:
o an intermediate bottleneck o an intermediate bottleneck
o change in available capacity (e.g., due to interface change, o change in available capacity (e.g., due to interface change,
routing change). routing change, abrupt arrival/departure of background non-
adaptive traffic).
o maximum Media Bit Rate is Greater than Link Capacity. In this o maximum Media Bit Rate is Greater than Link Capacity. In this
case, the application will attempt to ramp up to its maximum bit case, the application will attempt to ramp up to its maximum bit
rate, since the link capacity is limited to a value lower, the rate, since the link capacity is limited to a value lower, the
congestion control scheme is expected to stabilize the sending bit congestion control scheme is expected to stabilize the sending bit
rate close to the available bottleneck capacity. This situation rate close to the available bottleneck capacity. This situation
can occur when the endpoints are connected via thin long networks can occur when the endpoints are connected via thin long networks
even though the advertised capacity of the access network may be even though the advertised capacity of the access network may be
higher. higher.
skipping to change at page 12, line 19 skipping to change at page 12, line 34
+ Number of sources : Zero (0) + Number of sources : Zero (0)
o Test Specific Information: o Test Specific Information:
* This test uses the following one way propagation delays of 50 * This test uses the following one way propagation delays of 50
ms and 100 ms. ms and 100 ms.
* This test uses bottleneck path capacity variation as listed in * This test uses bottleneck path capacity variation as listed in
Table 1 Table 1
+---------------------+----------------+------------+---------------+ * When using background non-adaptive UDP traffic to induce time-
| Variation pattern | Path direction | Start time | Path capacity | varying bottleneck for the RMCAT flow, the physical path
| index | | | | capacity is 4Mbps and the UDP traffic source rate changes over
+---------------------+----------------+------------+---------------+ time as (4-x)Mbps, where x is the bottleneck capacity specified
| One | Forward | 0s | 1Mbps | in Table 1
| Two | Forward | 40s | 2.5Mbps |
| Three | Forward | 60s | 600Kbps | +--------------------+--------------+-----------+-------------------+
| Four | Forward | 80s | 1Mbps | | Variation pattern | Path | Start | Path capacity |
+---------------------+----------------+------------+---------------+ | index | direction | time | ratio |
+--------------------+--------------+-----------+-------------------+
| One | Forward | 0s | 1.0 |
| Two | Forward | 40s | 2.5 |
| Three | Forward | 60s | 0.6 |
| Four | Forward | 80s | 1.0 |
+--------------------+--------------+-----------+-------------------+
Table 1: Path capacity variation pattern for forward direction Table 1: Path capacity variation pattern for forward direction
5.2. Variable Available Capacity with Multiple RMCAT flows 5.2. Variable Available Capacity with Multiple RMCAT flows
This test case is similar to Section 5.1. However in addition this This test case is similar to Section 5.1. However in addition this
test will also consider persistent network load due to competing test will also consider persistent network load due to competing
traffic. traffic.
Expected behavior: the candidate algorithms is expected to detect the Expected behavior: the candidate algorithms is expected to detect the
skipping to change at page 13, line 27 skipping to change at page 13, line 50
+---+ +---+ +---+ +---+
Figure 3: Testbed Topology for Variable Available Capacity Figure 3: Testbed Topology for Variable Available Capacity
Testbed attributes: Testbed attributes:
Testbed attributes are similar as described in Section 5.1 except the Testbed attributes are similar as described in Section 5.1 except the
test specific capacity variation setup. test specific capacity variation setup.
Test Specific Information: This test uses path capacity variation as Test Specific Information: This test uses path capacity variation as
listed in Table 2 with a corresponding end time of 125 seconds. listed in Table 2 with a corresponding end time of 125 seconds. The
reference bottleneck capacity is 2Mbps. When using background non-
adaptive UDP traffic to induce time-varying bottleneck for RMCAT
flows, the physical path capacity is 4Mbps and the UDP traffic source
rate changes over time as (4-x)Mbps, where x is the bottleneck
capacity specified in Table 2.
+---------------------+----------------+------------+---------------+ +--------------------+--------------+-----------+-------------------+
| Variation pattern | Path direction | Start time | Path capacity | | Variation pattern | Path | Start | Path capacity |
| index | | | | | index | direction | time | ratio |
+---------------------+----------------+------------+---------------+ +--------------------+--------------+-----------+-------------------+
| One | Forward | 0s | 4Mbps | | One | Forward | 0s | 2.0 |
| Two | Forward | 25s | 2Mbps | | Two | Forward | 25s | 1.0 |
| Three | Forward | 50s | 3.5Mbps | | Three | Forward | 50s | 1.75 |
| Four | Forward | 75s | 1Mbps | | Four | Forward | 75s | 0.5 |
| Five | Forward | 100s | 2Mbps | | Five | Forward | 100s | 1.0 |
+---------------------+----------------+------------+---------------+ +--------------------+--------------+-----------+-------------------+
Table 2: Path capacity variation pattern for forward direction Table 2: Path capacity variation pattern for forward direction
5.3. Congested Feedback Link with Bi-directional RMCAT flows 5.3. Congested Feedback Link with Bi-directional RMCAT flows
RMCAT WG has been chartered to define algorithms for RTP hence it is RMCAT WG has been chartered to define algorithms for RTP hence it is
assumed that RTCP, RTP header extension or such would be used by the assumed that RTCP, RTP header extension or such would be used by the
congestion control algorithm in the backchannel. Due to asymmetric congestion control algorithm in the backchannel. Due to asymmetric
nature of the link between communicating peers it is possible for a nature of the link between communicating peers it is possible for a
participating peer to not receive such feedback information due to an participating peer to not receive such feedback information due to an
skipping to change at page 14, line 25 skipping to change at page 15, line 5
Testbed topology: One (1) media source S1 is connected to Testbed topology: One (1) media source S1 is connected to
corresponding R1, but both endpoints are additionally receiving and corresponding R1, but both endpoints are additionally receiving and
sending data, respectively. The media traffic (S1->R1) is sending data, respectively. The media traffic (S1->R1) is
transported over the forward path and corresponding feedback/control transported over the forward path and corresponding feedback/control
traffic is transported over the backward path. Likewise media traffic is transported over the backward path. Likewise media
traffic (S2->R2) is transported over the backward path and traffic (S2->R2) is transported over the backward path and
corresponding feedback/control traffic is transported over the corresponding feedback/control traffic is transported over the
forward path. forward path.
+---+ +---+ +---+ +---+
|S1 |===== \ Forward --> / =======|R1 | |S1 |===== \ Forward --> / =======|R1 |
+---+ \\ // +---+ +---+ \\ // +---+
\\ // \\ //
+-----+ +-----+ +-----+ +-----+
| A |------------------------------>| B | | A |------------------------------>| B |
| |<------------------------------| | | |<------------------------------| |
+-----+ +-----+ +-----+ +-----+
// \\ // \\
// <-- Backward \\ // <-- Backward \\
+---+ // \\ +---+ +---+ // \\ +---+
|R2 |===== / \ ======|S2 | |R2 |===== / \ ======|S2 |
+---+ +---+ +---+ +---+
Figure 4: Testbed Topology for Congested Feedback Link Figure 4: Testbed Topology for Congested Feedback Link
Testbed attributes: Testbed attributes:
o Test duration: 100s o Test duration: 100s
o Path characteristics: o Path characteristics:
* Bottleneck-link capacity: 2Mbps. * Reference bottleneck capacity: 1Mbps.
o Application-related: o Application-related:
* Media Source: * Media Source:
+ Media type: Video + Media type: Video
- Media direction: forward and backward - Media direction: forward and backward
- Number of media sources: Two (2) - Number of media sources: Two (2)
skipping to change at page 15, line 36 skipping to change at page 16, line 16
o End time: 99s. o End time: 99s.
* Competing traffic: * Competing traffic:
+ Number of sources : Zero (0) + Number of sources : Zero (0)
o Test Specific Information: This test uses path capacity variations o Test Specific Information: This test uses path capacity variations
to create congested feedback link. Table 3 lists the variation to create congested feedback link. Table 3 lists the variation
patterns applied to the forward path and Table 4 lists the patterns applied to the forward path and Table 4 lists the
variation patterns applied to the backward path. variation patterns applied to the backward path. When using
background non-adaptive UDP traffic to induce time-varying
bottleneck for RMCAT flows, the physical path capacity is 4Mbps
for both directions and the UDP traffic source rate changes over
time as (4-x)Mbps in each direction, where x is the bottleneck
capacity specified in Table 4.
+---------------------+----------------+------------+---------------+ +--------------------+--------------+-----------+-------------------+
| Variation pattern | Path direction | Start time | Path capacity | | Variation pattern | Path | Start | Path capacity |
| index | | | | | index | direction | time | ratio |
+---------------------+----------------+------------+---------------+ +--------------------+--------------+-----------+-------------------+
| One | Forward | 0s | 2Mbps | | One | Forward | 0s | 2.0 |
| Two | Forward | 20s | 1Mbps | | Two | Forward | 20s | 1.0 |
| Three | Forward | 40s | 500Kbps | | Three | Forward | 40s | 0.5 |
| Four | Forward | 60s | 2Mbps | | Four | Forward | 60s | 2.0 |
+---------------------+----------------+------------+---------------+ +--------------------+--------------+-----------+-------------------+
Table 3: Path capacity variation pattern for forward direction Table 3: Path capacity variation pattern for forward direction
+---------------------+----------------+------------+---------------+ +--------------------+--------------+-----------+-------------------+
| Variation pattern | Path direction | Start time | Path capacity | | Variation pattern | Path | Start | Path capacity |
| index | | | | | index | direction | time | ratio |
+---------------------+----------------+------------+---------------+ +--------------------+--------------+-----------+-------------------+
| One | Backward | 0s | 2Mbps | | One | Backward | 0s | 2.0 |
| Two | Backward | 35s | 800Kbps | | Two | Backward | 35s | 0.8 |
| Three | Backward | 70s | 2Mbps | | Three | Backward | 70s | 2.0 |
+---------------------+----------------+------------+---------------+ +--------------------+--------------+-----------+-------------------+
Table 4: Path capacity variation pattern for backward direction Table 4: Path capacity variation pattern for backward direction
5.4. Competing Flows with Same RMCAT Algorithm 5.4. Competing Flows with Same RMCAT Algorithm
In this test case, more than one RMCAT media flow shares the In this test case, more than one RMCAT media flow shares the
bottleneck link and each of them uses the same congestion control bottleneck link and each of them uses the same congestion control
algorithm. This is a typical scenario where a real-time interactive algorithm. This is a typical scenario where a real-time interactive
application sends more than one media flows to the same destination application sends more than one media flows to the same destination
and these flows are multiplexed over the same port. In such a and these flows are multiplexed over the same port. In such a
skipping to change at page 17, line 24 skipping to change at page 18, line 4
// <-- Backward \\ // <-- Backward \\
+---+ // \\ +---+ +---+ // \\ +---+
|S3 |====== / \ ======|R3 | |S3 |====== / \ ======|R3 |
+---+ +---+ +---+ +---+
Figure 5: Testbed Topology for Multiple RMCAT Flows Figure 5: Testbed Topology for Multiple RMCAT Flows
Testbed attributes: Testbed attributes:
o Test duration: 120s o Test duration: 120s
o Path characteristics: o Path characteristics:
* Bottleneck-link capacity: 3.5Mbps * Reference bottleneck capacity: 3.5Mbps
* Path capacity ratio: 1.0
o Application-related: o Application-related:
* Media Source: * Media Source:
+ Media type: Video + Media type: Video
- Media direction: forward. - Media direction: forward.
- Number of media sources: Three (3) - Number of media sources: Three (3)
skipping to change at page 21, line 7 skipping to change at page 21, line 27
A. TCP throughput. A. TCP throughput.
Testbed topology: One (1) media source S1 is connected to Testbed topology: One (1) media source S1 is connected to
corresponding media sink, R1. In addition, there is a long-live TCP corresponding media sink, R1. In addition, there is a long-live TCP
flow sharing the same bottleneck link. The media traffic is flow sharing the same bottleneck link. The media traffic is
transported over the forward path and corresponding feedback/control transported over the forward path and corresponding feedback/control
traffic is transported over the backward path. The TCP traffic goes traffic is transported over the backward path. The TCP traffic goes
over the forward path from, S_tcp with acknowledgement packets over the forward path from, S_tcp with acknowledgement packets
flowing along the backward path from, R_tcp. flowing along the backward path from, R_tcp.
+--+ +--+ +--+ +--+
|S1|===== \ Forward --> / =======|R1| |S1|===== \ Forward --> / =======|R1|
+--+ \\ // +--+ +--+ \\ // +--+
\\ // \\ //
+-----+ +-----+ +-----+ +-----+
| A |---------------------------->| B | | A |---------------------------->| B |
| |<----------------------------| | | |<----------------------------| |
+-----+ +-----+ +-----+ +-----+
// \\ // \\
// <-- Backward \\ // <-- Backward \\
+-----+ // \\ +-----+ +-----+ // \\ +-----+
|S_tcp|=== / \ ===|R_tcp| |S_tcp|=== / \ ===|R_tcp|
+-----+ +-----+ +-----+ +-----+
Figure 6: Testbed Topology for TCP vs RMCAT Flows Figure 6: Testbed Topology for TCP vs RMCAT Flows
Testbed attributes: Testbed attributes:
o Test duration: 120s o Test duration: 120s
o Path characteristics: o Path characteristics:
* Bottleneck-link capacity: 2Mbps * Reference bottleneck capacity: 2Mbps
* Bottleneck queue size: [20ms, 300ms, 1000ms] * Path capacity ratio: 1.0
* Bottleneck queue size: [300ms, 1000ms]
o Application-related: o Application-related:
* Media Source: * Media Source:
+ Media type: Video + Media type: Video
- Media direction: forward - Media direction: forward
- Number of media sources: One (1) - Number of media sources: One (1)
skipping to change at page 23, line 22 skipping to change at page 23, line 43
Testbed topology: The topology described here is same as the one Testbed topology: The topology described here is same as the one
described in Figure 6. described in Figure 6.
Testbed attributes: Testbed attributes:
o Test duration: 300s o Test duration: 300s
o Path characteristics: o Path characteristics:
* Bottleneck-link capacity: 2.0Mbps * Reference bottleneck capacity: 2.0Mbps
* Path capacity ratio: 1.0
o Application-related: o Application-related:
* Media Source: * Media Source:
+ Media type: Video + Media type: Video
- Media direction: forward - Media direction: forward
- Number of media sources: two (2) - Number of media sources: two (2)
- Media timeline: - Media timeline:
o Start time: 5s. o Start time: 5s.
o End time: 299s. o End time: 299s.
skipping to change at page 27, line 11 skipping to change at page 27, line 19
Expected behavior: the candidate algorithm is expected to achieve Expected behavior: the candidate algorithm is expected to achieve
full utilization at both bottleneck links without starving any of the full utilization at both bottleneck links without starving any of the
three RMCAT flows. three RMCAT flows.
Forward ----> Forward ---->
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|S2 | |R2 | |S3 | |R3 | |S2 | |R2 | |S3 | |R3 |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| | | | | | | |
| | | | | | | |
+---+ +-----+ +-----+ +-----+ +-----+ +---+ +---+ +-----+ +-----+ +-----+ +-----+ +---+
|S1 |=======| A |------>| B |----->| C |---->| D |=======|R1 | |S1 |=======| A |------>| B |----->| C |---->| D |=======|R1 |
+---+ | |<------| |<-----| |<----| | +---+ +---+ | |<------| |<-----| |<----| | +---+
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
1st 2nd 1st 2nd
Bottleneck (A->B) Bottleneck (C->D) Bottleneck (A->B) Bottleneck (C->D)
<------ Backward <------ Backward
skipping to change at page 27, line 35 skipping to change at page 27, line 43
respective destinations R1, R2, and R3. For all three flows the respective destinations R1, R2, and R3. For all three flows the
media traffic is transported over the forward path and corresponding media traffic is transported over the forward path and corresponding
feedback/control traffic is transported over the backward path. feedback/control traffic is transported over the backward path.
Testbed attributes: Testbed attributes:
o Test duration: 120s o Test duration: 120s
o Path characteristics: o Path characteristics:
* Path capacity between A and B = 2Mbps. * Reference bottleneck capacity between A and B = 2Mbps.
* Path capacity between B and C = 8Mbps. * Path capacity ratio between A and B: 1.0
* Path capacity ratio between B and C: 4.0.
* Path capacity between C and D = 1.5Mbps. * Path capacity ratio between C and D: 0.75.
* One-Way propagation delay: * One-Way propagation delay:
1. Between S1 and R1 : 100ms 1. Between S1 and R1: 100ms
2. Between S2 and R2: 40ms 2. Between S2 and R2: 40ms
3. Between S3 and R3: 40ms 3. Between S3 and R3: 40ms
o Application-related: o Application-related:
* Media Source: * Media Source:
+ Media type: Video + Media type: Video
skipping to change at page 28, line 39 skipping to change at page 29, line 7
o Start time: 0s. o Start time: 0s.
o End time: 119s. o End time: 119s.
* Competing traffic: * Competing traffic:
+ Number of sources : Zero (0) + Number of sources : Zero (0)
7. Wireless Access Links 7. Wireless Access Links
7.1. Cellular Network Specific Test Cases Additional wireless network (both cellular network and WiFi network)
specific test cases are define in [I-D.ietf-rmcat-wireless-tests]
Additional cellular network specific test cases are define in
[I-D.draft-sarker-rmcat-cellular-eval-test-cases]
7.2. Wi-Fi Network Specific Test Cases
TBD
[Editor's Note: We should encourage people to come up with possible
WiFi Network specific test cases]
8. Security Considerations 8. Security Considerations
Security issues have not been discussed in this memo. Security issues have not been discussed in this memo.
9. IANA Considerations 9. IANA Considerations
There are no IANA impacts in this memo. There are no IANA impacts in this memo.
10. Acknowledgements 10. Acknowledgements
skipping to change at page 29, line 27 skipping to change at page 29, line 32
The content and concepts within this document are a product of the The content and concepts within this document are a product of the
discussion carried out in the Design Team. discussion carried out in the Design Team.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN) and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, August 2012. for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
2012, <http://www.rfc-editor.org/info/rfc6679>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. DOI 10.17487/RFC3551, July 2003,
<http://www.rfc-editor.org/info/rfc3551>.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
Protocol Extended Reports (RTCP XR)", RFC 3611, November "RTP Control Protocol Extended Reports (RTCP XR)", RFC
2003. 3611, DOI 10.17487/RFC3611, November 2003,
<http://www.rfc-editor.org/info/rfc3611>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI
2006. 10.17487/RFC4585, July 2006,
<http://www.rfc-editor.org/info/rfc4585>.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009. and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
2009, <http://www.rfc-editor.org/info/rfc5506>.
[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-09 (work in progress), March
2015.
[I-D.ietf-rmcat-eval-criteria] [I-D.ietf-rmcat-eval-criteria]
Singh, V. and J. Ott, "Evaluating Congestion Control for Singh, V. and J. Ott, "Evaluating Congestion Control for
Interactive Real-time Media", draft-ietf-rmcat-eval- Interactive Real-time Media", draft-ietf-rmcat-eval-
criteria-02 (work in progress), July 2014. criteria-03 (work in progress), March 2015.
[I-D.ietf-rmcat-wireless-tests]
Sarker, Z. and I. Johansson, "Evaluation Test Cases for
Interactive Real-Time Media over Wireless Networks",
draft-ietf-rmcat-wireless-tests-00 (work in progress),
June 2015.
11.2. Informative References
[I-D.ietf-rmcat-cc-requirements] [I-D.ietf-rmcat-cc-requirements]
Jesup, R. and Z. Sarker, "Congestion Control Requirements Jesup, R. and Z. Sarker, "Congestion Control Requirements
for Interactive Real-Time Media", draft-ietf-rmcat-cc- for Interactive Real-Time Media", draft-ietf-rmcat-cc-
requirements-09 (work in progress), December 2014. requirements-09 (work in progress), December 2014.
[I-D.draft-sarker-rmcat-cellular-eval-test-cases]
Sarker, Z. and I. Johansson, "Evaluation Test Cases for
Interactive Real-Time Media over Cellular Networks", 6
2014, <http://www.ietf.org/id/
draft-sarker-rmcat-cellular-eval-test-cases-01.txt>.
11.2. Informative References
[xiph-seq] [xiph-seq]
Xiph.org, , "Video Test Media", Xiph.org, , "Video Test Media",
http://media.xiph.org/video/derf/ , . http://media.xiph.org/video/derf/ .
[HEVC-seq] [HEVC-seq]
HEVC, , "Test Sequences", HEVC, , "Test Sequences",
http://www.netlab.tkk.fi/~varun/test_sequences/ , . http://www.netlab.tkk.fi/~varun/test_sequences/ .
Authors' Addresses Authors' Addresses
Zaheduzzaman Sarker Zaheduzzaman Sarker
Ericsson AB Ericsson AB
Luleae, SE 977 53 Luleae, SE 977 53
Sweden Sweden
Phone: +46 10 717 37 43 Phone: +46 10 717 37 43
Email: zaheduzzaman.sarker@ericsson.com Email: zaheduzzaman.sarker@ericsson.com
 End of changes. 47 change blocks. 
134 lines changed or deleted 161 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/