WHITE PAPER

CDNs DEMYSTIFIED
Copyright 2012 Elemental Technologies, Inc. CDNs Demystified A Streaming Technology Primer

A Streaming Technology Primer

1

CONTENTS
Overview ....................................................................................................................................................... 3 What is a CDN? ............................................................................................................................................ 3 Basic CDN Video Functions .......................................................................................................................... 3 Protocols and Connections ........................................................................................................................... 3 Stateful Connections ................................................................................................................................. 3 Stateless Connections ............................................................................................................................... 4 CDN Content Onramp Strategies ................................................................................................................. 5 Physical Topology of a CDN ......................................................................................................................... 5 Elements of a CDN ....................................................................................................................................... 6 Conclusion..................................................................................................................................................... 8

Copyright 2012 Elemental Technologies, Inc.

CDNs Demystified A Streaming Technology Primer

OVERVIEW
The definition of a Content Delivery Network (CDN) is evolving as these providers expand the range of services they deliver and video suppliers they serve. This brief describes the fundamental capabilities and practices of a CDN as they relate to video processing functions, such as those provided by Elemental. Read on to gain a working knowledge of how a CDN operates, become familiar with terminology common to CDNs, and learn about the interactions that take place between the components that make up a CDN video delivery system.

WHAT IS A CDN?
A CDN is a system of software, hardware, and network components that acts as one large distributed computer. Services performed by a CDN may include digital media delivery, network transit, website acceleration, file storage, server co-location and cloud processing, among others. In addition to these services, most CDNs provide both analytic and provisioning control panels for video suppliers to configure and monitor their usage. This brief focuses predominantly on CDN services related to ingest and delivery of digital video content. CDNs can be regional, such as ChinaCache, or deployed worldwide, such as Akamai.

BASIC CDN VIDEO FUNCTIONS

CDN video services are divided into two basic types: Video On Demand (VOD) and live. VOD services are provided by CDN edge servers that deliver static pre-encoded video files to client video players. Live services are provided by CDN edge servers that deliver live contentdynamically generated video files or network data streams that originates from video encoders and is transported to client video players through the backbone network of the CDN. In most cases, these processes are transparent to the encoder source and client player.

PROTOCOLS AND CONNECTIONS

All interactions between video encoders and CDNs or video players and CDNs are defined by network protocols, such as HTTP or RTMP, and streaming delivery architectures, such as Apple HLS or Microsoft Smooth Streaming. Network connection protocols fall into two categories: stateful and stateless connections.

STATEFUL CONNECTIONS
Stateful connections are physical socket connections that exist between an encoder and a CDN or a player and a CDN. They remain connected throughout the duration of an encoder or player viewing session. CDNs frequently use specialized edge servers running media server software, such as Adobes Media Server or Wowza Media Server, to handle these types of connections. The network protocols used for these types of connections are usually proprietary and specific to the media server and player used. Examples of these include RTMP, RTMPE and MMS. These protocols utilize sophisticated client and server message stacks to optimize performance and user experience. Server, client and network status are utilized in negotiating video traffic between the client and server and also take into account the overall server load and performance. Although these protocols have been used for over a decade, they are being replaced by stateless based protocols primarily based on HTTP. Some of the key benefits of stateful connections include: the ability to track unique user sessions in viewing video content, lower latency, quicker startup, and better error control/handling. These can be difficult to emulate in stateless connections, but workarounds have been introduced.

Copyright 2012 Elemental Technologies, Inc.

CDNs Demystified A Streaming Technology Primer

STATELESS CONNECTIONS
Stateless connections use the HTTP protocol to deliver video content in one of three modes: progressive download, HTTP range request, or a type of manifest/file segment paradigm, such as Apple Streaming, Adobe HDS, and Microsoft Smooth Streaming. Progressive download delivery is characterized by a video player requesting a file and playing it as it downloads. The player does not require the entire file to be downloaded before displaying video. Typically, a video buffer exists in the range of 3-5 seconds. Progressive download was the first method used to present video on the internet. It is the most inefficient method because it does not support multi-bit rate delivery, and in many cases, a browser will download the entire video file regardless of what the user is viewing. Progressive download is the lowest common denominator in video delivery. Almost all players, devices and formats are supported and it only requires the CDN to provide the most basic HTTP 1.0 edge server to service the request. This still works well for short video clips, but is being replaced by newer methods of delivery described below. HTTP range request delivery is similar to progressive download, but differs in that the player makes multiple GET requests for sections of the video via the HTTP 1.1 range request/partial content mechanism. As the player is displaying video from one request, it is simultaneously requesting the next range of data from within the video file. In practice, there have been issues requiring smart players or smart HTTP servers to handle segment requests that fail to result in leading reference/Iframes. If a player requests a range request of data, usually in response to a seek function, it is possible the request will result in a video segment that does not have a leading reference/I-frame. If the player can handle these cases, no special functionality is required of the CDN other than basic HTTP 1.1 support on it edge servers. Some CDNs have enhanced HTTP servers that, when a request for media file types is made, will guarantee that the first frame returned in the video segment begins with a reference/I-frame. The most common implementation of HTTP range request video delivery has been the initial implementation of HTML5 players with WebM content. Others include Flash player, Flowplayer, JW Player and several other popular players. Manifest/file segment delivery has become the fastest growing method of delivery, primarily due to the explosion of video via mobile devices, tablets and web platforms, such as Netflix. This type of delivery is characterized by repetitive HTTP requests or pushes of video data chunks in the form of individual file segments. Each connection may or may not use the same physical network socket. Most implementations attempt to reuse connections through keep-alive mechanisms to promote for speed and efficiency. The three most common implementations are Adobe HTTP Dynamic Streaming (HDS), Microsoft Smooth Streaming (MSS), and Apple HTTP Live Streaming (HLS). In all three of these scenarios, the encoder simply pushes 2 10 second sequential file segments to an HTTP origin server and periodically updates the manifest file. In most cases, the files are written to disk and then proceed to be pushed to the CDN for distribution and delivery. Most player scenarios require a manifest file that is used by the player as a map of the video segment files. These stateless connections have a very simple HTTP protocol in which all request, logic, and optimization is performed by the player and there is no evaluation or awareness of server state. Although stateless connections may reuse a connection for each request, this is not guaranteed, which makes it difficult to map specific file requests to individual user sessions for reporting or analytics. That said, this type of delivery is very attractive to CDNs since it allows them to use existing generic servers, such as Apache, or slightly enhanced HTTP platforms, such as IIS, to deliver all of their content instead of relying on a fleet of media servers, which may include third party licensing fees and usually require specialized resources to configure and maintain. Additionally, many CDNs are optimized for small object delivery of content and now are able to move video around in small segments instead of large files. This decreases their network load and storage requirements while increasing efficiency and utilizing many of the cache management features in their existing HTTP delivery infrastructure.

Copyright 2012 Elemental Technologies, Inc.

CDNs Demystified A Streaming Technology Primer

CDN CONTENT ONRAMP STRATEGIES

There are two main strategies that are used to populate a CDN with customer content: push and pull. Push strategies are characterized by a computer outside the CDN pushing content to the CDN. This mechanism may be as simple as an FTP client pushing to a CDN FTP server, but in many cases the push mechanism is located on a CDN customer control panel. In this scenario, content from the video supplier is physically moved and prepositioned onto the CDN. The video supplier is then required to explicitly introduce each piece of content onto the CDN before it can be viewed or downloaded. Pull strategies are characterized by the CDN pulling a file from a HTTP or FTP server based on a request the CDN received for content. When the CDN receives a request for content that it does not have in its inventory, the CDN will retrieve (pull) the content from the video suppliers origin, as long as an origin has been defined. In a pull scenario, a specific predefined origin must be set up in the video suppliers CDN profile before a request is made. Frequently, the CDN simultaneously proxies the request back to the requesting client and propagates the content into the CDNs content management system.

PHYSICAL TOPOLOGY OF A CDN

A CDN consists of two tangible pieces: Points of Presence (PoP) and the Backbone Network (BBN). The BBN connects the PoPs together. Most of the services that video suppliers use are hosted on servers that reside within PoPs. The file and data transfer that occurs between PoPs usually transits over the BBN. The main value that CDNs provide is placing content in close proximity to the viewer requesting the content and reliable high-speed transfer of data between the PoPs. A CDNs performance is dependent on a number of factors: the number of PoPs they own, the proximity of these PoPs to the viewers making content request, the BBNs connection of the PoPs and the efficiency, reliability and performance of the CDN software that is used to deliver and manage content. Most traditional CDNs were built for hardwired delivery of content via ISPs. Recently, however, CDNs have re-architected for delivery via mobile wireless network providers. Points of Presence (PoP) are a collection of servers that a Akamai has 84,000 CDN places in a physical location. The server types and roles are described below in the Elements of a CDN servers in more than section. Not all PoPs contain all types of servers or serve 100 PoPs worldwide. the same purposes. Typically, CDNs operate under the strategy of owning PoPs in areas of dense population and close geographical proximity to the large number of viewers that are accessing content from video suppliers. In many cases, CDN PoPs are co-located in MSO/ISP back office installations. Large CDNs, such as Akamai, have hundreds of PoPs worldwide. A Backbone Network (BBN) is the system that CDNs use to connect PoPs. In some cases, these are dedicated private data pipes between PoPs, while in other cases, they may be shared peering arrangements, whereby they are not dedicated to CDN traffic but are also not used as part of the public internet. A non-CDN company may own dedicated links between cities that are not fully subscribed, and may peer or lease access to these pipes. The reason CDNs use a dedicated backbone is to provide transfers between PoPs using high speed, dedicated, managed and monitored network resources, as opposed to relying on the public internet.

Copyright 2012 Elemental Technologies, Inc.

CDNs Demystified A Streaming Technology Primer

ELEMENTS OF A CDN
Several elements comprise a CDN and they are effectively described by the roles they play in delivering video content. Below are some of the common roles and their functional descriptions. As previously stated, not all PoPs will play all these roles, though a physical server may serve multiple purposes. Origin (Ingest) servers are the entry point to place content onto the CDN. In the case of live content, these can either be media servers, such as IIS, FMS or Wowza, or, in the case of HTTP Live Streaming (HLS), an HTTP web server. Live encoders have to correctly define these entry points before they will be able publish live content to a CDN. The publishing point, authentication credentials and encryption information is usually provided to the customer by the CDN. This information may also be obtained through the CDNs configuration control panel. For VOD or HLS content, these are typically FTP sites, HTTP servers or HTTP upload functions from a UI control panel. For stateful protocols such as RTMP or RTSP, there are usually publishing points defined in the media server. In the case of Microsoft Smooth Streaming, although it uses the stateless HTTP protocol, it is stateful in that it uses one long running post request.

Distribution Servers tend to be deployed within each geographical Point of Presence (PoP). The purpose of these servers is to provide a fanned-out distribution of content from a single point or points within a PoP/CDN to all of the edge servers within that PoP. Some CDNs use multicast network delivery as a distribution system within a PoP, or possibly within their entire network. There are usually multiple distribution servers to provide failover. Edge Servers deliver content to the viewers client players. In addition to providing live and VOD content, they offer client authentication, logging, access control, and many other functions related to the clients interaction with the CDN. Typically, a CDN will have tens or hundreds of edge servers in a PoP. The actual content that is served from an edge server may come from a variety of sources: o Software Cache Recently requested content is usually cached within the edge delivery software that handles incoming requests. The cache is tunable, but in general the last/least requested cache object is the first to be removed. This caching is frequently chunks or segments of individual files, and not necessarily an entire file.

Copyright 2012 Elemental Technologies, Inc.

CDNs Demystified A Streaming Technology Primer

Local File System Many CDNs will store recently requested files on the local disk file system. Based on the CDN and individual customer policy rules, content will be removed after a defined period of time or inactivity. Similar to caching, the last/least requested file is usually the first to be removed. Not all CDNs use local file disk storage, but use their edge servers in cache/proxy-only roles. This is especially true of dedicated HLS edge servers. SAN Network Storage Many CDNs have a SAN within a PoP that an edge server may use to request content. This type of storage may have an NFS or some other mount point. In many cases, they may use HTTP, NNTP or some other protocol for file request. Origin Pull If an edge server receives a request that it does not have in cache, on disk, or in remote network storage, it will make a request to a CDN origin server that will retrieve the file from the video supplier. This is usually an HTTP or FTP request. The edge server will simultaneously retrieve the file from the CDN origin server and proxy it back to the requesting client. In many cases, the origin server will also place the file into the CDNs content management and inventory system.

File servers are the near-line storage that CDNs use to hold content. These servers are not usually accessible to customers of the CDN. CDNs use these as mezzanine storage devices for content supplied by customers. In many cases, a CDN will remove content from an edge server if it is inactive. If a request is made for content that has been aged out, the CDN software will retrieve it from the file server, and place it back at the edge. Network DVR Archive Servers are used to record live content and create an archive VOD representation for later viewing. Some systems provide DVR capabilities that allow viewing of the recorded segment before the live event is actually completed. In this case, if a viewer joins a live event after the broadcast has started, they are able to rewind to the beginning or any other part of the live event, as long as it has already been delivered by the CDN. Origin Servers are typically of two types in any CDN implementation: customer origin servers and origin pull servers. o Video supplier origin servers are usually web or FTP servers outside of the CDN that reside on the video suppliers network and are controlled by the video supplier. This is where a video supplier will place content and it usually requires authenticated access. These origins typically have to be defined in the video suppliers CDN control panel so the CDN will know where to find particular content and how to authenticate it. Origin pull servers are used by CDNs to retrieve content from a video suppliers origin server in the case of a pull request. A request for content a CDN does not have in storage will result in an origin pull server making a request to a customer origin server to retrieve this content and propagate it throughout the network. A key point here is that a flood of requests for an object not already within the CDN does notor should notgenerate a flood of requests to the video suppliers origin server. These requests should instead be funneled into a single request and proxied out through the edge servers. This shields the video suppliers origin server from being overwhelmed by requests.

Copyright 2012 Elemental Technologies, Inc.

CDNs Demystified A Streaming Technology Primer

URL Request Resolvers are the front door of the CDN for all requests. (Typically, URL request resolvers accept a request, such as videosupplier.cdn.com/path/content, which may result in a request to videosupplier.cdn.ny1.edge033/path/content.) These requests may be redirected based on geography, CDN load, inventory availability, network routing, cost of service, quality of service, or many other rules to lead to a specific edge server. The request resolver services the request for content as fast as possible by directing the request to an edge server that has the content and is physically closest to the client that is requesting the content. While the concept is relatively straightforward, this tends to be the secret sauce that differentiates CDNs and defines their performance. Because of this, there are many patents and lawsuits concerning request resolution. Configuration Control Panel In the early days of the CDN industry, all configuration and management was accomplished by back office service request systems similar to a phone companys service provisioning system. Video suppliers did not have the ability to directly manage their accounts and all changes were implemented through this service provisioning method. As CDN software and customer-facing services evolved, CDNs provided control panels for customer access and account management. Example account settings include live event definitions, content cache control, configurable guidelines for bandwidth and usage, log reporting definitions, content authentication, video supplier origins, and many other attributes that are used to define a CDNs account and content profile. Analytics/Billing Control Panel Most CDNs today provide video suppliers with raw logging data and analytics to access and review usage metrics. These are usually bandwidth and storage statistics that directly relate to billing. The control panel is the visible user interface for the CDN, and can go a long way to impact a video suppliers purchasing decision.

CONCLUSION
With a broad range of capabilities and service offerings, CDNs provide critical infrastructure and play a crucial role in the global distribution of video content from encoding sources such as those supplied by Elemental. In an expanding video universe with an ever widening number of playback devices, video suppliers increasingly rely on CDN technologies and/or services to effectively deliver video content to end users.

Copyright 2012 Elemental Technologies, Inc.

CDNs Demystified A Streaming Technology Primer