A Measurement-Derived Functional Model for the Interaction Between Congestion Control and QoE in Video Conferencing

Video Conferencing Applications (VCAs) that support remote work and education have increased in use over the last two years, contributing to Internet bandwidth usage. VCA clients transmit video and audio to each other in peer-to-peer mode or through a bridge known as a Selective Forwarding Unit (SFU). Popular VCAs implement congestion control in the application layer over UDP and accomplish rate adjustment through video rate control, ultimately affecting end user Quality of Experience (QoE). Researchers have reported on the throughput and video metric performance of specific VCAs using structured experiments. Yet prior work rarely examines the interaction between congestion control mechanisms and rate adjustment techniques that produces the observed throughput and QoE metrics. Understanding this interaction at a functional level paves the way to explain observed performance, to pinpoint commonalities and key functional differences across VCAs, and to contemplate opportunities for innovation. To that end, we first design and conduct detailed measurements of three VCAs (WebRTC/Jitsi, Zoom, BlueJeans) to develop understanding of their congestion and video rate control mechanisms. We then use the measurement results to derive our functional models for the VCA client and SFU. Our models reveal the complexity of these systems and demonstrate how, despite some uniformity in function deployment, there is significant variability among the VCAs in the implementation of these functions.

1. 1.

   In principle, the total client sending rate includes video, audio, and control data (e.g., RTCP packets). In this paper, we focus only on video data as it is the most bandwidth intensive.

2. 2.

   The Zoom packet structure determined by Michel et al. [31] could aid this process.

This work was supported by NSF grant NETS-1909040. We thank the PAM reviewers and our shepherd for their valuable feedback.

Authors and Affiliations

1. Georgia Institute of Technology, Atlanta, GA, USA

   Jia He, Mostafa Ammar & Ellen Zegura

Corresponding author

Correspondence to Jia He .

Editors and Affiliations

1. Karlstad University, Karlstad, Sweden

   Anna Brunstrom

2. Edgio, Scottsdale, AZ, USA

   Marcel Flores

3. IMDEA Networks Institute, Madrid, Spain

   Marco Fiore

A Competition with TCP

Competition with different types of TCP flows. (a-c) Jitsi, (d-f) Zoom in SFU mode.

Full size image

As Zoom has been reported to take a majority share of the bandwidth when competing with TCP [28, 30, 34], we took measurements with different types of TCP flows to compare and explain results using the functional models and measurements in Sect. 4.

The testbed was used in two-person SFU mode with Zoom and Jitsi as in Sect. 4.3. In all cases, a total bandwidth limit of 4 Mb/s was applied to the upload of Client 1. After 30 s of measurement, ten TCP flows begin in various patterns: (i) started at the same time with nine minute duration, (ii) started at 30 s intervals, all finishing at the nine minute mark, and (iii) started and stopped at the same time every 20 s.

Figure 15 shows the results of these measurements. Figures 15(a), 15(b), and 15(c) all show that Jitsi immediately gives up practically all of its bandwidth in the presence of TCP. In particular, Fig. 15(b) shows that this occurs with only a single TCP flow sharing the link at the 30 s mark. This behavior is likely caused by GCC’s sensitivity to changes in delay; once GCC gives up some bandwidth, TCP takes it, compounding the response. Conversely, Figs. 15(d), 15(e), and 15(f) show that Zoom sending rate actually increases in TCP’s presence. This is likely a consequence of how it decides to add FEC as described in Sect. 4.3, the general insensitivity that Zoom has to packet loss, and the high threshold for responding to latency.

B Video Subsampling Methods

As mentioned in Sect. 1, the SFU is able to adjust the quality of forwarded video streams via subsampling. The exact method used for this differs between the considered VCAs, as described below, and summarized in Table 2.

Zoom uses a custom implementation of H.264 Scalable Video Coding (SVC) [2, 23, 36] to encode base and enhancement video layers. The SFU can then add/drop layers before forwarding to clients. Because H.264 SVC is used, subsampling of both the resolution and the frame rate is available to the SFU in Zoom as an orthogonal technique to adjust video bit rate [21, 37, 44, 45].

Jitsi and BlueJeans use video simulcast, in which the VCA client sends multiple independent video streams at different resolutions. Jitsi uses simulcast when the VP8 encoder is used. In particular, the Jitsi clients make use of three simulcast streams, with resolution scaling factors of 1, 2, and 4. At 1280\(\,\times \,\)720 native video resolution, this means the two other streams will be 640\(\,\times \,\)360 and 320\(\,\times \,\)180. BlueJeans also uses the VP8 encoder, implying use of simulcast, though there are no means of measuring the individual video streams. In a VCA with simulcast, the SFU chooses which one of the received video streams to forward, which determines the resolution. Additionally, it may choose to adjust the frame rate without re-encoding. Note that resolution changes without re-encoding are not possible with the VP8 codec [5, 41], demanding the use of simulcast.

Client sent video quality metrics in peer-to-peer mode, when adjusting the upload latency. The colors indicate the distinct modes of operation.

Full size image

C Zoom Video Rate Control under Different Latency Conditions

Figure 16 presents the video metrics for Zoom as a function of the additional latency on the upload. Overall, the sent video metrics begin to see an impact at 400 ms additional upload latency, and beyond 600 ms additional latency, there are no further impacts.

Frame Rate and Resolution. We group the consideration of both of these metrics as they share a very similar response to the additional upload latency. The most notable feature is the evolution of high variance in the measurement results for added latencies above 500 ms. We observe that much of the measured variance is not due to fluctuation in the frame rate or resolution; instead it is caused by Zoom returning to the maximum resolution and frame rate some time after the experiment starts. The time at which this occurs is a function of the latency; the higher the latency, the longer Zoom takes to begin recovering its sending rate. At higher latencies beyond 600 ms, the recorded variance is low. This is either because the time taken for Zoom to begin recovering is longer than the measurement duration, or because Zoom keeps the low sending rate indefinitely if the latency is beyond this value.

Measured Video Sending Rate. The measured video sending rate corresponds well to the frame rate and resolution trends. Specifically, there appear to be two intermediate levels of video sending rate; the first averaging around 2.25 Mb/s between 400 and 500 ms added latency, and the second averaging around 1.5 Mb/s between 500 and 600 ms. Beyond 600 ms, a flat 100 kb/s sending rate is used, which corresponds to what is observed in Fig. 4(f).

QP. The method for obtaining Zoom’s QP outlined in Sect. 3.2 is incompatible with latency measurements. This is because starting a screen recording in the Zoom application prompts a sudden, very large spike in latency. Once this spike dissipates, the Zoom application begins sending at the maximum rate, even when the steady-state latency is above 1,000 ms. We are uncertain if this is intended behavior to maintain maximum quality for recording purposes, or if this is a bug. In any case, we are unable to ascertain the Zoom QP for these measurements.

Reprints and permissions

© 2023 The Author(s), under exclusive license to Springer Nature Switzerland AG

Policies and ethics