In the lesson for this month we are going to do an analysis of a popular streaming service. Our goal is to better understand how we can use a traditional IT tool to do a deep analysis of this type of video flow. We will learn techniques that are widely applicable to troubleshooting and to analyzing other types of audio and video flows.
We’ve chosen to use Netflix as an example of a streaming service. Netflix has recently passed $1 billion in revenue and represents extremely high amounts of IP traffic on the internet. Like Apple HLS and Microsoft Smooth Streaming, Netflix generally uses variations of adaptive bit rate (ABR) delivery. The transport method is very different from other video flows such as conferencing video, SRT, or SDVoE.
It is interesting to understand how Wireshark, a free IT tool, can help in our analysis. Wireshark has been used for decades with traditional data applications. However, here, our focus is on its use with video. In the example discussed here, the internet connection is DSL with a downstream/upstream bandwidth of 20/2Mbps. The target playout device is a Windows 10 computer running Chrome to access the video. In order to capture the Netflix flow, the stream is passed through an Ethernet switch and the analysis device running Wireshark is attached to a mirror port.
Using a feature of Wireshark called conversations, we can obtain a table such as that shown in Figure 1. By inspecting the various tabs at the top and clicking on column headings to sort the entries in the column, we can see the TCP sessions that deliver the video to the client computer at 192.168.7.116. The first three sessions dominate, delivering about 44 MB. If we right click on the first row of that table, the traffic for that TCP session is separated and shown.
Then, using the I/O graph function of Wireshark, Figure 2 results. This illustrates the bandwidth used by the single TCP session sent to port 50926 (listed in the first row of Figure 1). In the first 23 seconds, the video source uses most of the available 20Mb bandwidth to attempt to saturate the playout buffer. Then, at varying intervals of approximately 5-10 seconds, the playout buffer is refreshed with much smaller deliveries of video. If we were to repeat this procedure on the sessions described in line 2 and 3 of Figure 1, we would see almost identical graphs. By starting three simultaneous sessions to deliver the first burst, Netflix can overcome one of the problems posed by the TCP algorithm. A single session would be handicapped by the latency of the connection.
So, what can we conclude from this evidence? First, the deliveries use TCP, which indicates that it is under the control of the TCP algorithm. Decreasing the bandwidth will lengthen the time needed to deliver the first saturation burst and all succeeding bursts. Second, the length of this burst will be subject to the amount of traffic on the upstream path, which delivers the acknowledgements of the delivered packets. The presence of competing traffic or high network loss rates will also lengthen each burst. If these bursts use too much time and the playout buffer empties, the video will pause. This will probably increase the likelihood that the source will switch to a lower resolution. Such interference will also increase latency in the delivery.
Note that changing the playout device, its operating system or its browser, or the type of internet connection will change the results you will see. However, at the very least, we have seen an example of video delivery that is much different than what we would see if we analyzed IPTV, conferencing video, or video types such as SRT.
