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

Article Featured Image

We have also evaluated the link usage of HTTP/1.0, HTTP/1.1, and HTTP/2.0 with and without SSL encryption under varying round trip times (RTT), i.e. delay, focusing on DASH-based media streaming. HTTP/1.0 achieves link usage equal or higher than 90 percent within our experiments with RTTs ranging from 0 to 50ms. However, for RTTs that are typical for mobile access connections, i.e., 100 and 150ms, the link usage only ranges from 75 percent to 85 percent, caused by TCP slow start that influences every segment request. HTTP/1.1 resolves this issue with persistent connections and pipelining, enabling RTT tolerance and link usage higher than 93 percent for fixed and mobile access connection RTTs ranging from 0 to 150ms, as TCP slow start is only influencing at the beginning of the session. The performance of HTTP/2.0 is similar to HTTP/1.1, as a consequence that HTTP/1.1 can use a single persistent connection and pipelining. Nevertheless, it must be noted that HTTP/2.0 offers these functionalities implicitly, while in case of HTTP/1.1 it is not possible to use these features at any time due to proxies and servers that do not support these features, as they are optional and not mandatory.

Conclusion, Outlook, and Challenges

As shown, HTTP/2.0 in combination with DASH can significantly increase streaming performance, especially in mobile networks with high RTTs compared to HTTP/1.0. Furthermore, it eliminates a major problem of HTTP/1.1, i.e., Head-of-Line blocking (HoL). Besides that, HTTP/2.0 introduces an additional feature which allows the server to push resources to the client. This enables a completely new streaming approach on top of HTTP that can further reduce latency and overhead. For example, segments can be pushed to the clients during the segment generation process, enabling a low latency-based DASH approach. The client could be still in control of the adaptation process because it could notify the server when it should switch to a specific representation and afterwards the server will push segments of the selected representation to the client. An example for such a hybrid push/pull approach is shown in the figure below.

This could be a door opener for applications that can currently not be efficiently deployed with DASH, such as real-time communication applications or other applications that require a low latency streaming approach. Nevertheless, there are also challenges which arise with such an approach, e.g., how to cache pushed resources and serve clients while maintaining the session state, or transparently forwarding such a session to another server with the state information.

Other challenges will become more important in the future, such as seamless deployment of HTTP/2.0 with HTTP/1.0 and HTTP/1.1 being still out there on the client, as well as on the server side. Currently, Next Protocol Negotiation (NPN) and Application Layer Protocol Negotiation (ALPN) are under consideration to be used for this purpose. This allows an HTTP/2.0-enabled server to downgrade a connection to HTTP/1.1 or HTTP/1.0 if the client does not support it. Other mechanisms, such as in-band upgrade or DNS hints, are considered. Choosing and deploying the right mechanism which can be easily and seamlessly adopted by the industry will be key for the success of HTTP/2.0.

Additionally, HTTP/2.0 currently has security issues caused by compression ratio info-leak mass exploitation (CRIME) and present encoding table information leakage (PETAL). Moreover, the persistent connection feature that is offered by HTTP/2.0 implicitly binds a client to a specific server, in comparison to HTTP/1.0 where individual requests can be routed to different servers for load balancing transparently to the client. One can argue that with HTTP/2.0 it is still possible to request resources from different servers but this must be managed by the client, which can for example use all DNS resolved hosts in a round robin manner.

While, there are many opportunities we also have challenges to solve, but with such a flexible and efficient protocol stack, I am excited to see what applications will pop up.

May the DASH and also the HTTP/2.0 be with you!

Streaming Covers
for qualified subscribers
Subscribe Now Current Issue Past Issues
Related Articles

20 for 20: The Most Important Standards of the Last 20 Years

To celebrate Streaming Media's 20th year, here's an overview of 20 major patents and standards that have impacted the growth of the streaming media industry.

Will MSE/EME/DASH Lead to Simpler Workflows? Don't Bet on It

What the online video industry needs is simple standards for reaching all viewers. But when have standards ever simplified online video?

Why the Broadcasting Industry Should Get Behind DASH Adoption

Broadcasters want standards they can depend on to stand the test of time. What they don't want is to regularly change their entire video workflows.

The State of MPEG-DASH Deployment

MPEG-DASH is slowly but surely becoming the main competitor to HLS, driven by adoption by major players and intrinsic strengths. Here's who's using it now, who's going to be soon, and what challenges still need to be addressed.

A Post-IBC MPEG-DASH Status Check

How dynamic is MPEG-DASH ecosystem after IBC 2013? Here are an analysis of the latest trends and an extensive industry DASH-compliant solutions directory.

Companies and Suppliers Mentioned