August 7, 2014
By Christopher Mueller CTO and Co-Founder of Bitmovin GmbH
Featured Articles

HTTP/2.0 and DASH: Planning Tomorrow's Improved Video Delivery

HTTP traffic has grown extensively driven by the immense growth of multimedia traffic. Nowadays, it could be seen as the protocol to deploy new services and applicationsand it is also heavily used by the industry, due to the fact that it provides advanced features for modern internet architectures:

It is a content centric protocol that decouples names from addresses through DNS
It provides caching elements and middle boxes as reverse and forward proxies
It enables scalable and flexible content deployment with content distribution, already leveraged by Content Distribution Networks (CDN)

However, there is room for improvement as many services are still using HTTP/1.0 which was specified in May 1996, or are not using all the features of HTTP/1.1, such as persistent connections or pipelining. For example, already deployed HTTP streaming solutions such as Microsoft Smooth Streaming, Apple HTTP Live Streaming, and Adobe Dynamic Streaming do not use HTTP/1.1 pipelining with persistent connections, which could increase the streaming performance by up to 30 percent. Unfortunately, there are not many proxies that support HTTP/1.1 pipelining with persistent connections, due to the Head-of-Line (HoL) blocking problem where one pending response could possibly delay a range of other responses. The problem is that the proxy has to send in-order responses, which means that earlier arriving out-of-order responses will be blocked until the response that causes the HoL blocking arrives.

Head-of-Line blocking

In order to overcome these shortcomings the Internet Engineering Taskforce (IETF) Hypertext Transfer Protocol Bis (httpbis) working group has recently started the development process of HTTP/2.0. Three proposals have been submitted to the IETF, i.e., Google SPDY, Microsoft HTTP Speed+Mobility, and Network-Friendly HTTP Upgrade, where Google’s SPDY proposal has been chosen as working draft for HTTP/2.0. Moreover, several major companies, e.g., Facebook, Twitter, Akamai, Firefox, and obviously Google itself support SPDY already or have announced that they will support it in the near future.

SPDY is already used for all Google web services when users connect with the Google Chrome or Mozilla Firefox browser, which implies that it will be already heavily tested and further improved due to the results of these tests. SPDY could be used as session layer between HTTP and TCP to multiplex multiple HTTP requests over one single TCP connection while requiring no or little changes from the application layer. The major benefits of SPDY are that it offers multiplexing over one TCP connection, prioritized requests, compressed headers, and the option for the server to push resources to the client.

This features can eliminate the HoL blocking problem, due to the single TCP connection that can be used for multiple prioritized streams with compressed HTTP headers and will enhance the performance of HTTP/1.0 significantly.

DASH & HTTP/2.0

Dynamic Adaptive Streaming over HTTP (DASH) has been specified to be used with HTTP/1.x but it can be seamlessly integrated with HTTP/2.0 as it can act as a session layer between HTTP and TCP with DASH on top of the HTTP layer. We have already integrated HTTP/2.0 into our libdash solution and shown that the performance can be significantly increased compared to HTTP/1.0.

Basically, we have evaluated the overhead of HTTP/1.0, HTTP/1.1, and HTTP/2.0 with and without SSL encryption with a specific focus on DASH-based media streaming. It could be seen that the overhead of HTTP is negligibly small, i.e., 5 percent to 7 percent for segmented DASH-based streams with 2 second segments and media bitrates higher than 700kbps. Additionally, it can be seen that the HTTP/2.0 overhead is slightly higher than the overhead of HTTP due to its framing layer. However, the slightly increased overhead is negligible, as it enables delay tolerance, which will be shown in the next experiment.