Define the test case:

General description:

describes the motivation and the goals of the test case.

Expected behavior:

describes the desired rate adaptation behavior.

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 10 ms, 100 ms, or 1 s) for measuring certain metrics. Typical measurement interval is 200 ms.

Define testbed topology:

Every test case needs to define an evaluation testbed topology. Figure 1 shows such an evaluation topology. In this evaluation topology, S1..Sn are traffic sources. These sources generate media traffic and use the congestion control algorithm(s) 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 Figure 1. In this setup, the media flows are transported in the forward direction, and the 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.

+---+                                                        +---+
|S1 |====== \               Forward -->             / =======|R1 |
+---+       \\                                     //        +---+
             \\                                   //
+---+       +-----+                            +-----+       +---+
|S2 |=======|  A  |--------------------------->|  B  |=======|R2 |
+---+       |     |<---------------------------|     |       +---+
            +-----+                            +-----+
(...)         //                                  \\         (...)
             //          <-- Backward              \\
+---+       //                                      \\       +---+
|Sn |====== /                                        \ ======|Rn |
+---+                                                        +---+

Figure 1: Example of a Testbed Topology

In a testbed environment with real equipment, there may exist a significant amount of unwanted traffic on the portions of the network path between the endpoints. 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. Such unwanted traffic should be removed or avoided to the greatest extent possible.

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 are 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.

Minimum bottleneck-link capacity:

defines the 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, "tail drop" [RFC 7567], Flow Queue Controlled Delay (FQ-CoDel) [RFC 8290], or Proportional Integral controller Enhanced (PIE) [RFC 8033].

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. This 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 the following:

Adaptability:

describes the adaptation options. For example, in the case of video, it defines the following ranges of adaptation: bit rate, frame rate, and 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., 10 ms to 1000 ms) 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, can be found in [RFC 8593].

Media content:

describes the chosen video scenario. For example, video test sequences are available at [xiph-seq] and [HEVC-seq]. Different video scenarios give different distributions of video frames produced by the video encoder. Hence, it is important to specify the media content used in a particular test. If a synthetic video traffic source [RFC 8593] is used, then the synthetic video traffic source needs to be configured according to the characteristics of the media content specified.

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 [RFC 8868].

Traffic direction:

forward, backward, or both.

Type of sources:

defines the types of competing traffic sources. Types of competing traffic flows are listed in [RFC 8868]. 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 that 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.

1. Flow level:
   1. End-to-end delay for the congestion-controlled media flow(s). For example, end-to-end delay observed on the IP packet level and the video frame level.
   2. Variation in sending bit rate and throughput. Mainly observing the frequency and magnitude of oscillations.
   3. Packet losses observed at the receiving endpoint.
   4. Feedback message overhead.
   5. Convergence time. Time to reach steady state for the congestion-controlled media flow(s). Each occurrence of convergence during the test period needs to be presented.
2. Transport level:
   1. Bandwidth utilization.
   2. Queue length (milliseconds at specified path capacity).

Path direction:

forward and backward.

Reference bottleneck capacity:

1 Mbps.

One-way propagation delay:

50 ms. Implementers are encouraged to run the experiment with additional propagation delays mentioned in [RFC 8868].

Maximum end-to-end jitter:

30 ms. Jitter models are described in [RFC 8868].

Bottleneck queue type:

"tail drop". Implementers are encouraged to run the experiment with other Active Queue Management (AQM) schemes, such as FQ-CoDel and PIE.

Bottleneck queue size:

300 ms.

Path loss ratio:

0%.

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 4 Mbps. However, for running tests to evaluate the congestion control algorithms, it is more important to have a look at how they react to a 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 a 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 a suitable frame resolution range also needs to be selected.

Frame rate:

10 fps - 30 fps. 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 needs to be suitably adjusted.

Variation from target bit rate:

+/-5%. Unless otherwise specified in the test case(s), bit rate variation should be calculated over a one (1) second period of time.

Responsiveness to new bit rate request:

100 ms

Media content:

The media content should represent a typical video conversational scenario with head and shoulder movement. We recommend using the Foreman video sequence [xiph-seq].

Media startup behavior:

150 Kbps. 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 a smart approach as additional information for the evaluation process.

Media type:

Audio

Media codec:

CBR

Media bit rate:

20 Kbps

• 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, when the application tries to ramp up to its maximum bit rate, since the link capacity is limited to a lower value, the congestion control scheme is expected to stabilize the sending bit rate close to the available bottleneck capacity.

Expected behavior:

The candidate algorithm is expected to detect the path capacity constraint, converge to the bottleneck link's capacity, and adapt the flow to avoid unwanted media rate oscillation when the sending bit rate is approaching the bottleneck link's capacity. Such oscillations might 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 Section 4.1.

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.

                             Forward -->
+---+       +-----+                               +-----+       +---+
|S1 |=======|  A  |------------------------------>|  B  |=======|R1 |
+---+       |     |<------------------------------|     |       +---+
            +-----+                               +-----+
                          <-- Backward

Testbed attributes:

Test duration:

100 s

Path characteristics:

as described in Section 4.2

Application-related:

Media Traffic:

Media type:

Video

Media direction:

forward

Number of media sources:

one (1)

Media timeline:

Start time:

0 s

End time:

99 s

Media type:

Audio

Media direction:

forward

Number of media sources:

one (1)

Media timeline:

Start time:

0 s

End time:

99 s

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 Table 1.

When using background non-adaptive UDP traffic to induce a time-varying bottleneck, the physical path capacity remains at 4 Mbps, and the UDP traffic source rate changes over time as (4 - (Y x r)), where r is the Reference bottleneck capacity in Mbps, and Y is the path capacity ratio specified in Table 1.

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 Section 4.1.

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.

+---+                                                         +---+
|S1 |===== \                                         / =======|R1 |
+---+      \\             Forward -->               //        +---+
            \\                                     //
            +-----+                               +-----+
            |  A  |------------------------------>|  B  |
            |     |<------------------------------|     |
            +-----+                               +-----+
              //                                    \\
             //          <-- Backward                \\
+---+       //                                        \\       +---+
|S2 |====== /                                          \ ======|R2 |
+---+                                                          +---+

Testbed attributes:

Testbed attributes are similar to those described in Section 5.1, except for the test-specific capacity variation setup.

Test-specific information:

This test uses path capacity variation as listed in Table 2 with a corresponding end time of 125 seconds. The reference bottleneck capacity is 2 Mbps. When using background non-adaptive UDP traffic to induce time-varying bottleneck for congestion-controlled media flows, the physical path capacity is 4 Mbps, and the UDP traffic source rate changes over time as (4 - (Y x r)), where r is the Reference bottleneck capacity in Mbps, and Y is the path capacity ratio specified in Table 2.

Expected behavior:

It is expected that the candidate algorithms are able to cope with the lack of feedback information and to 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 Section 4.1.

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 the corresponding feedback/control traffic is transported over the backward path. Likewise, media traffic (S2->R2) is transported over the backward path, and the corresponding feedback/control traffic is transported over the forward path.

+---+                                                          +---+
|S1 |====== \                Forward -->              / =======|R1 |
+---+       \\                                       //        +---+
             \\                                     //
       	  +-----+                               +-----+
          |  A  |------------------------------>|  B  |
          |     |<------------------------------|     |
          +-----+                               +-----+
             //                                     \\
            //            <-- Backward               \\
+---+      //                                         \\       +---+
|R2 |===== /                                           \ ======|S2 |
+---+                                                          +---+
	

Testbed attributes:

Test duration:

100 s

Path characteristics:

Reference bottleneck capacity:

1 Mbps

Application-related:

Media source:

Media type:

Video

Media direction:

forward and backward

Number of media sources:

two (2)

Media timeline:

Start time:

0 s

End time:

99 s

Media type:

Audio

Media direction:

forward and backward

Number of media sources:

two (2)

Media timeline:

Start time:

0 s

End time:

99 s

Competing traffic:

Number of sources:

zero (0)

Test-specific information:

This test uses path capacity variations to create a congested feedback link. Table 3 lists the variation patterns applied to the forward path, and Table 4 lists the variation patterns applied to the backward path. When using background non-adaptive UDP traffic to induce a time-varying bottleneck for congestion-controlled media flows, the physical path capacity is 4 Mbps 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.

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 Section 4.1.

Testbed topology:

Three media sources S1, S2, and S3 are connected to R1, R2, and R3, respectively. The media traffic is transported over the forward path, and the corresponding feedback/control traffic is transported over the backward path.

+---+                                                         +---+
|S1 |===== \                Forward -->              / =======|R1 |
+---+      \\                                       //        +---+
            \\                                     //
+---+       +-----+                               +-----+       +---+
|S2 |=======|  A  |------------------------------>|  B  |=======|R2 |
+---+       |     |<------------------------------|     |       +---+
            +-----+                               +-----+
            //          <-- Backward               \\
+---+      //                                       \\       +---+
|S3 |===== /                                         \ ======|R3 |
+---+                                                        +---+

Testbed attributes:

Test duration:

120 s

Path characteristics:

Reference bottleneck capacity:

3.5 Mbps

Path capacity ratio:

1.0

Application-related:

Media Source:

Media type:

Video

Media direction:

forward

Number of media sources:

three (3)

Media timeline:

New media flows are added sequentially, at short time intervals. See the test-specific setup below.

Media type:

Audio

Media direction:

forward

Number of media sources:

three (3)

Media timeline:

New media flows are added sequentially, at short time intervals. See the test-specific setup below.

Competing traffic:

Number of sources:

zero (0)

Test-specific information:

Table 5 defines the media timeline for both media types.

Expected behavior:

It is expected that the competing flows will converge to bit rates to accommodate all the flows with minimum possible latency and loss. The effectiveness of the algorithm depends on how fast and fairly the competing flows converge to their steady states irrespective of the RTT observed.

Evaluation metrics:

As described in Section 4.1.

Testbed topology:

Five (5) media sources S1..S5 are connected to their corresponding media sinks R1..R5. The media traffic is transported over the forward path, and the corresponding feedback/control traffic is transported over the backward path. The topology is the same as in Section 5.4.

Testbed attributes:

Test duration:

300 s

Path characteristics:

Reference bottleneck capacity:

4 Mbps

Path capacity ratio:

1.0

One-way propagation delay for each flow:

10 ms for S1-R1, 25 ms for S2-R2, 50 ms for S3-R3, 100 ms for S4-R4, and 150 ms S5-R5.

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 the 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 the test-specific setup below.

Competing traffic:

Number of sources:

zero (0)

Test-specific information:

Table 6 defines the media timeline for both media types.

Expected behavior:

Depending on the convergence observed in test cases 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:

Includes the following metrics in addition to those described in Section 4.1:

1. Flow level:
   1. TCP throughput
   2. 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-lived TCP flow sharing the same bottleneck link. The media traffic is transported over the forward path, and the corresponding feedback/control traffic is transported over the backward path. The TCP traffic goes over the forward path from S_tcp with acknowledgment packets going over the backward path from R_tcp.

 +--+                                                     +--+
 |S1|===== \              Forward -->              / =====|R1|
 +--+      \\                                     //      +--+
            \\                                   //
       	    +-----+                             +-----+
       	    |  A  |---------------------------->|  B  |
       	    |     |<----------------------------|     |
       	    +-----+                             +-----+
            //        <-- Backward               \\
+-----+    //                                     \\    +-----+
|S_tcp|=== /                                       \ ===|R_tcp|
+-----+                                                 +-----+

Testbed attributes:

Test duration:

120 s

Path characteristics:

Reference bottleneck capacity:

2 Mbps

Path capacity ratio:

1.0

Bottleneck queue size:

[300 ms, 1000 ms]

Application-related:

Media source:

Media type:

Video

Media direction:

forward

Number of media sources:

one (1)

Media timeline:

Start time:

5 s

End time:

119 s

Media type:

Audio

Media direction:

forward

Number of media sources:

one (1)

Media timeline:

Start time:

5 s

End time:

119 s

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 [RFC 5681]. Implementers are also encouraged to run the experiment with alternative TCP congestion control algorithms.

Traffic timeline:

Start time:

0 s

End time:

119 s

Test-specific information:

none

Expected behavior:

The candidate algorithm is expected to avoid flow starvation during the presence of short and bursty competing TCP flows, streaming at least at the minimum media bit rate. After competing TCP flows terminate, the media streams are expected to be robust enough to eventually recover to previous steady state behavior, and at the very least, avoid persistent starvation.

Evaluation metrics:

Includes the following metrics in addition to those described in Section 4.1:

1. Flow level:
   1. Variation in the sending rate of the TCP flow
   2. TCP throughput

Testbed topology:

The topology described here is the same as the one described in Figure 6.

Testbed attributes:

Test duration:

300 s

Path characteristics:

Reference bottleneck capacity:

2.0 Mbps

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:

5 s

End time:

299 s

Media type:

Audio

Media direction:

forward

Number of media sources:

two (2)

Media timeline:

Start time:

5 s

End time:

299 s

Competing traffic:

Number and types of sources:

ten (10), short-lived TCP flows.

Traffic direction:

forward

Congestion algorithm:

default TCP congestion control [RFC 5681]. Implementers are also encouraged to run the experiment with an alternative TCP congestion control algorithm.

Traffic timeline:

Each short TCP flow is modeled as a sequence of file downloads interleaved with idle periods. Not all short TCP flows start at the same time, two of them start in the ON state, while rest of the eight flows start in an OFF state. For a description of the short TCP flow model, see test-specific information below.

Test-specific information:

Short TCP traffic model:

The short TCP model to be used in this test is described in [RFC 8868].

Expected behavior:

During the period where the third stream is paused, the two remaining flows are expected to increase their rates and reach the maximum media bit rate. When the third stream resumes, all three flows are expected to converge to the same original fair share of rates prior to the media pause/resume event.

Evaluation metrics:

Includes the following metrics in addition to those described in Section 4.1:

1. Flow level:
   1. Variation in sending bit rate and throughput. Mainly observing the frequency and magnitude of oscillations.

Testbed topology:

Same as the test case defined in Section 5.4.

Testbed attributes:

The general description of the testbed parameters are the same as Section 5.4 with changes in the test-specific setup as below:

Other test-specific setup:

Media flow timeline:

Flow ID:

one (1)

Start time:

0 s

Flow duration:

119 s

Pause time:

not required

Resume time:

not required

Media flow timeline:

Flow ID:

two (2)

Start time:

0 s

Flow duration:

119 s

Pause time:

at 40 s

Resume time:

at 60 s

Media flow timeline:

Flow ID:

three (3)

Start time:

0 s

Flow duration:

119 s

Pause time:

not required

Resume time:

not required

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 and ensuring fair share of the available bandwidth at each bottleneck.

                             Forward ---->

            +---+          +---+        +---+      +---+
            |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 the corresponding feedback/control traffic is transported over the backward path.

Testbed attributes:

Test duration:

300 s

Path characteristics:

Reference bottleneck capacity:

2 Mbps

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:

100 ms

Between S2 and R2:

40 ms

Between S3 and R3:

40 ms

Application-related:

Media source:

Media type:

Video

Media direction:

Forward

Number of media sources:

Three (3)

Media timeline:

Start time:

0 s

End time:

299 s

Media type:

Audio

Media direction:

Forward

Number of media sources:

Three (3)

Media timeline:

Start time:

0 s

End time:

299 s

Competing traffic:

Number of sources:

Zero (0)

[RFC3550]

H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003,
<https://www.rfc-editor.org/info/rfc3550>.

[RFC3551]

H. Schulzrinne, and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003,
<https://www.rfc-editor.org/info/rfc3551>.

[RFC3611]

T. Friedman, R. Caceres, and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003,
<https://www.rfc-editor.org/info/rfc3611>.

[RFC4585]

J. Ott, S. Wenger, N. Sato, C. Burmeister, and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006,
<https://www.rfc-editor.org/info/rfc4585>.

[RFC5506]

I. Johansson, and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009,
<https://www.rfc-editor.org/info/rfc5506>.

[RFC5681]

M. Allman, V. Paxson, and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>.

[RFC6679]

M. Westerlund, I. Johansson, C. Perkins, P. O'Hanlon, and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012,
<https://www.rfc-editor.org/info/rfc6679>.

[RFC8593]

X. Zhu, S. Mena, and Z. Sarker, "Video Traffic Models for RTP Congestion Control Evaluations", RFC 8593, DOI 10.17487/RFC8593, May 2019,
<https://www.rfc-editor.org/info/rfc8593>.

[RFC8836]

R Jesup, and Z Sarker, "Congestion Control Requirements for Interactive Real-Time Media", RFC 8836, DOI 10.17487/RFC8836, January 2021,
<https://www.rfc-editor.org/info/rfc8836>.

[RFC8868]

V Singh, J Ott, and S Holmer, "Evaluating Congestion Control for Interactive Real-Time Media", RFC 8868, DOI 10.17487/RFC8868, January 2021,
<https://www.rfc-editor.org/info/rfc8868>.

[RFC8869]

Z Sarker, X Zhu, and J Fu, "Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks", RFC 8869, DOI 10.17487/RFC8869, January 2021,
<https://www.rfc-editor.org/info/rfc8869>.

[HEVC-seq]

HEVC, "Test Sequences",
<http://www.netlab.tkk.fi/~varun/test_sequences/>.

[RFC2914]

S. Floyd, "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/info/rfc2914>.

[RFC7567]

F. Baker, and G. Fairhurst, "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/info/rfc7567>.

[RFC8033]

R. Pan, P. Natarajan, F. Baker, and G. White, "Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017,
<https://www.rfc-editor.org/info/rfc8033>.

[RFC8290]

T. Hoeiland-Joergensen, P. McKenney, D. Taht, J. Gettys, and E. Dumazet, "The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm", RFC 8290, DOI 10.17487/RFC8290, January 2018,
<https://www.rfc-editor.org/info/rfc8290>.

[RFC8699]

S. Islam, M. Welzl, and S. Gjessing, "Coupled Congestion Control for RTP Media", RFC 8699, DOI 10.17487/RFC8699, January 2020,
<https://www.rfc-editor.org/info/rfc8699>.

[xiph-seq]

Xiph.org, "Video Test Media",
<http://media.xiph.org/video/derf/>.

Zaheduzzaman Sarker

Varun Singh

Xiaoqing Zhu

Michael A. Ramalho