Linköpings universitet SE–581 83 Linköping +46 13 28 10 00 , www.liu.se 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
Transcript
Linköpings universitetSE–581 83 Linköping
+46 13 28 10 00 , www.liu.se
Linköping University | Department of Computer ScienceBachelor thesis, 16 ECTS | Datateknik
2017 | LIU-IDA/LITH-EX-G--17/073--SE
HTTP/2, Server Push andBranched Video– Evaluation of using HTTP/2 Server Push in DynamicAdaptive Streaming over HTTP with linear and non-linearprefetching algorithms.
Utvärdering av HTTP/2 Server Push vid adaptivvideoströmning.
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 årfrå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 enstakakopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och förundervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva dettatillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. Föratt garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefa ttar rätt att bli nämnd som upphovsman iden omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sättsamt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende elleregenart. För ytterligare information om Linköping University Electronic Press se förlagetshemsida http://www.ep.liu.se/.
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 circum-stances. The online availability of the document implies permanent permission for anyone toread, to download, or to print out single copies for his/hers own use and to use it unchangedfor non-commercial research and educational purpose. Subsequent transfers of copyrightcannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measuresto assure authenticity, security and accessibility. According to intellectual property law theauthor has the right to be mentioned when his/her work is accessed as desc ribed aboveand to be protected against infringement. For additional information about the LinköpingUniversity Electronic Press and its procedures for publication and for assurance of documentintegrity, please refer to its www home page: http://www.ep.liu.se/.
Students in the 5 year Information Technology program complete a semester-long softwaredevelopment project during their sixth semester (third year). The project is completed in mid-sized groups, and the students implement a mobile application intended to be used in a multi-actor setting, currently a search and rescue scenario. In parallel they study several topicsrelevant to the technical and ethical considerations in the project. The project culminatesby demonstrating a working product and a written report documenting the results of thepractical development process including requirements elicitation. During the final stage ofthe semester, students create small groups and specialise in one topic, resulting in a bachelorthesis. 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 thesemester, including the conditions and requirements for a bachelor thesis.
Abstract
The purpose of this thesis is to investigate and test the usage of HTTP/2 in dynamic adap-tive video streaming as well as to take a look into how it can be used to benefit prefetchingalgorithms used with branched video. With a series of experiments the performance gainsof using HTTP/2 rather than the older standard HTTP/1.1 has been investigated. Theresults has shown no significant change to player quality and buffer occupancy when us-ing HTTP/2, though our tests has shown in a slight decrease in overall playback qualitywhen using HTTP/2. When using a linear prefetch of two fragments an average qualityimprovement of 4.59% has been shown, however, the result is inconclusive due to vari-ations 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%, whenusing linear prefetch with three fragments. The values for buffer occupancy gains are con-clusive. Two implementations for non-linear prefetching has been made. The first one usesHTTP/2 server push to deliver fragments for prefetching and the second one uses client-side invoked HTTP requests to pull fragments from the server. Using HTTP/2 server pushhas shown in a decrease of 2.5% in average total load time while using client-side pullinghas shown in a decrease of 34% in average total load time.
Acknowledgments
We would like to thank our supervisor Niklas Carlsson and his colleague VengatanathanKrishnamoorthi for the guidance, help and support during the entire project. We also wantto thank the team behind DASH.js and the Go programming language.
2.1 Comparison of simplex, multiplex and server push. . . . . . . . . . . . . . . . . . . 52.2 A 20 second video file divided into several fragments of 5 seconds and different
qualities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Client request a fragment that is delivered by the server . . . . . . . . . . . . . . . . 62.4 An example of a branched video with two branch points. . . . . . . . . . . . . . . . 7
3.1 A request served with a K-push method. . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1 Average quality level and buffer level when using HTTP/1.1 . . . . . . . . . . . . . 164.2 Average quality level and buffer level over time when using HTTP/2 without lin-
ear prefetching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.3 Average quality level and buffer level over time when using HTTP/2 and linear
prefetch with k=1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.4 Average quality level and buffer level over time when using HTTP/2 and linear
prefetch with k=2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.5 Average quality level and buffer level over time when using HTTP/2 and linear
prefetch with k=3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.6 Average quality level and buffer level over time when using HTTP/2 and linear
4.1 Quality index and corresponding bit-rates. . . . . . . . . . . . . . . . . . . . . . . . 154.2 Comparison between the test using HTTP/1.1 and HTTP/2 . . . . . . . . . . . . . 194.3 Comparison between the test using HTTP/2 and linear prefetching . . . . . . . . . 194.4 Standard deviation for all the tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.5 Variation for all the tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.6 Load times with and without prefetching and comparison on total load time. . . . 21
viii
1 Introduction
1.1 Motivation
Video streaming is becoming increasingly popular and more people choose to consume me-dia content via their Internet connection. The multinational technology conglomerate Ciscopredicts that by the year of 2020 video streaming will account for about 80% of the Inter-net data traffic [3]. Video streaming is without a doubt a hot-topic in the technology sec-tor. HTTP1, commonly used to deliver video content, was not originally designed for videostreaming. Because of this, more adaptation at the application level is required to give bet-ter support for video streaming. In the search for a more effective solution for HTTP, thenewer version of HTTP, named HTTP/2, has been developed. This thesis covers how videostreaming can benefit from features in the relatively new standard HTTP/2, which is there tocomplement and eventually replace the old standard HTTP/1.1. The improvement of videostreaming can have a huge impact for the end user. This means reduced data usage, reducedbattery usage and increased video quality. One of the new features in HTTP/2 is server pushthat allows the web server to push multiple resource to the client without requiring an explicitrequest 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, inthe video streaming context, has any performance gains. And how it can be implementedin branched video streaming. In this thesis we have investigated when HTTP/2 and serverpush is preferred over HTTP/1.1 and what issues HTTP/2 server push can solve compared toHTTP/1.1 in video streaming with the DASH2 protocol. An investigation to find if HTTP/2can 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 usingHTTP/2 server push technology.
1Hyper Text Transfer Protocol2Dynamic Adaptive Streaming over HTTP
1
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 videostreaming?
1.4 Delimitations
HTTP/2 has many new features but in this thesis the focus is on the server push functional-ity. To limit the results from the experiments only quantitative results will be collected andconsidered, such as how much video is buffered at a given point or what quality is playedback. An implementation with server push in a common web server and customization’s forvideo streaming over HTTP/2 has been made. The first implementation is based on a linearprefetch strategy, other strategies to using server push in video streaming, like non-linearprefetching, have also been investigated. The second implementations is an algorithm fornon-linear prefetching when playing media of type branched video.
2
2 Theory
This theory chapter covers how HTTP/2 differs from HTTP/1.1 and the basics of how dy-namic adaptive streaming over HTTP works. It also covers a background about branchedvideo 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/2is a constant ongoing process, many large Internet companies has already adopted HTTP/2and many others are expected to follow. Because HTTP/1.1 is still relatively common it isvery relevant to look at how it works. HTTP in general is a request driven protocol where aclient, usually refereed to as a web browser, send a request to a server to fetch a web pagewith some content. The resource fetched usually contains links to other resources that alsoneeds to be fetched to display a page in full, such as images and style-sheets. HTTP/1.1 doesnot feature any type of multiplexing, meaning that resources requested by the client cannotbe streamed asynchronously. So the client will have to wait for one response to finish beforereceiving a response for the next request. This means that if the client wants to load tworesources, one fast and one slow, and the slow resource gets requested first, the fast resourcecannot be sent until the slow one has finished which causes unnecessary waiting, this typeof flow is illustrated in Figure 2.1. This synchronous process is not suitable for today’s richweb 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 streamingrequests often share the same pipeline as the web page they are located on, they will also takea part in the waiting process for other resources. If another request is being responded towhen the web browser is trying to request another video fragment then the video requestwill have to wait for the other request to finish, this might cause a video to stall1 duringplayback.
Another problem with HTTP/1.1 is that it in general requires one round trip to the serverper request made. This becomes a big issue in high-latency networks. To address this HTTPpipelining was introduced where a number of request can be served over the same TCP con-
1Video sizes to play for a short period of time.
3
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. Acommon way to work around the issue of no multiplexing as default in HTTP/1.1 is to usemultiple TCP connections. However, this is not a formal part of the standard of HTTP/1.1and is not required. It is also usually limited to a maximum of six parallel connections andhas no support for prioritizing responses.
2.2 HTTP/2
Internet Engineering Task Force (IETF) introduced a new version of HTTP in the RFC 7540standard named HTTP/2 [1]. HTTP/2 is an updated version of HTTP/1.1 that includes avariety new features like server push, stream multiplexing and minimizing protocol over-head via efficient compression of HTTP header fields. The aim is to address the issues ofHTTP/1.1 and in turn contribute to a faster Internet. The server push technology was orig-inally designed to help reduce web page load latency by allowing the web server to pushcontent that the client might need in the near future, such as external resources on a pagethe client is currently rendering. This means that some resources may be transmitted to theclient before the client is done parsing the link to that content. The idea is that the server canmaintain a persistent connection with the client and push multiple resources at the same timewithout a need to require a request for every resource. This means that the round trip delaywhich comes with the request-response model can be avoided and the server can simplypush all resources the client will need when requesting a specific page into its web browsercache-memory. When the client eventually wants to make a request for a specific resourcethe request can be instantly loaded if the content is already stored in the web browsers cache-memory.
Figure 2.1a shows a typical request/response pattern when requesting a website from aHTTP/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 trans-ferred, a very steep slope would indicate a large file as it would take longer time for it tobe 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. Fig-ure 2.1c shows a typical request/response patterns when using HTTP/2 and server pushenabled. Responses are both loaded asynchronously and responses to resource 2 and 3 arepushed by the server instantly rather than requested.
4
2.3. Dynamic adaptive streaming over HTTP
(b)Multiplex:
Resources are loaded in parallel
(a)Simplex:
Resources are loaded in sequence
request 1
response 1
request 2
response 2
request 3
response 3
request 1
response 1
request 2
response 2
request 3
response 3
(c)Server push & multiplexing:
Resources are pushed and loaded in parallel
request 1
response 1
push 2
push 3
finish
finish
finish
Client
Tim
e
Server Client
Tim
e
Server Client
Tim
e
Server
Figure 2.1: Comparison of simplex, multiplex and server push.
In the context of video streaming some clear benefits of using HTTP/2 can be identified;multiplexing, which keeps requests from blocking the ability for video content to reach theuser in time to be played and server push, which allows video content to be pushed to theuser instead of being transmitted upon request.
2.3 Dynamic adaptive streaming over HTTP
DASH is a protocol used to deliver video content to the user in an adaptive mode. Adaptivemode means that the bit-rate of the video quality selected for playback should not exceed theavailable bandwidth. To allow for this adaption process the original video is split into differ-ent fragments of a pre-defined length, these fragments are then encoded into different qualitylevels at different bit-rates making them different in size. Figure 2.2 shows an illustration ofhow a video could be split into different fragments.
Fragment 1: 1200.0 kbps Fragment 2: 1200.0 kbps Fragment 3: 1200.0 kbps Fragment 4: 1200.0 kbps
Fragment 1: 570.0 kbps Fragment 2: 570.0 kbps Fragment 3: 570.0 kbps Fragment 4: 570.0 kbps
5 seconds
Video file
5 seconds 5 seconds 5 seconds
Quality index 2
Quality index 1
Figure 2.2: A 20 second video file divided into several fragments of 5 seconds and differentqualities
Because the video is split into these fragments of different qualities the client may now freelyselect which of these fragment to download, as illustrated in Figure 2.3. If the selected videoquality which the client downloads exceeds the available bandwidth the client will not beable to download video fragments in time to be played back, this causes the video to stall,
5
2.3. Dynamic adaptive streaming over HTTP
which causes buffering2. This type of behaviour is unwanted. The available bandwidth iscalculated by the client as it downloads video fragments and it is up to the client to choosewhich fragments to request and download from the server. This client driven interaction isvery suitable for the distributed structure of many video streaming services, as there is noneed for servers to keep track of different states or do any bandwidth estimations, as this ismanaged by the client.
Figure 2.3: Client request a fragment that is delivered by the server
DASH uses an MPD3 file which is first fetched by the client when a video streaming processis about to begin. The MPD file have a variety of options and tells the client where to findthe different video fragments as well as what video encoding has been used to encode thefragments. The MPD file also contains options for minimum and/or maximum buffer. Theminimum buffer is a value of how many seconds of video data the client needs to have inits buffer before starting a video playback, if the buffer content falls below this threshold thevideo continues to play. If the client buffer is entirely empty it will not continue playbackuntil enough fragments has been fetched to reach the minimum buffer threshold. This optionhelps to keep the client from constantly freezing in bad bandwidth conditions. The maximumbuffer 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 bandwidthconditions improves over time. By selecting these factors with care the client can be giveninstructions to help balance great video quality with the risk of stalling to buffer more videocontent.
The goal of this adaptive streaming mode is to allow users to consume video data in asmooth playback even though bandwidth conditions are bad. The downside of adaptivestreaming is that users with unstable connections might experience a lot of shifts in videoquality, 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 havedifferent characteristics such as different buffer thresholds.
Dash.js
A commonly used implementation of DASH for websites is dash.js written in JavaScript. Thisimplementation is specially suitable for usage in web browsers as most browsers has supportfor JavaScript. It works by including a JavaScript file into the web-page and then defining aHTML5 video element with a link pointing to the MDP file. This implementation is the oneused in the experiments conducted and was selected due to its common usage and activedevelopment.
Bandwidth estimation in dash.js
One of the factors that has to be taken into consideration when using a specific implemen-tation of DASH is to look at how the bandwidth is estimated. Dash.js estimates bandwidthby using the first received response byte for measuring latency and the time to final byte to
2The process of downloading content to be played3Media Preparation Description
6
2.4. Branched video and prefetching
measure bandwidth. When using this estimation for adaptive bit-rate selection the measuredbandwidth is averaged by a sliding scale. Special consideration in the experiments as to notaffect 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, everyuser receives the same flow of information. Non-linear is the opposite where every userreceives a different flow of information depending on their interactions. A common usage fornon-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].
1
3
5
2
4
Figure 2.4: An example of abranched video with two branchpoints.
Branched video is a type of non-linear media of whichthe users can select different playback paths through thevideo without noticing interruptions in the video quality[8][10]. A playback path is in most cases selected by theconsumer. A path could represent a sub-story or an al-ternative chain of events that the consumer can choose towatch. Because of the interactive nature of branched videothe wait time between selecting a branch until the switch-ing is done will need to be fairly low, as not to affect theconsumers experience. Figure 2.4 shows how a branchedvideo might be divided into different paths.
Branched video is similar to the concept of alternativevideos or recommended videos. Where the user can se-lect from a range of different videos to continue to watchafter the current video has finished. This is common among different video streamingproviders. Although branched video puts even more requirements on the low switch timeswhen 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 videostream. Most often also the same quality of which is played back. This is most suitable forlinear, 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 differ-ent video streams. These fragments could either be of the video currently being consumedor of alternative videos that will be presented to the user when the current video finish. Themethod is most suitable for non-linear media.
To access a seamless switching between different paths in non-linear media, prefetchingand buffer management is often used [8][10]. The player prefetch fragments for each possiblepath into a prefetch buffer and manages the content of the video [8]. Prefetching is also use-ful to provide attractive recommended video choices to the users that often switch quicklybetween 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 recom-mended videos need to be prefetched and buffer managed parallel to the video being playedto achieve an instant playback when a user select one of these recommended videos [9].
7
2.5. Related works
Branched video
Krishnamoorthi et al. [10] define branched video as a traditional linear HAS4 video thatallows the video designer to define arbitrary playback sequences through the underlyinglinear video and allows the user to choose between alternative playback sequences. Thepaper 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 toanother to the last possible moment. And give an uninterrupted playback and maximize thevideo quality.
Alternative videos
Krishnamoorthi et al. [9] covers a design, implementation and evaluation of an HAS frame-work to provide prefetching and buffer managing of the alternative videos. The prefetchingdesign and performance was based on three policy classes called best-effort, token-based anddeadline based. In Best-effort policies chunks from the alternative videos will be prefetchedonly when the buffer occupancy reaches maximum value Tmax. Token-based policies prefetchchunks in the same way as in best-effort policies but there are differences in how these twopolicies decides from which video to be prefetched next. The token-based method uses a con-stant rate to determine when to prefetch fragments of a video. This policy provides greatercontrol at which time an alternative video may first be prefetched. Deadline-based policies, asopposed to token-based policies, provides specific deadlines at which the alternative videosneed to be done prefetching rather then when to start prefetching them. This is done to ensurethat the alternative videos will be prefetched in time to be played and ensuring that the videois of the highest quality. This type of policies are important for users that prefer a smoothswitching between the alternative videos.
Multi-video stream bundles
Carlsson et al. [2] introduce and present a system design of a general multi-video stream bun-dle framework. The multi-video stream bundle consists of multiple "parallel" video streamwhich are synchronized in time. Each of these multiple video streams provides the videofrom different cameras capturing the same shot or movie. The idea is to allow for exampleproducers to give the freedom to users to switch between different perspective at differenttimes. The multi-video stream bundle framework is to impact the quality adaptive featuresand 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 serveror the time it takes for the web client to process the received data. The use of predictiveprefetching can address some of the latency issues in the web. Predictive prefetching basicallymeans having resources that are likely to be accesses later be prefetched by the client. Thiswould 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 pushcould have in adaptive streaming. Their focus has been on testing if using push could al-low the mobile device radio unit to go into sleep mode between bulks of pushing a certainamount of video fragments. They describe the HTTP/2 server push functionality as "[...] an
4HTTP Adaptive Streaming
8
2.5. Related works
elegant way of changing the HTTP request schedule in video streaming without compromis-ing the scalability of HTTP streaming or making changes to the HTTP resources.". A methodthey refereed to as the K-push strategy was introduced, where the server would push the ksubsequent video fragments for the given bit-rate when the client sends their request for avideo fragment of that bit-rate. This strategy would limit the amount of request the client hasto send to the server as well as transmitting a set of fragments in bulk rather than spreadingthem out with a given interval. Sending fragments in bulk means that for a given period oftime, when the sent fragments has been received and are awaiting to be played, the radiounit can enter sleep mode until another request is sent for the next k fragments. One of theproblems covered in the report is selecting a suitable value for k, such as allowing the radiounit to enter sleep mode. This value can be derived from the power consumption model ofthe mobile device to reach an optimal value.
Van der Hooft et. al. [6] discuss the merits of an HTTP server push approach. The paperis a study based on first performing measurements on the available network in real 4G/LTEnetworks within the city of Ghent in Belgium. Secondly analyzing the induced bit-rate over-head for video fragments with a sub-second duration. They determined that the fragmentduration time should not be lower than 500 ms to limit the overhead to 9.2%. They havedone the experiments by using MiniNet framework with a single client and streaming theencoded video from a Jetty server. The client is implemented on the libdash library which isthe official reference software of the MPEG-DASH standard. Their results showed in highervideo 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 QoE5 of HAS.The paper covers how to improve the QoE of HAS by reducing the number of video freezescaused by rebuffering. How to reduce the number of quality level changes, reduce the latencyfor live streaming and reduce the interactivity delay by using HTTP/2 features. The mainfocus is to design and implement an HTTP/2 push approach in live streaming. The push-based 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 bereduced by 90.1% and the average start-up delay can be reduced by 40.1%.
5Quality och Experience
9
3 Method
To test the viability of using HTTP/2 and server push in video streaming context we havecarefully measured the impact of using HTTP/2 compared to HTTP/1.1. We have done thiswith two different types of prefetching: one linear prefetching algorithm and one non-linearprefetching 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 performancegains, when using server push. We have investigated two factors identified as related to theoverall user experience; buffer occupancy and video quality. The buffer occupancy is mea-sured as the average seconds of video the player has buffered during the playback. The over-all player quality is the average quality level at which the player is requesting and playingfragments. To make it possible to focus on the main problem we have used an existing DASHimplementation and a web server that supports HTTP/2. However, to enable the HTTP/2server push feature we have implemented a server side logic using the programming lan-guage Go/1.8.1. Because it is also important to use a web client that support HTTP/2, Operahas been selected to perform the tests.
3.1 Web server
When traditionally implementing DASH most web servers are sufficient as no special webserver support or server side logic is needed to make DASH function, outside of supportingthe HTTP standard. Using HTTP/2 will not require any server side logic either, only a webserver 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 confor-mance of over 90% is considered to be acceptable as long as there is full support for serverpush. Because HTTP/2 is such a wide, and relatively new, standard a 100% conformance isnot expected by almost any modern web servers. And our test should not be affected by asmall 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 toolcalled h2spec1. h2spec provides a test suite that can run against any web server to check whatfeatures of HTTP/2 are supported.
Because we needed to implement some server side logic to get our prefetching algorithmsto work properly we wanted to use a web server implementation that allowed us to customizewhat happens when a request is served. We therefore turned to the programming languageGo which has a built in HTTP/2 package and support for server push. When we ran a confor-mance test using the h2spec testing tool we got a conformance result for the HTTP/2 packagein Go/1.8.1 of 92%. The tests showed that Go/1.8.1 had full support for server push. Becauseof 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 abilityto properly limit the available bandwidth by simply delaying the chunks outgoing data ac-cording to a specified limit, this limit is given in Mbit/s and can be changed through a simpleAPI. The bandwidth throttling is built with a steady function meaning that the end result isstable, no deviations or overshoot in the supplied bandwidth occurs. The throttling featureuses a timed loop to copy the response bytes at a desired rate. This rate is also divided by thenumber of concurrent connections to simulate one throttled connection. We have also testedwith Woundershaper, a program to limit bandwidth, but it gave overshoot which we did notwant in our tests. The effect of the throttling code has been tested by downloading a large fileand 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 forHTTP/2. Opera/43.0.2442.1165 was used in the tests. A HTML web page was created with adash.js client added. The pages also features an added live preview graph that gives instantinsight 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 thetimer runs out the test results are automatically stored to a file and the test is reset. Thisallow for running many consecutive tests without the need for any interaction except formonitoring 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 withthe DASH client running on the same virtual machine. The machine used for the tests withthe linear prefetching algorithm was running Windows/10.0.14393 and had no other softwareexcept for the browser and the server installed. For the tests with the non-linear prefetchingalgorithm we ran MacOS/10.12.3.
3.4 Linear prefetching
For the linear prefetch strategy tested in this report, similarly to the strategy explained inSection 2.5. Where the web server pushes the k next video fragments of the same bit-ratewhen a request for a specific fragment is received, illustrated in Figure 3.1. The value ofthe k parameter, how many fragments to prefetch, has been varied across the range of 0-4 toobserve any trends in the overall performance impact for the end-user.
11
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 clientto identify what fragments to push when using the linear prefetch method. When a fragmentis 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 valuek 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 linearmedia there has been six different test configurations where two of these, the configurationswith HTTP/1.1 and HTTP/2 without server push, are used as baselines. One test producesone data point per second, that is 180 data points for average quality and 180 data points foraverage buffer occupancy. The test using HTTP/2 without server push will be compared tothe 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 wehave ran 10 tests. The results of these 10 tests per configuration has then been averagedacross every second of which the test ran, so that 10 tests using a given configuration arereduced to one data set of 120 data points for quality and 120 data points for buffer occupancyrepresenting 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 theHTTP/1.1 baseline used to compare the following two tests. The test was conducted byadding a dash.js video player to a simple web page and rendering it in the browser withoutHTTP/2 enabled on the server. The video then started and played for 180 seconds until theresults 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 processand bandwidth throttling was the same as in the previous test. The test was run to make surethat no other HTTP/2 features other than server push, like multiplexing, is misinterpret as aperformance gain in using server push.
With HTTP/2 and server push
In this test the linear prefetch strategy was implemented and enabled. The video playbackprocess and bandwidth variation was the same as in the previous tests. A few different valuesof 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 videoplayback. At the end of the test, at 180 second, the data collected in JavaScript was posted
12
3.5. Non-linear prefetching
to the web server. The data was dumped to a file named according to the settings used andthe time at which the test finished. When 10 tests had been run for every configuration wecombined the results and averaged them. A separate program built in Go reads the files froma collection of files depending on the settings used during the test and synchronizes the time-stamps. It then averages the quality and buffer occupancy for every time-stamp, removesthe first 60 seconds of the tests and dumps the data to a single file. From this data a plot isgenerated in gnuplot2, which is presented in Chapter 4.
Comparing the results
The first test performed was to measure the buffer occupancy and quality level with HTTP/2and no linear prefetch. We then wanted to compare this result to the tests run over HTTP/2with different linear prefetch fragments. The last test performed was again to measure bufferoccupancy 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 60seconds has been cut out. We averaged the 10 tests for each configuration to account for somedeviation in the results.
Quality and buffer occupancy variation
To investigate how the playback quality and buffer occupancy varies we have selected twomeasurements, 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 howthe quality and buffer varies over time.
1K´ 1
Kÿ
k=a
|qk´1 ´ qk| (3.1)
1K´ 1
Kÿ
k=a
|bk´1 ´ bk| (3.2)
A high value would indicate "choppiness" in the values and a low value would indicate lesschanges in the data. K is defined as the total time the test ran, a is the point when to startconsidering variations (in our case 60 seconds), qk is the quality index at time k and bk is thebuffer occupancy at time k.
3.5 Non-linear prefetching
We have also created an implementation to prefetch for branched media with the goal ofreducing the initial load time when branching a video. The initial load time is calculated fromthe point the page has loaded until the video starts playing. By automatically branching thevideo after 60 seconds and sampling the initial load time when using prefetching and whennot using prefetching we have established some results. We have made two different testswith non-linear prefetching. The first test with HTTP/2 server push and the second testwith client-side invoked HTTP requests, which we call HTTP pull. The difference betweenthe two methods is that the HTTP pull method uses HTTP requests invoked at the client-side to prefetch fragments of the upcoming branches. The method using HTTP/2 serverpush uses server-side invoked pushes to push the fragments of the upcoming branches. Wehave made 15 tests in total to average the results. 5 tests without prefetching, 5 tests whenprefetching with server push and the other 5 tests when prefetching with HTTP pull. Thetest is conducted by first playing a video, called stream 1. We sample the initial load time
2Program for generating plots from csv files
13
3.5. Non-linear prefetching
for stream 1. After 60 seconds we branch to a second video, stream 2. We sample the initialload time for stream 2. We repeat this procedure 5 times and average the initial load timefor 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 stream2 as fragments for stream 1 is requested. The fragments that are pushed for stream 2 are of apre-defined quality level, this is also the quality level that will be enforced on stream 2 duringthe first 10 seconds of playback. The reason that a pre-defined quality level has been selectedis that dash.js would otherwise select a higher quality that can be played back because of thenear instant response time of the pushed fragments. We sample the initial load time in thesame way as in the tests without prefetching. By comparing these results we can observewhat impact our prefetching algorithm has to the initial load time of stream 2.
14
4 Results
This chapter covers the results of the tests performed over HTTP/1.1 and HTTP/2 with andwithout 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 bit-rates for the video used in the tests. Although there are 19 available qualities the results hasbeen focused around quality index 8-11. It is noticeable that the bandwidth for the averagequality is lower than the 2.5 Mbit/s we throttled to in our tests. This might be an indicationthat the throttling is unstable or incorrect. It may also be an indication of the connectionbeing slower for other reasons or that the video player selects a lower quality than what canbe played back given the available bandwidth.
Table 4.1: Quality index and corresponding bit-rates.
Figure 4.1 shows the results of the test ran with HTTP/2 disabled, i.e. using HTTP/1.1. Theplot shows the average buffer occupancy and quality level of all 10 test for each second. Wecan observe that the quality level is rather stable and does not incrementally decrease orincrease. The buffer occupancy level moves up and down as video is played (removed frombuffer) and downloaded (added to buffer). Note that the first 60 seconds of the tests has beendiscarded to stabilize the results and remove irregularities in initial buffer time, as mentionedin Chapter 3.
7
7.5
8
8.5
9
9.5
10
60 80 100 120 140 160 1808
9
10
11
12
13
14
15
16
Ave
rage
qua
lity
inde
x
Ave
rage
buf
fer
leve
l [se
cond
s]
Time [seconds]
Quality indexBuffer level
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 linearprefetch. The quality line shows that the quality level is unstable and incrementally decreasesthroughout the playback.
7
7.5
8
8.5
9
9.5
10
60 80 100 120 140 160 1808
9
10
11
12
13
14
15
16
Ave
rage
qua
lity
inde
x
Ave
rage
buf
fer
leve
l [se
cond
s]
Time [seconds]
Quality indexBuffer level
Figure 4.2: Average quality level and buffer level over time when using HTTP/2 withoutlinear prefetching
16
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 frag-ment. Also here we can see that the quality level is unstable and incrementally decreases atthe beginning of the tests at the same way as mentioned earlier in Figure 4.2. The decreasingquality could be an indication of an error when combining HTTP/2 server push and band-width estimation, although we have not been able to find the reason for this behaviour.
7
7.5
8
8.5
9
9.5
10
60 80 100 120 140 160 1808
9
10
11
12
13
14
15
16
Ave
rage
qua
lity
inde
x
Ave
rage
buf
fer
leve
l [se
cond
s]
Time [seconds]
Quality indexBuffer level
Figure 4.3: Average quality level and buffer level over time when using HTTP/2 and linearprefetch 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 twofragments. The quality level line shows that the quality level is unstable as in Figure 4.2 andFigure 4.3. This means there are no big differences on how the quality level acts with thesethree different settings for prefetching fragments.
7
7.5
8
8.5
9
9.5
10
60 80 100 120 140 160 1808
9
10
11
12
13
14
15
16
Ave
rage
qua
lity
inde
x
Ave
rage
buf
fer
leve
l [se
cond
s]
Time [seconds]
Quality indexBuffer level
Figure 4.4: Average quality level and buffer level over time when using HTTP/2 and linearprefetch with k=2
17
4.2. Linear prefetching
Linear prefetch with three fragment
The average buffer occupancy and quality level with three prefetching fragments of all 10tests can be shown in figure 4.5 below. As seen in the plot, the quality level here decreasesthrough the playback.
7
7.5
8
8.5
9
9.5
10
60 80 100 120 140 160 1808
9
10
11
12
13
14
15
16
Ave
rage
qua
lity
inde
x
Ave
rage
buf
fer
leve
l [se
cond
s]
Time [seconds]
Quality indexBuffer level
Figure 4.5: Average quality level and buffer level over time when using HTTP/2 and linearprefetch with k=3
Linear prefetch with four fragment
The average result of linear prefetching with four fragments shows in Figure 4.6. The averagequality level incrementally decreases throughout the playback. We can notice some improve-ment in the quality level compared to linear prefetching of three fragments seen in Figure4.5.
7
7.5
8
8.5
9
9.5
10
60 80 100 120 140 160 1808
9
10
11
12
13
14
15
16
Ave
rage
qua
lity
inde
x
Ave
rage
buf
fer
leve
l [se
cond
s]
Time [seconds]
Quality indexBuffer level
Figure 4.6: Average quality level and buffer level over time when using HTTP/2 and linearprefetch with k=4
18
4.2. Linear prefetching
Comparison
Table 4.2 compares the results using HTTP/1.1 and HTTP/2. Note that the tests withHTTP/1.1 ran without TLS1 encryption. Our tests shows that HTTP/2 has no major ad-vantage or disadvantage over HTTP/1.1.
Table 4.2: Comparison between the test using HTTP/1.1 and HTTP/2
A decrease of 6.7% in average quality is not a very significant change. Because the test to-tals 120 seconds 6.7% only accounts for about 8 seconds of decreased quality on average forHTTP/2 compared to HTTP/1.1.
Table 4.3 shows the collected results over the test we made with 2.5 mbit/s bandwidththrottling. The gain indicates the change in relation to the HTTP/2 baseline. An overallpositive gain in buffer level has been shown in all the tests with server push enabled. How-ever, the type of impact on the average player quality varies between the different values ofk showing a slight decrease for k value 3 and a slight increase for k values 1, 2 and 4. Themaximum increase, when using k=2, only accounts for about 6 seconds on average spent ona higher quality meaning that the impact to the end user is minimal. Table 4.3 also shows theconfidence interval for quality level.
Table 4.3: Comparison between the test using HTTP/2 and linear prefetching
Table 4.4 shows the standard deviation σ over the data points collected for each of the fivetests with HTTP/2. The variation has been measured on all data points, not the averagedresults. The standard deviation indicates the stability in the results collected. This shows thatthe standard deviation for each buffer and quality does not give a huge different betweeneach k value. This means that the test are stable.
Table 4.4: Standard deviation for all the tests
Test σ for buffer σ for qualityHTTP/1.1 0.12 0.74K=0 0.30 0.67K=1 0.32 0.66K=2 0.49 0.73K=3 0.48 0.90K=4 0.31 1.24
These results shows a viability to benefit from HTTP/2 features without compromising thestability of video streaming quality or buffer occupancy on the client side. However, thestandard deviation only tells us how much the average quality an buffer occupancy variesbut not how it varies.
1Transport Layer Security
19
4.2. Linear prefetching
Table 4.5 shows that the quality variation decreases slightly the more fragments we push.However, the variation of quality when HTTP/2 is enabled is still higher compared toHTTP/1.1. The tests ran over HTTP/1.1 was more stable compared to HTTP/2 and thatmay explain why the quality index varies more with HTTP/2.
Figure 4.7 shows the collected results for the linear prefetcher including marked confidenceintervals. The confidence of the results are fairly high.
-5
-4
-3
-2
-1
0
1
2
3
4
5
6
k=1 k=2 k=3 k=4
Ave
rage
Qua
lity
Cha
nge
[%]
Number of prefetched fragments
Figure 4.7: Results for linear prefetching with confidence intervals
20
4.3. Prefetching with branched video
Figure 4.8 shows the variations compared to each other. We can notice that the variations forthe buffer occupancy is scattered which means that the results are less stable. Because of thisit will be harder to draw conclusions based on the average buffer occupancy measurement.
0.02
0.04
0.06
0.08
0.1
0.12
0.14
HTTP/1.1 K=0 K=1 K=2 K=3 K=4
0.2
0.4
0.6
0.8
1
1.2
Qua
lity
vari
atio
n
Buf
fer
vari
atio
n
Quality variationBuffer variation
Figure 4.8: Variations for quality and buffer occupancy compared
4.3 Prefetching with branched video
Table 4.6 shows the results for the average load time for the tests with branched video. Theload time is roughly the same when no prefetching is being used, which is expected. Whenusing server push to prefetch video data for stream 2 the total load time is 2.5% lower thanusing no prefetching. The load time for stream 1 is higher, most likely because data for stream2 is loaded simultaneously with stream 1. When using the HTTP pull method the total loadtime is lowered by 34% compared to not using any prefetching. The load time for stream 1is also increased but not as much as in the tests with server push. Both the HTTP pull andHTTP/2 server push method loads stream 2 simultaneously as stream 1 when prefetching,why the load times for stream 1 differs between these two methods is unknown.
Table 4.6: Load times with and without prefetching and comparison on total load time.
Prefetching Load time stream 1 Load time stream 2 Total load time ChangeNo prefetching 2836.33ms 2294ms 5130.33ms (baseline)Server push 4757.6ms 243.4ms 5001ms -2.5%HTTP pull 3163.6ms 222.4ms 3386ms -34%
21
5 Discussion
5.1 Linear prefetching
The effect of the slightly increased average quality that we have observed in the results whenusing server push is that the video player spends slightly more time playing a higher quality.A decrease in average player quality an indication that more time has been spent playing alower quality. It is generally desirable to have high player quality for as long time as possiblebut still have enough buffer so that the player does not run out of video to play resultingis stalls. However, the observed differences are rather small and does not really indicate inany significant differences between our tests. Because of this, other factors should also beconsidered when choosing whether or not to use HTTP/2 with a server push based on linearprefetching.
Overall, in our tests, HTTP/2 has been slightly worse than HTTP/1.1. Because of this, theintroduction of HTTP/2 in video streaming could cause some issues. It is however importantto note that this conclusion is based entirely on the results shown in this thesis. HTTP/2 alsohas other features to take benefit from that has not been investigated here. Also the fact thatTLS encryption has been used for HTTP/2 must be taken into consideration. Not using TLScould also be the explanation as to why HTTP/1.1 had slightly better results than HTTP/2.
The stability of the tests has been measured by looking at the variations of quality andbuffer occupancy, as presented in Chapter 4. When using HTTP/2 without server push thevariations were at its largest value. When using server push the variations decreased slightly.HTTP/1.1 had the most stable results. Having a stable buffer occupancy is not all too relevantto the users direct experience, the buffer occupancy only becomes relevant if it falls to 0 andthe video stalls. We have not had any stalls in any of our tests. Having a more stable qualityis more noticeable by the user. If the quality varies too much too often the user might getdistracted from the video.
In all of the tests with HTTP/2 we can see a slight decrease in quality throughout the tests.We do not have a conclusive reason for this. It could relate to either the server, browser, videostreaming implementation or underlying network infrastructure. One factor that can come toplay is the fact that HTTP/2 uses a long lived, single, TCP connection between the client andserver. The tests has also been run with no competing traffic on the network. It is possiblethat the introduction of competing traffic might change the results shown in our tests.
22
5.2. Non-linear prefetching
The observed gains when using server push compared to not using server push withHTTP/2 has shown a maximum quality increase of 4.59% at k = 2. This is in line with whathave been observed by Van der Hooft et. al. [6], described in Chapter 2.
5.2 Non-linear prefetching
In section 5.1 we have discussed the viability of using HTTP/2 in video streaming basedon the results from our tests. We have shown that using HTTP/2 to deliver video contentonly has a slight disadvantage. We have also shown that HTTP/2 can be used in non-linearprefetching to enhance loading times for branched video.
For the non-linear prefetching method best-effort, presented in Chapter 2, video frag-ments of the available branches to the current video should be prefetched once the clientbuffer occupancy of the current video reaches a given value Tmax. However, because serverpush relies on strictly server-side logic, the best-effort model is less suitable for usage withserver push. Unless the client can signal when the value Tmax has been reached, as the clientis alone in knowing the value of the buffer occupancy.
For token-based prefetching the fragments of available branches are prefetched at a givenrate s from a given start time t. If t = 0, meaning that the prefetching process should begininstantly when the video is requested, server push can be used to periodically push fragmentsof the available branches until the client-server connection is closed. However, if t ą 0, it willbe harder for the server to determine the actual value of t. Since the client is alone in knowingwhat point in the video is currently playing. Similarly to the best-effort this would requirethe client to signal the server to start pushing fragments for prefetching.
For deadline based prefetching the prefetching process is started at a point in time t =a´ b so that every fragment to be prefetched finished at a given point in time t = a. Whereb is the time it would take to download all of the fragments to be prefetched. To determine bthe prefetching initializer needs to be aware of the file size and current bandwidth available.Because of this, the server would have to determine the average bandwidth upload speedtowards the client when using server push to prefetch.
The simplest solution to using server push when prefetching non-linear media, amongthose mentioned in this report, should be the token-based model as this requires the leastamount of server side logic to be implemented. However, using HTTP/2 server push in along session is risky as the persistence of the underlying TCP connection cannot be insured.Therefore it is better to use server push in the start of a session rather than pushing sometime after the initialization has begun. In our experiments we experienced these problemswith the long lived TCP connection. One reason for this could be a low TCP Keep Alive set-ting that would evict the TCP connection prematurely while we are still pushing fragments.This causes the server-client connection to stall. Because of this we choose to implement ourprefetching for non-linear media at the start of a session. This has other benefits such as thefact that users doesn’t always wait until the end before switching video stream.
With the introduction of predictive methods, such as machine learning, to decide whatfragments to prefetch we see a much bigger benefit of using HTTP/2 server push. Becausethe predictive models often reside at the server side the server can take automatic decisionson what fragments to push instead of requiring the client to actively fetch them. A simpleexample is a machine learning model that is trained with data of a users context such as timeof day, location, age etc. whenever a user makes a choice of a branched video path. Based onthat data the server could predict branches by similar users and push the start of the branchthat the user is most likely to take.
23
5.3. Prefetching branched video
5.3 Prefetching branched video
When we implemented a simple prefetching algorithm for branched video, where the first5 fragments for the available branches are pushed at the initialization of a video, we sawa significant decrease in initial load time for the branches. This algorithm is based on thetoken-based model where t = 0 meaning that fragments are starting to be pushed at theinitialization of the first video. This means that the transition from one stream to the otheris going to be more smooth even on connections with low bandwidth. Some more extensivetesting could have been made using this method by changing the number of fragments toprefetch and the number of branches that are available.
One improvement to the prefetching algorithm is to more intelligently select which qual-ity to prefetch for the branches. Also, if there are multiple branches, what branches to actuallyprefetch. We suggest taking an average quality of the current video during the first x secondsof playback and use that quality when prefetching. This would match the prefetched qualitywith a quality suitable for the clients available bandwidth. Another thing to consider is theability to program server-side logic to use prediction to determine what branches to push tothe user. This would allow the server to customize what branches are prefetched for a specificuser based on what branch the user is most likely to proceed. A benefit of placing the taskof prefetching on the server-side is that the server can take decisions based on observationsfrom other users. A problem with doing this on the server-side only is that the client videoplayer cannot detect if a fragment has been pushed using HTTP/2 server push. This couldlead to the client missing the opportunity to play a prefetched fragment and in term wastedata traffic.
5.4 Method
To test the viability of using HTTP/2 with server push for video streaming we have imple-mented a simple linear prefetching algorithm. Due to some technical limitations and prob-lems we have been unable to complete a non-linear prefetching algorithm. This mostly dueto limitations in the standard library in Go/1.8.1 that wont allow us to initialize a push aftera request has finished. This could of course be worked around by initializing a request fromthe client every time a push is wanted, however, this is a bit contradictory to the point ofeliminating unnecessary client requests by using server push in the first place. So as of now,a correct non-linear prefetching approach would be rather difficult to implement withoutchanging the underlying software. Having more time to fine-tune the implementation wouldhave given a higher chance of making a successful solution with a non-linear prefetching al-gorithm. We have also noted some stability problems when using server push in long livedTCP connections where the connection between server and client stalls sometimes. Possibleimprovements to the method could be to increase the stability in the network setup by finetuning the TCP Keep Alive parameters. Another improvement is to increase the amount oftests made and to do the tests over a varied bandwidth situation. This would be a closer rep-resentation of a real world scenario. Also, testing other non-linear prefetching policies such asdeadline-based and best-effort to compare with our prefetching algorithm might show otherresults. Which could help to explain the relativley small gains observen in using HTTP/2server push for prefetching non-linear media.
5.5 The work in a wider context
There are many advantages of prefetching for both linear and non-linear media. With thecurrent development of media such as 360˝ video, virtual reality, branched video there is def-initely a need to improve and adapt video streaming. Not only do users want to consumehigher quality content but also more content overall, as mentioned in the introduction. Also,
24
5.5. The work in a wider context
users who live in areas with worse bandwidth conditions or users who pay per usage are es-pecially affected by small optimization’s. A wide introduction of HTTP/2 in video streamingcould also have a negative effect, given the results from our investigations, as we have shownin an overall decreased quality level when using HTTP/2.
25
5.6. Conclusion
5.6 Conclusion
In our experiments we have tested HTTP/2 when using Dynamic Adaptive Streaming overHTTP and shown that HTTP/2 does not cause any large performance drops compared toHTTP/1.1. The experiments shows that using HTTP/2 does give some minor drops in end-user video quality of -6.7%. Buffer occupancy is increased with 1.82% when using HTTP/2.
When using the HTTP/2 feature server push to implement a linear prefetch strategy someperformance gains has been shown. Average buffer occupancy is increased by up to 12.58%,when using a linear prefetch of three fragments. Average video quality is increased by up to4.59%, when using a linear prefetch of two fragments. These gains are similar to those ob-served in other related papers. This results shows a viability of using HTTP/2 server push toimplement linear prefetching in DASH. A problem with a constant decrease in video qualitywhen using HTTP/2 has been shown in our test, but a conclusive reason behind this has notbeen determined.
Non-linear prefetching for branched video has also been discussed and has shown to beviable. Especially when combined with a predictive prefetching pattern where resources areprefetched based on server-side predictions. In this report three different approaches to non-linear prefetching has been investigated; best-effort, token-based and deadline-based. Wehave also made a simple implementation of a non-linear prefetcher based on the token-basedmodel. Out of the three models mentioned token-based has been identified as the simplestmethod to implement in practice.
We also implemented two non-linear prefetching algorithms using HTTP/2 server pushand HTTP pull. Out of these methods the HTTP pull algorithm has shown the greatest overallimprovement to user experience with a lowered total load time of 34%.
The end result of improving video streaming is faster and more stable experience for theend user. Improvements also benefit users who have limited access to bandwidth. This isimportant because video streaming is becoming increasingly popular.
26
Bibliography
[1] M. Belshe, R. Peon, and Ed. M. Thomson. “Hypertext Transfer Protocol Version 2(HTTP/2)”. In: RFC 7540 (2015).
[2] N. Carlsson, D. Eager, V. Krishnamoorthi, and T. Polishchuk. “Optimized AdaptiveStreaming of Multi-video Stream Bundles”. In: IEEE TMM (2017).
[4] R. Fielding, UC Irvine, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T.Berners-Lee. “Hypertext Transfer Protocol – HTTP/1.1”. In: RFC 2616 (1999).
[5] D. Gotz. “Scalable and adaptive streaming for non-linear media”. In: Proc. ACM MM(2006).
[6] J. van der Hooft, S. Petrangeli, T. Wauters, R.Huysegems, P. Rondao Alface, T. Bostoen,and F. De Turck. “HTTP/2-Based Adaptive Streaming of HEVC Video Over 4G/LTENetworks”. In: IEEE Communications Letters (2015).
[7] R. Huysegems, T. Bostoen, P. Rondao Alface, J. van der Hooft, S. Petrangeli, T. Wauters,and F. De Turck. “HTTP/2-Based Methods to Improve the Live Experience of AdaptiveStreaming”. In: Proc. ACM MM (2015).
[8] V. Krishnamoorthi, P. Bergström, N. Carlsson, D. Eager, A. Mahanti, and N. Shah-mehri. “Empowering the Creative User: Personalized HTTP-based Adaptive Streamingof Multi-path Nonlinear Video”. In: Proc. ACM SIGCOMM (2013).
[9] V. Krishnamoorthi, N. Carlsson, D. Eager, A. Mahanti, and N. Shahmehri. “Bandwidth-aware Prefetching for Proactive Multi-video Preloading and Improved HAS Perfor-mance”. In: Proc. ACM MM (2015).
[10] V. Krishnamoorthi, N. Carlsson, D. Eager, A. Mahanti, and N. Shahmehri. “Quality-adaptive Prefetching for Interactive Branched Video using HTTP-based AdaptiveStreaming”. In: Proc. ACM MM (2014).
[11] L.Chen, Y.Zhou, and D.Ming Chiu. “A study of user behavior in online VoD services”.In: Computer Communications (2014).
[12] Venkata N. Padmanabhan and Jeffrey C. Mogul. “Using Predictive Prefetching to Im-prove World Wide Web Latency”. In: Proc. ACM SIGCOMM (1996).
[13] R. Peon and H. Ruellan. “HPACK: Header Compression for HTTP/2”. In: RFC 7541(2015).
27
Bibliography
[14] S. Wei, V.Swaminathan, and M. Xiao. “Power Efficient Mobile Video Streaming UsingHTTP/2 Server Push”. In: Proc. IEEE MMSP (2015).
[15] X. Yin, A. Jindal, V. Sekar, and B. Sinopoli. “A Control-Theoretic Approach for DynamicAdaptive Video Streaming over HTTP”. In: proc. ACM SIGCOMM (2015).
