Test Cases for Evaluating RMCAT Proposals

This memo describes a set of test cases for evaluating congestion control algorithm proposals for real-time interactive media. It is based on the guidelines enumerated in and the requirements discussed in . The test cases cover basic usage scenarios and are described using a common structure, which allows for additional test cases to be added to those described herein to accommodate other topologies and/or the modeling of different path characteristics. The described test cases in this memo SHOULD be used to evaluate any proposed congestion control algorithm for real-time interactive media.

The terminology defined in RTP, RTP Profile for Audio and Video Conferences with Minimal Control, RTCP Extended Report (XR), Extended RTP Profile for RTCP-based Feedback (RTP/AVPF), and Support for Reduced-Size RTCP apply.

All the test cases in this document follow a basic structure allowing implementers to describe a new test scenario without repeatedly explaining common attributes. The structure includes a general description section that describes the test case and its motivation. Additionally the test case defines a set of attributes that characterize the testbed, for example, the network path between communicating peers and the diverse traffic sources. Define the test case: General description: describes the motivation and the goals of the test case. Expected behavior: describes the desired rate adaptation behavior. Define a list of metrics to evaluate the desired behavior: this indicates the minimum set of metrics (e.g., link utilization, media sending rate) that a proposed algorithm needs to measure to validate the expected rate adaptation behavior. It should also indicate the time granularity (e.g., averaged over 10ms, 100ms, or 1s) for measuring certain metrics. Typical measurement interval is 200ms. Define testbed topology: every test case needs to define an evaluation testbed topology. shows such an evaluation topology. In this evaluation topology, S1..Sn are traffic sources. These sources generate media traffic and use either congestion control algorithm under investigation. R1..Rn are the corresponding receivers. A test case can have one or more such traffic sources (S) and their corresponding receivers (R). The path from the source to destination is denoted as "forward" and the path from a destination to a source is denoted as "backward". The following basic structure of the test case has been described from the perspective of media generating endpoints attached on the left-hand side of . In this setup, the media flows are transported in forward direction and corresponding feedback/control messages are transported in the backward direction. However, it is also possible to set up the test with media in both forward and backward directions. In that case, unless otherwise specified by the test case, it is expected that the backward path does not introduce any congestion related impairments and has enough capacity to accommodate both media and feedback/control messages. It should be noted that depending on the test cases it is possible to have different path characteristics in either of the directions.

/ =======|R1 | +---+ \\ // +---+ \\ // +---+ +-----+ +-----+ +---+ |S2 |=======| A |------------------------------>| B |=======|R2 | +---+ | |<------------------------------| | +---+ +-----+ +-----+ (...) // \\ (...) // <-- Backward \\ +---+ // \\ +---+ |Sn |====== / \ ======|Rn | +---+ +---+ ]]> In a testbed environment where real equipments are used to create a laboratory, there may exist a significant amount of traffic on portions of the network path between the endpoints that is not desired for the purposes of the tests described in the document. Some of this traffic may be generated by other processes on the endpoints themselves (e.g., discovery protocols) or by other endpoints not presently under test. It is recommended not to route traffic generated by endpoints that are not under test through the test bed and route those traffic generated by the endpoints under test around the bottleneck links specified herein. Define testbed attributes: Duration: defines the duration of the test in seconds. Path characteristics: defines the end-to-end transport level path characteristics of the testbed for a particular test case. Two sets of attributes describe the path characteristics, one for the forward path and the other for the backward path. The path characteristics for a particular path direction is applicable to all the Sources "S" sending traffic on that path. If only one attribute is specified, it is used for both path directions, however, unless specified the reverse path has no capacity restrictions and no path loss. Path direction: forward or backward. Bottleneck-link capacity: defines minimum capacity of the 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 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 without encountering any queuing delay. Maximum end-to-end jitter: defines the maximum jitter that can be observed along the path. Bottleneck queue type: for example, Droptail, FQ-CoDel, or PIE. Bottleneck queue size: defines the size of queue in terms of queuing time when the queue is full (in milliseconds). Path loss ratio: characterizes the non-congested, additive, losses to be generated on the end-to-end path. MUST describe the loss pattern or loss model used to generate the losses. Application-related: defines the traffic source behavior for implementing the test case Media traffic Source: defines the characteristics of the media sources. When using more than one media source, the different attributes are enumerated separately for each different media source. Media type: Video/Voice Media flow direction: forward, backward or both. Number of media sources: defines the total number of media sources Media codec: Constant Bit Rate (CBR) or Variable Bit Rate (VBR) Media source behavior: describes the media encoder behavior. It defines the main parameters that affect the adaptation behavior. This may include but is not limited to: Adaptability: describes the adaptation options. For example, in the case of video it defines the following ranges of adaptation: bit rate, frame rate, video resolution. Similarly, in the case of voice, it defines the range of bit rate adaptation, the sampling rate variation, and the variation in packetization interval. Output variation : for a VBR encoder it defines the encoder output variation from the average target rate over a particular measurement interval. For example, on average the encoder output may vary between 5% to 15% above or below the average target bit rate when measured over a 100 ms time window. The time interval over which the variation is specified must be provided. Responsiveness to a new bit rate request: the lag in time between a new bit rate request from the congestion control algorithm and actual rate changes in encoder output. Depending on the encoder, this value may be specified in absolute time (e.g. 10ms to 1000ms) or other appropriate metric (e.g. next frame interval time). More detailed discussions on expected media source behavior, including those from synthetic video traffic sources, is at . Media content: describes the chosen media sequences; For example, test sequences are available at: and . Media timeline: describes the point when the media source is introduced and removed from the testbed. For example, the media source may start transmitting immediately when the test case begins, or after a few seconds. Startup behavior: the media starts at a defined bit rate, which may be the minimum, maximum bit rate, or a value in between (in Kbps). Competing traffic source: describes the characteristics of the competing traffic source, the different types of competing flows are enumerated in . Traffic direction: forward, backward or both. Type of sources: defines the types of competing traffic sources. Types of competing traffic flows are listed in . For example, the number of TCP flows connected to a web browser, the mean size and distribution of the content downloaded. Number of sources: defines the total number of competing sources of each media type per traffic direction. Congestion control: enumerates the congestion control used by each type of competing traffic. Traffic timeline: describes when the competing traffic starts and ends in the test case. Additional attributes: describes attributes essential for implementing a test case which are not included in the above structure. These attributes MUST be well defined, so that the other implementers of that particular test case are able to implement it easily. Any attribute can have a set of values (enclosed within "[]"). Each member value of such a set MUST be treated as different value for the same attribute. It is desired to run separate tests for each such attribute value. The test cases described in this document follow the above structure.

This section describes recommended test case settings and could be overwritten by the respective test cases.

To evaluate the performance of the candidate algorithms the implementers MUST log enough information to visualize the following metrics at a fine enough time granularity: Flow level: End-to-end delay for the congestion controlled media flow. Variation in sending bit rate and goodput. Mainly observing the frequency and magnitude of oscillations. Packet losses observed at the receiving endpoint. Feedback message overhead. Convergence time - time to reach steady state for the congestion controlled media flow(s). Transport level: Bandwidth utilization. Queue length (milliseconds at specified path capacity): average over the length of the session. 5 and 95 percentile. median, maximum, minimum.

Each path between a sender and receiver as described in have the following characteristics unless otherwise specified in the test case. Path direction: forward and backward. Reference bottleneck capacity: 1Mbps. One-Way propagation delay: 50ms. Implementers are encouraged to run the experiment with additional propagation delays mentioned in Maximum end-to-end jitter: 30ms. Jitter models are described in Bottleneck queue type: Drop tail. Implementers are encouraged to run the experiment with other AQM schemes, such as FQ-CoDel and PIE. Bottleneck queue size: 300ms. Path loss ratio: 0%. Examples of additional network parameters are discussed in . 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 to run the experiments with both mechanisms for test cases specified in , , and .

Unless otherwise specified, each test case will include one or more media sources as described below. Media type: Video Media codec: VBR Media source behavior: Adaptability: Bit rate range: 150 Kbps - 1.5 Mbps. In real-life applications the bit rate range can vary a lot depending on the provided service, for example, the maximum bit rate can be up to 4Mbps. However, for running tests to evaluate the congestion control algorithms it is more important to have a look at how they are reacting to certain amount of bandwidth change. Also it is possible that the media traffic generator used in a particular simulator or testbed is not capable of generating higher bit rate. Hence we have selected a suitable bit rate range typical of consumer-grade video conferencing applications in designing the test case. If a different bit rate range is used in the test cases, then the end-to-end path capacity values will also need to be scaled accordingly. Frame resolution: 144p - 720p (or 1080p). This resolution range is selected based on the bit rate range. If a different bit rate range is used in the test cases then the frame resolution range also need to be selected suitably. Frame rate: 10fps - 30fps. This frame rate range is selected based on the bit rate range. If a different bit rate range is used in the test cases then the frame rate range also need to be adjusted suitably. Variation from target bit rate: +/-5%. Unless otherwise specified in the test case(s), bit rate variation SHOULD be calculated over one (1) second period of time. Responsiveness to new bit rate request: 100ms Media content: The media content should represent a typical video conversational scenario with head and shoulder movement. We recommend to use Foreman video sequence. Media startup behavior: 150Kbps. It should be noted that applications can use smart ways to select an optimal startup bit rate value for a certain network condition. In such cases the candidate proposals MAY show the effectiveness of such smart approach as an additional information for the evaluation process. Media type: Audio Media codec: CBR Media bit rate: 20Kbps

In this test case the bottleneck-link capacity between the two endpoints varies over time. This test is designed to measure the responsiveness of the candidate algorithm. This test tries to address the requirements in , which requires the algorithm to adapt the flow(s) and provide lower end-to-end latency when there exists: an intermediate bottleneck change in available capacity (e.g., due to interface change, routing change, abrupt arrival/departure of background non-adaptive traffic). maximum media bit rate is greater than link capacity. In this case, the application will attempt to ramp up to its maximum bit rate, since the link capacity is limited to a value lower, the congestion control scheme is expected to stabilize the sending bit rate close to the available bottleneck capacity. It should be noted that the exact variation in available capacity due to any of the above depends on the underlying technologies. Hence, we describe a set of known factors, which may be extended to devise a more specific test case targeting certain behaviors in a certain network environment. Expected behavior: the candidate algorithm is expected to detect the path capacity constraint, converges to the bottleneck link's capacity and adapt the flow to avoid unwanted oscillation when the sending bit rate is approaching the bottleneck link's capacity. The oscillations occur when the media flow(s) attempts to reach its maximum bit rate but overshoots the usage of the available bottleneck capacity then to rectify, it reduces the bit rate and starts to ramp up again. Evaluation metrics : as described in . Testbed topology: One media source S1 is connected to the corresponding R1. The media traffic is transported over the forward path and corresponding feedback/control traffic is transported over the backward path.

+---+ +-----+ +-----+ +---+ |S1 |=======| A |------------------------------>| B |=======|R1 | +---+ | |<------------------------------| | +---+ +-----+ +-----+ <-- Backward ]]> Testbed attributes: Test duration: 100s Path characteristics: as described in Application-related: Media Traffic: Media type: Video Media direction: forward. Number of media sources: one (1) Media timeline: Start time: 0s. End time: 99s. Media type: Audio Media direction: forward. Number of media sources: one (1) Media timeline: Start time: 0s. End time: 99s. Competing traffic: Number of sources : zero (0) Test Specific Information: One-way propagation delay: [ 50 ms, 100 ms]. on the forward path direction This test uses bottleneck path capacity variation as listed in When using background non-adaptive UDP traffic to induce time-varying bottleneck , the physical path capacity remains at 4Mbps and the UDP traffic source rate changes over time as (4-x)Mbps, where x is the bottleneck capacity specified in Variation pattern index Path direction Start time Path capacity ratio One Forward 0s 1.0 Two Forward 40s 2.5 Three Forward 60s 0.6 Four Forward 80s 1.0

This test case is similar to . However in addition this test will also consider persistent network load due to competing traffic. Expected behavior: the candidate algorithm is expected to detect the variation in available capacity and adapt the media stream(s) accordingly. The flows stabilize around their maximum bit rate as the maximum link capacity is large enough to accommodate the flows. When the available capacity drops, the flows adapt by decreasing their sending bit rate, and when congestion disappears, the flows are again expected to ramp up. Evaluation metrics : as described in . Testbed Topology: Two (2) media sources S1 and S2 are connected to their corresponding destinations R1 and R2. The media traffic is transported over the forward path and corresponding feedback/control traffic is transported over the backward path.

// +---+ \\ // +-----+ +-----+ | A |------------------------------>| B | | |<------------------------------| | +-----+ +-----+ // \\ // <-- Backward \\ +---+ // \\ +---+ |S2 |====== / \ ======|R2 | +---+ +---+ ]]> Testbed attributes: Testbed attributes are similar as described in except the test specific capacity variation setup. Test Specific Information: This test uses path capacity variation as listed in 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 congestion controlled media 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 . Variation pattern index Path direction Start time Path capacity ratio One Forward 0s 2.0 Two Forward 25s 1.0 Three Forward 50s 1.75 Four Forward 75s 0.5 Five Forward 100s 1.0

Real-time interactive media uses RTP hence it is assumed that RTCP, RTP header extension or such would be used by the congestion control algorithm in the backchannel. Due to asymmetric nature of the link between communicating peers it is possible for a participating peer to not receive such feedback information due to an impaired or congested backchannel (even when the forward channel might not be impaired). This test case is designed to observe the candidate congestion control behavior in such an event. It is expected that the candidate algorithms are able to cope with the lack of feedback information and adapt to minimize the performance degradation of media flows in the forward channel. It should be noted that for this test case: logs are compared with the reference case, i.e, when the backward channel has no impairments. Evaluation metrics : as described in . Testbed topology: One (1) media source S1 is connected to corresponding R1, but both endpoints are additionally receiving and sending data, respectively. The media traffic (S1->R1) is transported over the forward path and corresponding feedback/control traffic is transported over the backward path. Likewise media traffic (S2->R2) is transported over the backward path and corresponding feedback/control traffic is transported over the forward path.

/ =======|R1 | +---+ \\ // +---+ \\ // +-----+ +-----+ | A |------------------------------>| B | | |<------------------------------| | +-----+ +-----+ // \\ // <-- Backward \\ +---+ // \\ +---+ |R2 |===== / \ ======|S2 | +---+ +---+ ]]> Testbed attributes: Test duration: 100s Path characteristics: Reference bottleneck capacity: 1Mbps. Application-related: Media Source: Media type: Video Media direction: forward and backward Number of media sources: two (2) Media timeline: Start time: 0s. End time: 99s. Media type: Audio Media direction: forward and backward Number of media sources: two (2) Media timeline: Start time: 0s. End time: 99s. Competing traffic: Number of sources : zero (0) Test Specific Information: this test uses path capacity variations to create congested feedback link. lists the variation patterns applied to the forward path and lists the variation patterns applied to the backward path. When using background non-adaptive UDP traffic to induce time-varying bottleneck for congestion controlled media 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 . Variation pattern index Path direction Start time Path capacity ratio One Forward 0s 2.0 Two Forward 20s 1.0 Three Forward 40s 0.5 Four Forward 60s 2.0 Variation pattern index Path direction Start time Path capacity ratio One Backward 0s 2.0 Two Backward 35s 0.8 Three Backward 70s 2.0

In this test case, more than one media flows share the bottleneck link and each of them uses the same congestion control algorithm. This is a typical scenario where a real-time interactive application sends more than one media flow to the same destination and these flows are multiplexed over the same port. In such a scenario it is likely that the flows will be routed via the same path and need to share the available bandwidth amongst themselves. For the sake of simplicity it is assumed that there are no other competing traffic sources in the bottleneck link and that there is sufficient capacity to accommodate all the flows individually. While this appears to be a variant of the test case defined in , it focuses on the capacity sharing aspect of the candidate algorithm. The previous test case, on the other hand, measures adaptability, stability, and responsiveness of the candidate algorithm. Expected behavior: It is expected that the competing flows will converge to an optimum bit rate to accommodate all the flows with minimum possible latency and loss. Specifically, the test introduces three media flows at different time instances, when the second flow appears there should still be room to accommodate another flow on the bottleneck link. Lastly, when the third flow appears the bottleneck link should be saturated. Evaluation metrics : as described in . Testbed topology: Three media sources S1, S2, S3 are connected to R1, R2, R3 respectively. The media traffic is transported over the forward path and corresponding feedback/control traffic is transported over the backward path.

In this test case, multiple media flows share the bottleneck link, but the end-to-end path latency for each flow is different. For the sake of simplicity it is assumed that there are no other competing traffic sources in the bottleneck link and that there is sufficient capacity to accommodate all the flows. While this appears to be a variant of test case 5.2, it focuses on the capacity sharing aspect of the candidate algorithm under different RTTs. It is expected that the competing flows will converge to bit rates to accommodate all the flows with minimum possible latency and loss. Specifically, the test introduces five media flows at the same time instance. Evaluation metrics : as described in . Testbed Topology: Five (5) media sources S1,S2,..,S5 are connected to their corresponding media sinks R1,R2,..,R5. The media traffic is transported over the forward path and corresponding feedback/control traffic is transported over the backward path. The topology is the same as in . The end-to-end path delays are: 10ms for S1-R1, 25ms for S2-R2, 50ms for S3-R3, 100ms for S4-R4, and 150ms S5-R5, respectively. Testbed attributes: Test duration: 300s Path characteristics: One-Way propagation delay for each flow: 10ms, 25ms, 50ms, 100ms, 150ms. Application-related: Media Source: Media type: Video Media direction: forward Number of media sources: five (5) Media timeline: new media flows are added sequentially, at short time intervals. See test specific setup below. Media type: Audio Media direction: forward. Number of media sources: five (5) Media timeline: new media flows are added sequentially, at short time intervals. See test specific setup below. Competing traffic: Number of sources : zero (0) Test Specific Information: defines the media timeline for both media type. Flow IF Media type Start time End time 1 Video 0s 299s 2 Video 10s 299s 3 Video 20s 299s 4 Video 30s 299s 5 Video 40s 299s 6 Audio 0 299s 7 Audio 10s 299s 8 Audio 20s 299s 9 Audio 30s 299s 10 Audio 40s 299s

In this test case, one or more media flows share the bottleneck link with at least one long lived TCP flow. Long lived TCP flows download data throughout the session and are expected to have infinite amount of data to send and receive. This is a scenario where a multimedia application co-exists with a large file download. The test case measures the adaptivity of the candidate algorithm to competing traffic. It addresses the requirement 3 in . Expected behavior: depending on the convergence observed in test case 5.1 and 5.2, the candidate algorithm may be able to avoid congestion collapse. In the worst case, the media stream will fall to the minimum media bit rate. Evaluation metrics : following metrics in addition to as described in . Flow level: TCP throughput. Loss for the TCP flow Testbed topology: One (1) media source S1 is connected to the corresponding media sink, R1. In addition, there is a long-live TCP flow sharing the same bottleneck link. The media traffic is transported over the forward path and corresponding feedback/control traffic is transported over the backward path. The TCP traffic goes over the forward path from, S_tcp with acknowledgment packets go over the backward path from, R_tcp.

/ =======|R1| +--+ \\ // +--+ \\ // +-----+ +-----+ | A |---------------------------->| B | | |<----------------------------| | +-----+ +-----+ // \\ // <-- Backward \\ +-----+ // \\ +-----+ |S_tcp|=== / \ ===|R_tcp| +-----+ +-----+ ]]> Testbed attributes: Test duration: 120s Path characteristics: Reference bottleneck capacity: 2Mbps Path capacity ratio: 1.0 Bottleneck queue size: [300ms, 1000ms] Application-related: Media Source: Media type: Video Media direction: forward Number of media sources: one (1) Media timeline: Start time: 5s. End time: 119s. Media type: Audio Media direction: forward Number of media sources: one (1) Media timeline: Start time: 5s. End time: 119s. Additionally, implementers are encouraged to run the experiment with multiple media sources. Competing traffic: Number and Types of sources : one (1) and long-lived TCP Traffic direction : forward Congestion control: default TCP congestion control. Traffic timeline: Start time: 0s. End time: 119s. Test Specific Information: none

In this test case, one or more congestion controlled media flow shares the bottleneck link with multiple short-lived TCP flows. Short-lived TCP flows resemble the on/off pattern observed in the web traffic, wherein clients (browsers) connect to a server and download a resource (typically a web page, few images, text files, etc.) using several TCP connections (up to 4). This scenario shows the performance of a multimedia application when several browser windows are active. The test case measures the adaptivity of the candidate algorithm to competing web traffic, it addresses the requirements 1.E in . Depending on the number of short TCP flows, the cross-traffic either appears as a short burst flow or resembles a long TCP flow. The intention of this test is to observe the impact of short-term burst on the behavior of the candidate algorithm. Evaluation metrics : following metrics in addition to as described in . Flow level: Variation in the sending rate of the TCP flow. TCP throughput. Testbed topology: The topology described here is same as the one described in . Testbed attributes: Test duration: 300s Path characteristics: Reference bottleneck capacity: 2.0Mbps Path capacity ratio: 1.0 Application-related: Media source: Media type: Video Media direction: forward Number of media sources: two (2) Media timeline: Start time: 5s. End time: 299s. Media type: Audio Media direction: forward Number of media sources: two (2) Media timeline: Start time: 5s. End time: 299s. Competing traffic: Number and Types of sources : ten (10), short-lived TCP flows. Traffic direction : forward Congestion algorithm: default TCP Congestion control . Traffic timeline: each short TCP flow is modeled as a sequence of file downloads interleaved with idle periods. See test specific setup. Not all short TCP flows start at the same time, 2 of them start in the ON state while rest on the 8 flows start in an OFF stats. The model for the idle times for the OFF state is discussed in . Test Specific Information: Short-TCP traffic model: File sizes: uniform distribution between 100KB to 1MB Idle period: the duration of the OFF state is derived from an exponential distribution with the mean value of 10 seconds.

In this test case, more than one real-time interactive media flows share the link bandwidth and all flows reach to a steady state by utilizing the link capacity in an optimum way. At this stage one of the media flows is paused for a moment. This event will result in more available bandwidth for the rest of the flows as they are on a shared link. When the paused media flow resumes it would no longer have the same bandwidth share on the link. It has to make it's way through the other existing flows in the link to achieve a fair share of the link capacity. This test case is important specially for real-time interactive media which consists of more than one media flows and can pause/resume media flows at any point of time during the session. This test case directly addresses the requirement number 5 in . One can think it as a variation of test case defined in . However, it is different as the candidate algorithms can use different strategies to increase its efficiency, for example in terms of fairness, convergence time, reduce oscillation etc, by capitalizing the fact that they have previous information of the link. Evaluation metrics : following metrics in addition to as described in . Flow level: Variation in sending bit rate and goodput. Mainly observing the frequency and magnitude of oscillations. Testbed Topology: Same as test case defined in Testbed attributes: The general description of the testbed parameters are same as with changes in the test specific setup as below- Other test specific setup: Media flow timeline: Flow ID: one (1) Start time: 0s Flow duration: 119s Pause time: not required Resume time: not required Media flow timeline: Flow ID: two (2) Start time: 0s Flow duration: 119s Pause time: at 40s Resume time: at 60s Media flow timeline: Flow ID: three (3) Start time: 0s Flow duration:119s Pause time: not required Resume time: not required

It has been noticed that there are other interesting test cases besides the basic test cases listed above. In many aspects, these additional test cases can help further evaluation of the candidate algorithm. They are listed as below.

In this test case media flows will have different priority levels. This will be an extension of where the same test will be run with different priority levels imposed on each of the media flows. For example, the first flow (S1) is assigned a priority of 2 whereas the remaining two flows (S2 and S3) are assigned a priority of 1. The candidate algorithm MUST reflect the relative priorities assigned to each media flow. In the previous example, the first flow (S1) MUST arrive at a steady-state rate approximately twice of that of the other two flows (S2 and S3). The candidate algorithm can use a coupled congestion control mechanism for the bandwidth distribution according to the respective media flow priority.

This test case requires to run all the basic test cases with the availability of Explicit Congestion Notification (ECN) feature enabled. The goal of this test is to exhibit that the candidate algorithms do not fail when ECN signals are available. With ECN signals enabled the algorithms are expected to perform better than their delay based variants.

In this test case one congestion controlled media flow, S1->R2, traverses a path with multiple bottlenecks. As illustrated in , the first flow (S1->R1) competes with the second congestion controlled media flow (S2->R2) over the link between A and B which is close to the sender side; again, that flow (S1->R1) competes with the third congestion controlled media flow (S3->R3) over the link between C and D which is close to the receiver side. The goal of this test is to ensure that the candidate algorithms work properly in the presence of multiple bottleneck links on the end to end path. Expected behavior: the candidate algorithm is expected to achieve full utilization at both bottleneck links without starving any of the three congestion controlled media flows.

+---+ +---+ +---+ +---+ |S2 | |R2 | |S3 | |R3 | +---+ +---+ +---+ +---+ | | | | | | | | +---+ +-----+ +-----+ +-----+ +-----+ +---+ |S1 |=======| A |------>| B |----->| C |---->| D |=======|R1 | +---+ | |<------| |<-----| |<----| | +---+ +-----+ +-----+ +-----+ +-----+ 1st 2nd Bottleneck (A->B) Bottleneck (C->D) <------ Backward ]]> Testbed topology: Three media sources S1, S2, and S3 are connected to respective destinations R1, R2, and R3. For all three flows the media traffic is transported over the forward path and corresponding feedback/control traffic is transported over the backward path. Testbed attributes: Test duration: 300s Path characteristics: Reference bottleneck capacity: 2Mbps. Path capacity ratio between A and B: 1.0 Path capacity ratio between B and C: 4.0. Path capacity ratio between C and D: 0.75. One-Way propagation delay: Between S1 and R1: 100ms Between S2 and R2: 40ms Between S3 and R3: 40ms Application-related: Media Source: Media type: Video Media direction: Forward Number of media sources: Three (3) Media timeline: Start time: 0s. End time: 299s. Media type: Audio Media direction: Forward Number of media sources: Three (3) Media timeline: Start time: 0s. End time: 299s. Competing traffic: Number of sources : Zero (0)

Additional wireless network (both cellular network and WiFi network) specific test cases are defined in .

Security issues have not been discussed in this memo.

There are no IANA impacts in this memo.

Much of this document is derived from previous work on congestion control at the IETF. The content and concepts within this document are a product of the discussion carried out in the Design Team.