Multimedia streaming over HTTP is no longer a niche research topic as it has entered our daily lives. The common assumption is that it is deployed on top of the existing infrastructure, utilizing application (HTTP) and transport (TCP) layer protocols as is. Interestingly, standards such as MPEG’s Dynamic Adaptive Streaming over HTTP (DASH) do not mandate the usage of any specific transport protocol allowing for sufficient deployment flexibility which is further supported by emerging developments within both protocol layers. Therefore, we investigate and evaluate the usage of advanced transport options for the dynamic adaptive streaming over HTTP. We utilize a common test setup to evaluate HTTP/2 and the Quick UDP Internet Connections (QUIC) protocol in the context of DASH-based services.
The Hypertext Transfer Protocol Version 2 (HTTP/2) is available as RFC7540 within the standards track and QUIC is currently developed as informational Internet draft providing a UDP-based secure and reliable transport for HTTP/2 including loss recovery and congestion control.
Some time ago we already looked into HTTP/2 and this time we start describing how to combine it with QUIC.
Introduction
Adaptive multimedia streaming over-the-top of the existing infrastructure using HTTP is a major driver for innovation within both industry and academia. The MPEG standard Dynamic Adaptive Streaming over HTTP (DASH) provides interoperable representation formats in terms of media presentation description (MPD) and segments based on the ISO base media file format and MPEG-2 transport stream. Interestingly, the standard mandates the usage of HTTP-URLs for locating segments but not how they are actually delivered to the client. The general assumption is that a standard HTTP infrastructure is used which is deployed on top of TCP for the delivery of both MPD and segments. In practice, however, various (transport) protocols could be used such as in 3GPP which specifies DASH over (e)MBMS/FLUTE in a mobile broadcast environment. Another option for DASH is HTTP/2 which is based on Google’s SPDY.
While HTTP/2 is tightly coupled with TCP, earlier versions of HTTP actually do not mandate the usage of TCP although almost all implementations assume TCP to be used, specifically its means for reliable transport. The performance of TCP for media streaming applications has been analytically assessed concluding that the bandwidth requirement is about twice the media bitrate. Various improvements – both at the HTTP and the TCP layer – have shown significant performance gain, specifically when adopting persistent connections and pipelined requests as defined within HTTP/1.1. These features definitely provide a performance boost but suffer from the Head-of-Line (HoL) blocking problem and together with TCP’s streaming inflexibility, has lead to ad-hoc developments such as Google’s Quick UDP Internet Connections (QUIC) protocol and also SPDY; the latter being turned into HTTP/2. The performance of HTTP/2 in the context of DASH has already been assessed (i.e., compared with selected features of HTTP/1.0 and HTTP/1.1), so we look into its combination with QUIC here.
The aim of this work is to provide a baseline performance assessment of DASH-based services with advanced transport options, both at the application and transport layer. At the application layer, we investigate the usage of SPDY/HTTP/2 and HTTP/1.1 (with persistent connection and pipelined requests enabled); at the transport layer, we consider TCP and QUIC. For the actual evaluation, we examine the protocol overhead, link utilization and adaptation performance for the following combinations: (a) HTTP/2 over TCP, (b) HTTP/2 over SSL (and TCP), (c) HTTP/1.1 over QUIC, and (d) SPDY over QUIC. Please note that HTTP/2 and SPDY share the same principles despite minor format differences; but this shall not impact its performance. In this paper we adopt MPEG-DASH for the actual streaming format; but results are also applicable for other formats sharing the same principles (e.g., Apple HTTP Live Streaming). The evaluation setup is standard to enable cross-validation with both results, e.g., when targeting future enhancements.
MPEG-DASH
MPEG-DASH and related formats sharing the same principles (e.g., Adobe HDS, Apple HLS, Microsoft Smooth Streaming) enable adaptive HTTP streaming by providing multiple, time-aligned versions (e.g., different bitrate, resolution, codec, language) of segmented media files (e.g., 2-10 seconds) on ordinary Web servers which clients individually request in a dynamic and adaptive way, depending on its usage environment (e.g., available bandwidth, display resolution, codec support, language preference of the user).
A major requirement of the standard was to support the usage of standard Web servers without the need for any media- or streaming-specific extensions to enable reuse of the existing infrastructure deployed for the provisioning and delivery of regular Web traffic. The common assumption is that the intelligence is solely within the client implementation which requests segments – as described in the MPD – based on its context conditions. This adaptive client behavior and the supported media codecs are not normatively defined within the standard. The DASH Industry Forum provides interoperability points going beyond the MPEG specification including recommendations for selected media codecs, test vectors, and conformance software.
SPDY and HTTP/2
This section describes HTTP/2 which is based on Google’s SPDY protocol and at the time of writing of this blog post is available as IETF RFC7540.
The protocol is mandating the Transmission Control Protocol (TCP) and maintains a single persistent connection for each session. During a session, multiple streams can be opened between the client and the server in full-duplex mode. Typically, only one HTTP/2 connection between a server and a client exists until the client navigates to another server. The servers should leave connections open as long as possible until a given threshold timeout or when a client initiates a connection close.
The advantage of HTTP/2 is that it is fully compatible with HTTP/1.1 and can be integrated as a session layer between HTTP and TCP, hence, enabling incremental deployment. The HTTP request will be mapped into a HTTP/2 frame and vice versa for the HTTP response. Additionally, it is also possible to send multiple requests in parallel to support pipelining. Therefore, HTTP/2 offers an interface for HTTP, which simplifies its integration for already existing HTTP applications. After this handover from HTTP/1.1 to HTTP/2 the whole communication will be handled on the HTTP/2 framing layer until a response arrives which will be passed to the HTTP/1.1 layer.
Google further developed SPDY which is available as Draft 3.1 and still maintains two frame types for control and data frames but with similar functionality as within HTTP/2. However, they recently discontinued its development and instead focus more on HTTP/2.
QUIC
Quick UDP Internet Connections (QUIC) is an experimental, UDP-based transport layer network protocol which aims at reduced connection latency, congestion control, multiplexed/pipelined requests without head-of-line blocking, forward error correction (FEC) and connection migration.
During the connection establishment, the client speculatively assumes to have acceptable cryptographic credentials for at least a preliminary encryption of a request. In case the server does not accept the credentials, additional negotiations may be needed but, conceptually, all handshakes have a zero-RTT in QUIC.
The variable length (2-19 bytes) packet header comprises public/private flags, connection identifier, version information, sequence number, and FEC data. Streams are independent sequences of bi-directional data packets, which can be created both by the client and the server. For the congestion control, QUIC comes with two different approaches: (a) to mimic the TCP CUBIC algorithm, and (b) an inter-arrival scheme based on WebRTC. Implementations are required to support (a) and encouraged to implement also (b).
SPDY and QUIC are designed to work independently from each other, but when SPDY is implemented over QUIC, the QUIC layer handles most of the stream management. In particular, SPDY streams IDs are replaced by QUIC stream IDs without explicit framing and the data sent over the QUIC stream simply consists of SPDY headers followed by the body.
We hope you enjoyed reading this introduction to DASH, HTTP/2, and QUIC.
For further reading and an exciting conclusion to our exploration of advanced transport options for dash, go to part two here.
Generate MPEG-DASH and HLS Content
Transcode your content with Bitmovin’s Cloud Encoding Service. Bitmovin is a high-performance adaptive bitrate transcoding and streaming platform enabling transcoding in orders of magnitudes faster than real time – this means transcoding, e.g., a 2-hour HD video in minutes! Sign up below to try it today for free!
Best,
Christian Timmerer, CIO and Head of Research and Standardization
Contact Christian Timmerer: [email protected]
Follow Christian on Twitter: @timse7
Follow Bitmovin on Twitter: @bitmovin
