HTTP/2, Server Push and Branched Video

Transcription

1 Linköping University Department of Computer Science Bachelor thesis, 16 ECTS Datateknik 2017 LIU-IDA/LITH-EX-G--17/073--SE HTTP/2, Server Push and Branched Video Evaluation of using HTTP/2 Server Push in Dynamic Adaptive Streaming over HTTP with linear and non-linear prefetching algorithms. Utvärdering av HTTP/2 Server Push vid adaptiv videoströmning. Summia Al-mufti Rasmus Jönsson Supervisor : Niklas Carlsson Examiner : Nahid Shahmehri Linköpings universitet SE Linköping ,

2 Upphovsrätt Detta dokument hålls tillgängligt på Internet eller dess framtida ersättare under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter upps tår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefa ttar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida Copyright The publishers will keep this document online on the Internet or its possible replacement for a period of 25 years starting from the date of publication barring exceptional circumstances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as desc ribed above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: c Summia Al-mufti Rasmus Jönsson

3 Students in the 5 year Information Technology program complete a semester-long software development project during their sixth semester (third year). The project is completed in midsized groups, and the students implement a mobile application intended to be used in a multiactor setting, currently a search and rescue scenario. In parallel they study several topics relevant to the technical and ethical considerations in the project. The project culminates by demonstrating a working product and a written report documenting the results of the practical development process including requirements elicitation. During the final stage of the semester, students create small groups and specialise in one topic, resulting in a bachelor thesis. The current report represents the results obtained during this specialisation work. Hence, the thesis should be viewed as part of a larger body of work required to pass the semester, including the conditions and requirements for a bachelor thesis.

4 Abstract The purpose of this thesis is to investigate and test the usage of HTTP/2 in dynamic adaptive video streaming as well as to take a look into how it can be used to benefit prefetching algorithms used with branched video. With a series of experiments the performance gains of using HTTP/2 rather than the older standard HTTP/1.1 has been investigated. The results has shown no significant change to player quality and buffer occupancy when using HTTP/2, though our tests has shown in a slight decrease in overall playback quality when using HTTP/2. When using a linear prefetch of two fragments an average quality improvement of 4.59% has been shown, however, the result is inconclusive due to variations in average quality between different values for how many fragments to prefetch. Average buffer occupancy has shown promise with a maximum increase of 12.58%, when using linear prefetch with three fragments. The values for buffer occupancy gains are conclusive. Two implementations for non-linear prefetching has been made. The first one uses HTTP/2 server push to deliver fragments for prefetching and the second one uses clientside invoked HTTP requests to pull fragments from the server. Using HTTP/2 server push has shown in a decrease of 2.5% in average total load time while using client-side pulling has shown in a decrease of 34% in average total load time.

5 Acknowledgments We would like to thank our supervisor Niklas Carlsson and his colleague Vengatanathan Krishnamoorthi for the guidance, help and support during the entire project. We also want to thank the team behind DASH.js and the Go programming language. v

6 Contents Abstract Acknowledgments Contents List of Figures List of Tables iv v vi vii viii 1 Introduction Motivation Aim Research questions Delimitations Theory HTTP/ HTTP/ Dynamic adaptive streaming over HTTP Branched video and prefetching Related works Method Web server Web client Environment Linear prefetching Non-linear prefetching Results Video file Linear prefetching Prefetching with branched video Discussion Linear prefetching Non-linear prefetching Prefetching branched video Method The work in a wider context Conclusion Bibliography 27 vi

7 List of Figures 2.1 Comparison of simplex, multiplex and server push A 20 second video file divided into several fragments of 5 seconds and different qualities Client request a fragment that is delivered by the server An example of a branched video with two branch points A request served with a K-push method Average quality level and buffer level when using HTTP/ Average quality level and buffer level over time when using HTTP/2 without linear prefetching Average quality level and buffer level over time when using HTTP/2 and linear prefetch with k= Average quality level and buffer level over time when using HTTP/2 and linear prefetch with k= Average quality level and buffer level over time when using HTTP/2 and linear prefetch with k= Average quality level and buffer level over time when using HTTP/2 and linear prefetch with k= Results for linear prefetching with confidence intervals Variations for quality and buffer occupancy compared vii

8 List of Tables 4.1 Quality index and corresponding bit-rates Comparison between the test using HTTP/1.1 and HTTP/ Comparison between the test using HTTP/2 and linear prefetching Standard deviation for all the tests Variation for all the tests Load times with and without prefetching and comparison on total load time viii

9 1 Introduction 1.1 Motivation Video streaming is becoming increasingly popular and more people choose to consume media content via their Internet connection. The multinational technology conglomerate Cisco predicts that by the year of 2020 video streaming will account for about 80% of the Internet data traffic [3]. Video streaming is without a doubt a hot-topic in the technology sector. HTTP 1, commonly used to deliver video content, was not originally designed for video streaming. Because of this, more adaptation at the application level is required to give better support for video streaming. In the search for a more effective solution for HTTP, the newer version of HTTP, named HTTP/2, has been developed. This thesis covers how video streaming can benefit from features in the relatively new standard HTTP/2, which is there to complement and eventually replace the old standard HTTP/1.1. The improvement of video streaming can have a huge impact for the end user. This means reduced data usage, reduced battery usage and increased video quality. One of the new features in HTTP/2 is server push that allows the web server to push multiple resource to the client without requiring an explicit request by the client for those resources. 1.2 Aim The aim of this report is to investigate whether or not using HTTP/2 and server push, in the video streaming context, has any performance gains. And how it can be implemented in branched video streaming. In this thesis we have investigated when HTTP/2 and server push is preferred over HTTP/1.1 and what issues HTTP/2 server push can solve compared to HTTP/1.1 in video streaming with the DASH 2 protocol. An investigation to find if HTTP/2 can help solve the problems of HTTP/1.1, when using it to stream video, has also been made. These investigations have been done by implementing a video streaming mechanism using HTTP/2 server push technology. 1 Hyper Text Transfer Protocol 2 Dynamic Adaptive Streaming over HTTP 1

10 1.3. Research questions 1.3 Research questions Are there any benefits of using HTTP/2 in video streaming? Are there any benefits of using HTTP/2 with server push in video streaming? How does these benefits affect the end-user when watching video? How can a non-linear prefetch approach be used with HTTP/2 in branched video streaming? 1.4 Delimitations HTTP/2 has many new features but in this thesis the focus is on the server push functionality. To limit the results from the experiments only quantitative results will be collected and considered, such as how much video is buffered at a given point or what quality is played back. An implementation with server push in a common web server and customization s for video streaming over HTTP/2 has been made. The first implementation is based on a linear prefetch strategy, other strategies to using server push in video streaming, like non-linear prefetching, have also been investigated. The second implementations is an algorithm for non-linear prefetching when playing media of type branched video. 2

11 2 Theory This theory chapter covers how HTTP/2 differs from HTTP/1.1 and the basics of how dynamic adaptive streaming over HTTP works. It also covers a background about branched video streaming and differences between linear and non linear prefetching. 2.1 HTTP/1.1 HTTP/1.1 was first drafted in the RFC 2616 standard and has been around since year 1999 [4]. Today most websites on the Internet still use HTTP/1.1 and the transformation into HTTP/2 is a constant ongoing process, many large Internet companies has already adopted HTTP/2 and many others are expected to follow. Because HTTP/1.1 is still relatively common it is very relevant to look at how it works. HTTP in general is a request driven protocol where a client, usually refereed to as a web browser, send a request to a server to fetch a web page with some content. The resource fetched usually contains links to other resources that also needs to be fetched to display a page in full, such as images and style-sheets. HTTP/1.1 does not feature any type of multiplexing, meaning that resources requested by the client cannot be streamed asynchronously. So the client will have to wait for one response to finish before receiving a response for the next request. This means that if the client wants to load two resources, one fast and one slow, and the slow resource gets requested first, the fast resource cannot be sent until the slow one has finished which causes unnecessary waiting, this type of flow is illustrated in Figure 2.1. This synchronous process is not suitable for today s rich web pages because they often contain a vast amount of links to other required resources, which requires a lot of request to complete rendering of a web page. Because video streaming requests often share the same pipeline as the web page they are located on, they will also take a part in the waiting process for other resources. If another request is being responded to when the web browser is trying to request another video fragment then the video request will have to wait for the other request to finish, this might cause a video to stall 1 during playback. Another problem with HTTP/1.1 is that it in general requires one round trip to the server per request made. This becomes a big issue in high-latency networks. To address this HTTP pipelining was introduced where a number of request can be served over the same TCP con- 1 Video sizes to play for a short period of time. 3

12 2.2. HTTP/2 nection, which removes the need for additional round trips for every request. However, HTTP pipelining is not as widely used and does not add any support for multiplexing. A common way to work around the issue of no multiplexing as default in HTTP/1.1 is to use multiple TCP connections. However, this is not a formal part of the standard of HTTP/1.1 and is not required. It is also usually limited to a maximum of six parallel connections and has no support for prioritizing responses. 2.2 HTTP/2 Internet Engineering Task Force (IETF) introduced a new version of HTTP in the RFC 7540 standard named HTTP/2 [1]. HTTP/2 is an updated version of HTTP/1.1 that includes a variety new features like server push, stream multiplexing and minimizing protocol overhead via efficient compression of HTTP header fields. The aim is to address the issues of HTTP/1.1 and in turn contribute to a faster Internet. The server push technology was originally designed to help reduce web page load latency by allowing the web server to push content that the client might need in the near future, such as external resources on a page the client is currently rendering. This means that some resources may be transmitted to the client before the client is done parsing the link to that content. The idea is that the server can maintain a persistent connection with the client and push multiple resources at the same time without a need to require a request for every resource. This means that the round trip delay which comes with the request-response model can be avoided and the server can simply push all resources the client will need when requesting a specific page into its web browser cache-memory. When the client eventually wants to make a request for a specific resource the request can be instantly loaded if the content is already stored in the web browsers cachememory. Figure 2.1a shows a typical request/response pattern when requesting a website from a HTTP/1.1 server without multiplexing. All resources requested are loaded synchronously. The inclination of the response arrows indicate the size of the resource that is being transferred, a very steep slope would indicate a large file as it would take longer time for it to be transferred. Figure 2.1b shows a typical request/response pattern when using HTTP/2. Responses and requests have the ability to multiplex and be transferred asynchronously. Figure 2.1c shows a typical request/response patterns when using HTTP/2 and server push enabled. Responses are both loaded asynchronously and responses to resource 2 and 3 are pushed by the server instantly rather than requested. 4

13 In the context of video streaming some clear benefits of using HTTP/2 can be identified; 2.3. Dynamic adaptive streaming over Figure 2.1: Comparison of simplex, multiplex and server push. HTTP request 1 request 1 request 1 response 1 request 2 response 2 response 1 push 2 push 3 response 1 request 2 request 3 response 2 request 3 response 3 response 3 (a) Simplex: Resources are loaded in sequence (b) Multiplex: Resources are loaded in parallel (c) Server push & multiplexing: Resources are pushed and loaded in parallel

14 2.3. Dynamic adaptive streaming over HTTP which causes buffering 2. This type of behaviour is unwanted. The available bandwidth is calculated by the client as it downloads video fragments and it is up to the client to choose which fragments to request and download from the server. This client driven interaction is very suitable for the distributed structure of many video streaming services, as there is no need for servers to keep track of different states or do any bandwidth estimations, as this is managed by the client. Figure 2.3: Client request a fragment that is delivered by the server DASH uses an MPD 3 file which is first fetched by the client when a video streaming process is about to begin. The MPD file have a variety of options and tells the client where to find the different video fragments as well as what video encoding has been used to encode the fragments. The MPD file also contains options for minimum and/or maximum buffer. The minimum buffer is a value of how many seconds of video data the client needs to have in its buffer before starting a video playback, if the buffer content falls below this threshold the video continues to play. If the client buffer is entirely empty it will not continue playback until enough fragments has been fetched to reach the minimum buffer threshold. This option helps to keep the client from constantly freezing in bad bandwidth conditions. The maximum buffer option can be used to restrict the client from storing too much content in its buffer. This helps the client to not store too much video data of a too low quality if the bandwidth conditions improves over time. By selecting these factors with care the client can be given instructions to help balance great video quality with the risk of stalling to buffer more video content. The goal of this adaptive streaming mode is to allow users to consume video data in a smooth playback even though bandwidth conditions are bad. The downside of adaptive streaming is that users with unstable connections might experience a lot of shifts in video quality, but the gains in having adaptive streaming mode considered superior to this factor. It should also be stated that different implementations of the DASH protocol may have different characteristics such as different buffer thresholds. Dash.js A commonly used implementation of DASH for websites is dash.js written in JavaScript. This implementation is specially suitable for usage in web browsers as most browsers has support for JavaScript. It works by including a JavaScript file into the web-page and then defining a HTML5 video element with a link pointing to the MDP file. This implementation is the one used in the experiments conducted and was selected due to its common usage and active development. Bandwidth estimation in dash.js One of the factors that has to be taken into consideration when using a specific implementation of DASH is to look at how the bandwidth is estimated. Dash.js estimates bandwidth by using the first received response byte for measuring latency and the time to final byte to 2 The process of downloading content to be played 3 Media Preparation Description 6

15 2.4. Branched video and prefetching measure bandwidth. When using this estimation for adaptive bit-rate selection the measured bandwidth is averaged by a sliding scale. Special consideration in the experiments as to not affect the ability to correctly estimate bandwidth has been taken. 2.4 Branched video and prefetching Linear media is media arranged in a pre-defined order with no end-user interaction, every user receives the same flow of information. Non-linear is the opposite where every user receives a different flow of information depending on their interactions. A common usage for non-linear video streaming is 3D graphics where the user can navigate around a 3D scenery, in this case streaming the video of the users current viewing angle [5]. Branched video is a type of non-linear media of which the users can select different playback paths through the video without noticing interruptions in the video quality [8][10]. A playback path is in most cases selected by the consumer. A path could represent a sub-story or an alternative chain of events that the consumer can choose to watch. Because of the interactive nature of branched video the wait time between selecting a branch until the switching is done will need to be fairly low, as not to affect the consumers experience. Figure 2.4 shows how a branched video might be divided into different paths. Branched video is similar to the concept of alternative videos or recommended videos. Where the user can select from a range of different videos to continue to watch after the current video has finished Figure 2.4: An example of a branched video with two branch points. This is common among different video streaming providers. Although branched video puts even more requirements on the low switch times when branching similar techniques can be applied on both of the concepts. Linear prefetching Linear prefetching is when the prefetching algorithm downloads fragments of a single video stream. Most often also the same quality of which is played back. This is most suitable for linear, single stream, media as it usually only consists of one stream. Non-linear prefetching Non-linear prefetching is when the prefetching algorithm downloads fragments from different video streams. These fragments could either be of the video currently being consumed or of alternative videos that will be presented to the user when the current video finish. The method is most suitable for non-linear media. To access a seamless switching between different paths in non-linear media, prefetching and buffer management is often used [8][10]. The player prefetch fragments for each possible path into a prefetch buffer and manages the content of the video [8]. Prefetching is also useful to provide attractive recommended video choices to the users that often switch quickly between different videos. Studies shows that today s users in online video on-demand (VoD) often switch the video being streamed within a few minutes of viewing [11]. These recommended videos need to be prefetched and buffer managed parallel to the video being played to achieve an instant playback when a user select one of these recommended videos [9]

16 2.5. Related works Branched video Krishnamoorthi et al. [10] define branched video as a traditional linear HAS 4 video that allows the video designer to define arbitrary playback sequences through the underlying linear video and allows the user to choose between alternative playback sequences. The paper covers the design of optimized prefetching policies and buffer management schemes. The goal is to allow a seamless playback even if the user switch from one branch path to another to the last possible moment. And give an uninterrupted playback and maximize the video quality. Alternative videos Krishnamoorthi et al. [9] covers a design, implementation and evaluation of an HAS framework to provide prefetching and buffer managing of the alternative videos. The prefetching design and performance was based on three policy classes called best-effort, token-based and deadline based. In Best-effort policies chunks from the alternative videos will be prefetched only when the buffer occupancy reaches maximum value T max. Token-based policies prefetch chunks in the same way as in best-effort policies but there are differences in how these two policies decides from which video to be prefetched next. The token-based method uses a constant rate to determine when to prefetch fragments of a video. This policy provides greater control at which time an alternative video may first be prefetched. Deadline-based policies, as opposed to token-based policies, provides specific deadlines at which the alternative videos need to be done prefetching rather then when to start prefetching them. This is done to ensure that the alternative videos will be prefetched in time to be played and ensuring that the video is of the highest quality. This type of policies are important for users that prefer a smooth switching between the alternative videos. Multi-video stream bundles Carlsson et al. [2] introduce and present a system design of a general multi-video stream bundle framework. The multi-video stream bundle consists of multiple "parallel" video stream which are synchronized in time. Each of these multiple video streams provides the video from different cameras capturing the same shot or movie. The idea is to allow for example producers to give the freedom to users to switch between different perspective at different times. The multi-video stream bundle framework is to impact the quality adaptive features and time-based chunking of HAS, but also including adaptation in both rate and content. Predictive prefetching Many factors add delays to resources served over HTTP. Such as the disk latency of the server or the time it takes for the web client to process the received data. The use of predictive prefetching can address some of the latency issues in the web. Predictive prefetching basically means having resources that are likely to be accesses later be prefetched by the client. This would in turn limit the load time for these resources [12]. 2.5 Related works There are some papers that covers implementations of DASH featuring HTTP/2. Wei. et. al. [14] have focused on investigating energy efficiency benefits to mobile clients server push could have in adaptive streaming. Their focus has been on testing if using push could allow the mobile device radio unit to go into sleep mode between bulks of pushing a certain amount of video fragments. They describe the HTTP/2 server push functionality as "[...] an 4 HTTP Adaptive Streaming 8

17 2.5. Related works elegant way of changing the HTTP request schedule in video streaming without compromising the scalability of HTTP streaming or making changes to the HTTP resources.". A method they refereed to as the K-push strategy was introduced, where the server would push the k subsequent video fragments for the given bit-rate when the client sends their request for a video fragment of that bit-rate. This strategy would limit the amount of request the client has to send to the server as well as transmitting a set of fragments in bulk rather than spreading them out with a given interval. Sending fragments in bulk means that for a given period of time, when the sent fragments has been received and are awaiting to be played, the radio unit can enter sleep mode until another request is sent for the next k fragments. One of the problems covered in the report is selecting a suitable value for k, such as allowing the radio unit to enter sleep mode. This value can be derived from the power consumption model of the mobile device to reach an optimal value. Van der Hooft et. al. [6] discuss the merits of an HTTP server push approach. The paper is a study based on first performing measurements on the available network in real 4G/LTE networks within the city of Ghent in Belgium. Secondly analyzing the induced bit-rate overhead for video fragments with a sub-second duration. They determined that the fragment duration time should not be lower than 500 ms to limit the overhead to 9.2%. They have done the experiments by using MiniNet framework with a single client and streaming the encoded video from a Jetty server. The client is implemented on the libdash library which is the official reference software of the MPEG-DASH standard. Their results showed in higher video quality (+7.5%) and a lower freeze time (-50.4%) compared to solutions over HTTP/1.1. Huysegems et. al. [7] present ten HTTP/2-based methods to improve the QoE 5 of HAS. The paper covers how to improve the QoE of HAS by reducing the number of video freezes caused by rebuffering. How to reduce the number of quality level changes, reduce the latency for live streaming and reduce the interactivity delay by using HTTP/2 features. The main focus is to design and implement an HTTP/2 push approach in live streaming. The pushbased strategy uses HTTP/2 server push to push very short fragments from server to client. Their result shows that with an RTT of 300 ms the average server-to-display delay can be reduced by 90.1% and the average start-up delay can be reduced by 40.1%. 5 Quality och Experience 9

18 3 Method To test the viability of using HTTP/2 and server push in video streaming context we have carefully measured the impact of using HTTP/2 compared to HTTP/1.1. We have done this with two different types of prefetching: one linear prefetching algorithm and one non-linear prefetching algorithm. For these two types of prefetching we have conducted a series of tests. By doing this we have been able to determine whether or not HTTP/2 has any performance gains, when using server push. We have investigated two factors identified as related to the overall user experience; buffer occupancy and video quality. The buffer occupancy is measured as the average seconds of video the player has buffered during the playback. The overall player quality is the average quality level at which the player is requesting and playing fragments. To make it possible to focus on the main problem we have used an existing DASH implementation and a web server that supports HTTP/2. However, to enable the HTTP/2 server push feature we have implemented a server side logic using the programming language Go/ Because it is also important to use a web client that support HTTP/2, Opera has been selected to perform the tests. 3.1 Web server When traditionally implementing DASH most web servers are sufficient as no special web server support or server side logic is needed to make DASH function, outside of supporting the HTTP standard. Using HTTP/2 will not require any server side logic either, only a web server supporting HTTP/2 will be sufficient. However, when implementing server push, some server side logic is required to take decisions on what data to push to the user. For selecting the web server we wanted to have good support for HTTP/2, a conformance of over 90% is considered to be acceptable as long as there is full support for server push. Because HTTP/2 is such a wide, and relatively new, standard a 100% conformance is not expected by almost any modern web servers. And our test should not be affected by a small deviation from this, as long as the deviation does not relate to a core HTTP/2 feature. To test this we used a RFC 7540 [1] and RFC 7541 [13] compliant conformance testing tool called h2spec 1. h2spec provides a test suite that can run against any web server to check what features of HTTP/2 are supported. 1 Available at: 10

19 3.2. Web client Because we needed to implement some server side logic to get our prefetching algorithms to work properly we wanted to use a web server implementation that allowed us to customize what happens when a request is served. We therefore turned to the programming language Go which has a built in HTTP/2 package and support for server push. When we ran a conformance test using the h2spec testing tool we got a conformance result for the HTTP/2 package in Go/1.8.1 of 92%. The tests showed that Go/1.8.1 had full support for server push. Because of this factor Go/1.8.1 was selected as the web server implementation. In the web-server we have implemented a bandwidth throttling which gives the ability to properly limit the available bandwidth by simply delaying the chunks outgoing data according to a specified limit, this limit is given in Mbit/s and can be changed through a simple API. The bandwidth throttling is built with a steady function meaning that the end result is stable, no deviations or overshoot in the supplied bandwidth occurs. The throttling feature uses a timed loop to copy the response bytes at a desired rate. This rate is also divided by the number of concurrent connections to simulate one throttled connection. We have also tested with Woundershaper, a program to limit bandwidth, but it gave overshoot which we did not want in our tests. The effect of the throttling code has been tested by downloading a large file and using the web client speed indicator as reference. 3.2 Web client The web client used in the tests had no specific requirements other than a full support for HTTP/2. Opera/ was used in the tests. A HTML web page was created with a dash.js client added. The pages also features an added live preview graph that gives instant insight in the test results and a simple set of selectors for adjusting the bandwidth throttling. These settings also persists during test resets. The web page also features a timer, when the timer runs out the test results are automatically stored to a file and the test is reset. This allow for running many consecutive tests without the need for any interaction except for monitoring the overall health of the test. 3.3 Environment The environment of which the tests ran was setup with a web server and web browser with the DASH client running on the same virtual machine. The machine used for the tests with the linear prefetching algorithm was running Windows/ and had no other software except for the browser and the server installed. For the tests with the non-linear prefetching algorithm we ran MacOS/ Linear prefetching For the linear prefetch strategy tested in this report, similarly to the strategy explained in Section 2.5. Where the web server pushes the k next video fragments of the same bit-rate when a request for a specific fragment is received, illustrated in Figure 3.1. The value of the k parameter, how many fragments to prefetch, has been varied across the range of 0-4 to observe any trends in the overall performance impact for the end-user. 11

20 3.4. Linear prefetching Figure 3.1: A request served with a K-push method. We made some server side logic to read the video fragment requests coming from the client to identify what fragments to push when using the linear prefetch method. When a fragment is requested the Go web server reads the request and responds with the fragment requested, it also pushes the k next fragments of the same quality. To allow for easy change of the value k we added an API endpoint on the server to allow dynamic changes from the web client. To fully investigate the gains of using HTTP/2 with server push when consuming linear media there has been six different test configurations where two of these, the configurations with HTTP/1.1 and HTTP/2 without server push, are used as baselines. One test produces one data point per second, that is 180 data points for average quality and 180 data points for average buffer occupancy. The test using HTTP/2 without server push will be compared to the test with HTTP/1.1. The test using server push, with a linear prefetch of 1-4 fragments, has been compared to the HTTP/2 baseline test. For each of the six tests configurations we have ran 10 tests. The results of these 10 tests per configuration has then been averaged across every second of which the test ran, so that 10 tests using a given configuration are reduced to one data set of 120 data points for quality and 120 data points for buffer occupancy representing the total average results of the tests with that configuration. With HTTP/1.1 A simple video streaming test with dash.js using HTTP/1.1 has been conducted and is the HTTP/1.1 baseline used to compare the following two tests. The test was conducted by adding a dash.js video player to a simple web page and rendering it in the browser without HTTP/2 enabled on the server. The video then started and played for 180 seconds until the results where automatically stored and the test restarted, this procedure repeated 10 times. Network throttling was enabled to limit the available bandwidth to 2.5 Mbit/s With HTTP/2 A HTTP/2 baseline test was also run to compare with the next test. The playback process and bandwidth throttling was the same as in the previous test. The test was run to make sure that no other HTTP/2 features other than server push, like multiplexing, is misinterpret as a performance gain in using server push. With HTTP/2 and server push In this test the linear prefetch strategy was implemented and enabled. The video playback process and bandwidth variation was the same as in the previous tests. A few different values of the parameter k was tested, which can be found in Chapter 4. Extracting data Player quality and buffer occupancy was logged in JavaScript once a second during the video playback. At the end of the test, at 180 second, the data collected in JavaScript was posted 12

21 3.5. Non-linear prefetching to the web server. The data was dumped to a file named according to the settings used and the time at which the test finished. When 10 tests had been run for every configuration we combined the results and averaged them. A separate program built in Go reads the files from a collection of files depending on the settings used during the test and synchronizes the timestamps. It then averages the quality and buffer occupancy for every time-stamp, removes the first 60 seconds of the tests and dumps the data to a single file. From this data a plot is generated in gnuplot 2, which is presented in Chapter 4. Comparing the results The first test performed was to measure the buffer occupancy and quality level with HTTP/2 and no linear prefetch. We then wanted to compare this result to the tests run over HTTP/2 with different linear prefetch fragments. The last test performed was again to measure buffer occupancy and quality level but now with HTTP/2 disabled and with no linear prefetch. To remove interference and irregularities by the start-up time in the video stream the first 60 seconds has been cut out. We averaged the 10 tests for each configuration to account for some deviation in the results. Quality and buffer occupancy variation To investigate how the playback quality and buffer occupancy varies we have selected two measurements, the standard deviation and another equation inspired by a report by Yin et. al. [15]. By using the equations (3.1) and (3.2) inspired by Yin et. al. [15] we can measure how the quality and buffer varies over time. 1 K 1 1 K 1 Kÿ q k 1 q k (3.1) k=a Kÿ b k 1 b k (3.2) k=a A high value would indicate "choppiness" in the values and a low value would indicate less changes in the data. K is defined as the total time the test ran, a is the point when to start considering variations (in our case 60 seconds), q k is the quality index at time k and b k is the buffer occupancy at time k. 3.5 Non-linear prefetching We have also created an implementation to prefetch for branched media with the goal of reducing the initial load time when branching a video. The initial load time is calculated from the point the page has loaded until the video starts playing. By automatically branching the video after 60 seconds and sampling the initial load time when using prefetching and when not using prefetching we have established some results. We have made two different tests with non-linear prefetching. The first test with HTTP/2 server push and the second test with client-side invoked HTTP requests, which we call HTTP pull. The difference between the two methods is that the HTTP pull method uses HTTP requests invoked at the clientside to prefetch fragments of the upcoming branches. The method using HTTP/2 server push uses server-side invoked pushes to push the fragments of the upcoming branches. We have made 15 tests in total to average the results. 5 tests without prefetching, 5 tests when prefetching with server push and the other 5 tests when prefetching with HTTP pull. The test is conducted by first playing a video, called stream 1. We sample the initial load time 2 Program for generating plots from csv files 13

22 3.5. Non-linear prefetching for stream 1. After 60 seconds we branch to a second video, stream 2. We sample the initial load time for stream 2. We repeat this procedure 5 times and average the initial load time for stream 1 and stream 2. We then enable our prefetching algorithm and repeat the tests. Our prefetching algorithm uses HTTP/2 server push to push the first 5 fragments of stream 2 as fragments for stream 1 is requested. The fragments that are pushed for stream 2 are of a pre-defined quality level, this is also the quality level that will be enforced on stream 2 during the first 10 seconds of playback. The reason that a pre-defined quality level has been selected is that dash.js would otherwise select a higher quality that can be played back because of the near instant response time of the pushed fragments. We sample the initial load time in the same way as in the tests without prefetching. By comparing these results we can observe what impact our prefetching algorithm has to the initial load time of stream 2. 14

23 4 Results This chapter covers the results of the tests performed over HTTP/1.1 and HTTP/2 with and without linear prefetching and the tests with non-linear prefetching. 4.1 Video file Quality indexes varies from 1-18, Table 4.1 shows the quality indexes with corresponding bitrates for the video used in the tests. Although there are 19 available qualities the results has been focused around quality index It is noticeable that the bandwidth for the average quality is lower than the 2.5 Mbit/s we throttled to in our tests. This might be an indication that the throttling is unstable or incorrect. It may also be an indication of the connection being slower for other reasons or that the video player selects a lower quality than what can be played back given the available bandwidth. Table 4.1: Quality index and corresponding bit-rates. Quality Bit-rate Quality Bit-rate Quality Bit-rate Quality Bit-rate kbps kbps kbps Mbps kbps kbps Mbps Mbps kbps kbps Mbps Mbps kbps kbps Mbps Mbps kbps kbps Mbps Mbps 15

24 4.2. Linear prefetching 4.2 Linear prefetching HTTP/1.1 Figure 4.1 shows the results of the test ran with HTTP/2 disabled, i.e. using HTTP/1.1. The plot shows the average buffer occupancy and quality level of all 10 test for each second. We can observe that the quality level is rather stable and does not incrementally decrease or increase. The buffer occupancy level moves up and down as video is played (removed from buffer) and downloaded (added to buffer). Note that the first 60 seconds of the tests has been discarded to stabilize the results and remove irregularities in initial buffer time, as mentioned in Chapter Quality index Buffer level Average quality index Average buffer level [seconds] Time [seconds] Figure 4.1: Average quality level and buffer level when using HTTP/1.1 HTTP/2 Figure 4.2 shows a section of the average values for the tests conducted without linear prefetch. The quality line shows that the quality level is unstable and incrementally decreases throughout the playback Quality index Buffer level Average quality index Average buffer level [seconds] Time [seconds] Figure 4.2: Average quality level and buffer level over time when using HTTP/2 without linear prefetching 16

25 4.2. Linear prefetching HTTP/2 - Server push enabled Linear prefetch with one fragment Figure 4.3 shows the average result of the tests conducted with linear prefetch with one fragment. Also here we can see that the quality level is unstable and incrementally decreases at the beginning of the tests at the same way as mentioned earlier in Figure 4.2. The decreasing quality could be an indication of an error when combining HTTP/2 server push and bandwidth estimation, although we have not been able to find the reason for this behaviour Quality index Buffer level Average quality index Average buffer level [seconds] Time [seconds] Figure 4.3: Average quality level and buffer level over time when using HTTP/2 and linear prefetch with k=1 Linear prefetch with two fragments Figure 4.4 shows the average result for all 10 tests over HTTP/2 with linear prefetch with two fragments. The quality level line shows that the quality level is unstable as in Figure 4.2 and Figure 4.3. This means there are no big differences on how the quality level acts with these three different settings for prefetching fragments Quality index Buffer level Average quality index Average buffer level [seconds] Time [seconds] Figure 4.4: Average quality level and buffer level over time when using HTTP/2 and linear prefetch with k=2 17

26 4.2. Linear prefetching Linear prefetch with three fragment The average buffer occupancy and quality level with three prefetching fragments of all 10 tests can be shown in figure 4.5 below. As seen in the plot, the quality level here decreases through the playback Quality index Buffer level Average quality index Average buffer level [seconds] Time [seconds] Figure 4.5: Average quality level and buffer level over time when using HTTP/2 and linear prefetch with k=3 Linear prefetch with four fragment The average result of linear prefetching with four fragments shows in Figure 4.6. The average quality level incrementally decreases throughout the playback. We can notice some improvement in the quality level compared to linear prefetching of three fragments seen in Figure Quality index Buffer level Average quality index Average buffer level [seconds] Time [seconds] Figure 4.6: Average quality level and buffer level over time when using HTTP/2 and linear prefetch with k=4 18

27 4.2. Linear prefetching Comparison Table 4.2 compares the results using HTTP/1.1 and HTTP/2. Note that the tests with HTTP/1.1 ran without TLS 1 encryption. Our tests shows that HTTP/2 has no major advantage or disadvantage over HTTP/1.1. Table 4.2: Comparison between the test using HTTP/1.1 and HTTP/2 Push fragment Avg. buffer level Avg. quality level Buffer gain Quality gain HTTP/ s 9.10 (baseline) (baseline) HTTP/2 (k=0) 11.13s % -6.7% A decrease of 6.7% in average quality is not a very significant change. Because the test totals 120 seconds 6.7% only accounts for about 8 seconds of decreased quality on average for HTTP/2 compared to HTTP/1.1. Table 4.3 shows the collected results over the test we made with 2.5 mbit/s bandwidth throttling. The gain indicates the change in relation to the HTTP/2 baseline. An overall positive gain in buffer level has been shown in all the tests with server push enabled. However, the type of impact on the average player quality varies between the different values of k showing a slight decrease for k value 3 and a slight increase for k values 1, 2 and 4. The maximum increase, when using k=2, only accounts for about 6 seconds on average spent on a higher quality meaning that the impact to the end user is minimal. Table 4.3 also shows the confidence interval for quality level. Table 4.3: Comparison between the test using HTTP/2 and linear prefetching Push fragment Avg. buffer level Avg. quality level Buffer gain Quality gain K=0 (no push) (baseline) (baseline) K= s , % 2.47% K= s % 4.59% K= s % -3.65% K= s , % 0.94% Table 4.4 shows the standard deviation σ over the data points collected for each of the five tests with HTTP/2. The variation has been measured on all data points, not the averaged results. The standard deviation indicates the stability in the results collected. This shows that the standard deviation for each buffer and quality does not give a huge different between each k value. This means that the test are stable. Table 4.4: Standard deviation for all the tests Test σ for buffer σ for quality HTTP/ K= K= K= K= K= These results shows a viability to benefit from HTTP/2 features without compromising the stability of video streaming quality or buffer occupancy on the client side. However, the standard deviation only tells us how much the average quality an buffer occupancy varies but not how it varies. 1 Transport Layer Security 19