Toward WebTransport Support in dash.js

Over the recent years, video streaming has gained more and more popularity [14]. This not only puts much strain on the Internet infrastructure [4, 10] but also creates a drive to continue improving the viewer experience. One avenue to tackle both points is the new transport protocol--- QUIC [8], which has attracted enough attention to have led to the founding of the Media over QUIC (MoQ) working group in the Internet Engineering Task Force (IETF) [6]. This group is avidly working on creating a standard for transmitting delay-sensitive media using QUIC. QUIC can reduce initial latency thanks to the combination of its handshake and TLS handshake [8]. In this study, we conducted several experiments to evaluate the improvements WebTransport (running on top of QUIC) can provide to streaming media. In particular, we looked at the startup time for DASH-based [7] streaming using WebTransport compared to HTTP/1.1 and the possibility of estimating the transmission throughput (ETP) on the server instead of the client side. To measure the startup time, we set up a webtransport-go [13] server, an HTTP/1.1 Express [3] server and a client Website using the WebTransport API [16] to communicate with the webtransport-go server and Fetch API [12] for communicating to the Express server. DASH playback happens in a basic Media Source Extensions (MSE) [15] HTML5 video element. To simulate different network conditions, outgoing traffic was limited using the Linux traffic control command tc [9] as follows: (1) set: tc qdisc add dev  root tbf rate  latency 50ms burst 1540 (2) delete: tc qdisc delete dev  root Figure 1 shows our results of running said benchmark using Big Buck Bunny, Sunflower Version [2] with a segment duration of 1.6 seconds, a buffer target of a single segment, a resolution of 1280x720 at 2048 Kbps. We tested the startup time by using server bandwidth limits relative to the video bitrate, using limits ranging from one quarter to double the video bitrate. We ran every test 50 times each. Based on these tests, we conclude that WebTransport is a prime candidate to improve the startup time of dash.js. Another experimentation field is the accuracy of the ETP calculations [5]. Server-side throughput estimation can enhance existing client-side adaptive bitrate (ABR) algorithms or even completely replace them. The WebTransport server can run calculations to determine the ETP of each individually connected WebTransport session. To do that, we used the server-provided data from the qlog files [11]. We took the timestamps from before and after sending a segment, and using them, we could extract the exact log entries from the data sent. Furthermore, we filtered the entries containing the required data (smoothed_rtt and bytes_in_flight). Using this data, we calculated the ETP for every logged transmission as follows: A single transmission consists of numerous individual log entries, and to compute the final ETP of transmission, we took the arithmetic median of all entries. Observations so far using static assets show an excellent result with a deviation of less than 10% when the bandwidth limit set on the server and transmitted video bitrate are not far from each other. However, in comparison to existing throughput estimation in dash.js, WebTransport's server-side ETP does not offer a significantly improved estimation, and we will investigate whether server-side ETP offers improvements for low-latency live streaming, where dash.js struggles to provide accurate estimations as discussed in [1].


ABSTRACT
Over the recent years, video streaming has gained more and more popularity [14].This not only puts much strain on the Internet infrastructure [4,10] but also creates a drive to continue improving the viewer experience.One avenue to tackle both points is the new transport protocol-QUIC [8], which has attracted enough attention to have led to the founding of the Media over QUIC (MoQ) working group in the Internet Engineering Task Force (IETF) [6].This group is avidly working on creating a standard for transmitting delay-sensitive media using QUIC.QUIC can reduce initial latency thanks to the combination of its handshake and TLS handshake [8].
In this study, we conducted several experiments to evaluate the improvements WebTransport (running on top of QUIC) can provide to streaming media.In particular, we looked at the startup time for DASH-based [7] streaming using WebTransport compared to HTTP/1.1 and the possibility of estimating the transmission throughput (ETP) on the server instead of the client side.
To measure the startup time, we set up a webtransport-go [13] server, an HTTP/1.1 Express [3] server and a client Website using the WebTransport API [16] to communicate with the webtransportgo server and Fetch API [12] for communicating to the Express server.DASH playback happens in a basic Media Source Extensions (MSE) [15] HTML5 video element.To simulate different network conditions, outgoing traffic was limited using the Linux traffic control command tc [9] as follows: (1) set: tc qdisc add dev <netInterfaceName> root tbf rate <Server Bandwidth> latency 50ms burst 1540 (2) delete: tc qdisc delete dev <netInterfaceName> root Figure 1 shows our results of running said benchmark using Big Buck Bunny, Sunflower Version [2] with a segment duration of 1.6 seconds, a buffer target of a single segment, a resolution of 1280×720 at 2048 Kbps.We tested the startup time by using server bandwidth limits relative to the video bitrate, using limits ranging from one quarter to double the video bitrate.We ran every test 50 times each.Based on these tests, we conclude that WebTransport is a prime candidate to improve the startup time of dash.js.
Another experimentation field i s t he a ccuracy o f t he ETP calculations [5].Server-side throughput estimation can enhance existing client-side adaptive bitrate (ABR) algorithms or even completely replace them.The WebTransport server can run calculations to determine the ETP of each individually connected WebTransport session.To do that, we used the server-provided data from the qlog files [11].We took the timestamps from before and after sending a segment, and using them, we could extract the exact log entries from the data sent.Furthermore, we filtered the entries containing the required data (ℎ_ and __ ℎ).
Using this data, we calculated the ETP for every logged transmission as follows: A single transmission consists of numerous individual log entries, and to compute the final ETP of transmission, we took the arithmetic median of all entries.Observations so far using static assets show an excellent result with a deviation of less than 10% when the bandwidth limit set on the server and transmitted video bitrate are not far from each other.However, in comparison to existing throughput estimation in dash.js,WebTransport's server-side ETP does not offer a significantly improved estimation, and we will investigate whether server-side ETP offers improvements for low-latency live streaming, where dash.jsstruggles to provide accurate estimations as discussed in [1].