More articles in this series and about OTT/Streaming:

To improve video streaming performance in a lean and efficient way, we should focus on removing the delivery network bottlenecks. Rather than expanding the peering points into ISP networks and/or expand the ISP core networks themselves, we should design a video delivery network that literally removes traffic from these bottlenecks by distributing video edges to new deeper network locations.

The pull system of video streaming means that ultra-efficient streaming at full-scale must be enabled at the edge of the video delivery network, where a single live stream, linear channel or VOD file could be delivered many, many times to different viewers on their individual IP-connected devices. In contrast, the centralized origination point of the video delivery ecosystem is where a single channel, live event, or VOD asset places almost equal load on the infrastructure (i.e., a one-hour video file in a multi bitrate ladder requires broadly the same level of central storage, transcoding, packaging and origination processing if it is watched by 10 different people or by 10 million people). Origins scale with the content, while Edges scale with the audience, and this basic difference neatly highlights the need for different technology deployment and management strategies.

To repeat an important point: distributing the video Edge removes traffic from ISP core networks. It does not mean that traffic bypasses the core network. Rather, the bits and bytes still travel along the same pathway. But by moving the Edge servers nearer to consumers we move the point at which thousands of equal streams consume many, many gigabits per second of bandwidth. The incoming point to those servers is only in the several megabits or gigabits per second where the streams are unique – a linear channel at 5 Mbps for example, or a VOD asset like a film. In principle, Edge caching is a “one file in, many files out” model. So, wherever we locate the Edge is where we will have unique files in and many copies of files out. Doing that file proliferation work deeper in a network is a highly significant bandwidth saver for the upstream network. This basic principle is the win-win between broadcaster and ISP of having Edges deployed more deeply inside broadband and mobile networks. By removing traffic from core networks, congestion is removed from large tracks of the video delivery network which reduces the risk of buffering and improves viewer QoE. By deploying Edges more deeply in the network, proximity to the viewer is improved which enables low latency video to be more reliably delivered. By offloading traffic from the ISP core network, valuable network bandwidth is freed up which can be reused for other revenue-generating use cases.

The logic of this design seems clear. So, what could a network look like if we built it out like this?

The Streaming Capacity Blueprint Proposal

Efficiency is possibly the most fundamental requirement for full-scale streaming. Whatever the design, we must be energy efficient. Devices used for consuming content are a major energy consumer in the streaming ecosystem but this set of articles first looks at the network infrastructure from Origin to Edge which must scale dramatically to support future streaming demand.

The Origin

At the Origin end of the delivery chain, the capacity required scales with the content. Content archives, VOD libraries, and encoding/packaging/origination processing are all part of this picture. Content libraries grow all the time as new content is produced. The investment in producing content then requires that content to be stored safely. This requires content to be stored centrally, but in a reasonably distributed manner for resilience. In addition to video files, we have TV channels, once again expanding rapidly due to the FAST phenomenon, that need to be originated 24 hours per day. Both video files and TV channels need their origination points to be centralized but flexible. Gone are the days of building out large, dedicated video storage and channel encoding & origination environments that required significant capex investments. The use of more flexible cloud platforms is increasing for central content storage and origination because these platforms provide more flexibility. A 24-hour TV channel, or a pop-up channel, or a VOD library should easily adapt in terms of size and cost as audiences shift and as content or channel popularity changes. Cloud-based solutions enable this flexibility.

Video storage and caching inside the content delivery network should be as intelligent as possible, to minimize storage workloads. A first distinction to consider is between hot and cold content. Hot content – e.g., very recent catch-up TV or new VOD releases – should take up most of the storage capacity inside the Edge servers. But this does not mean that many Edge servers should all contain copies of the same video file. File replication should be minimized. The goal is for centralized Origin storage environments to be as big as required, but for distributed Edge storage environments to be as small as possible. One way to do this is to only copy a file to a new server when it is most efficient to do so. The definition of “most efficient” should be an accurate measure of combined storage use and network use, using energy consumption optimization as the decision driver. For example, if a file has been stored on one Edge cache because it was requested by a viewer, then that file is now inside the CDN. If a second request arrives for the same file, then it is potentially the right thing to do to stream the file from the cache where it is stored, even if the viewer has another cache closer to them which could store and stream the file. If that VOD file becomes very popular, then it could make more sense to copy it to other Edge locations. The dynamic decision-making about copying files should aim to minimize replicating files, which ultimately consumes storage potentially unnecessarily.

Content is generally replicated multiple times inside different Edge caches, or potentially inside multiple intermediate caching layers that add extra hardware into the content delivery network, for two primary reasons. The first is to minimize network usage between Origin and Edge from repeatedly requesting the same files, and second is because we want to deliver fastest-possible video start-up time. But if we deploy an intra-connected Edge network which minimizes the demand on the main Origin to Edge path for video delivery, and if we can better manage the customer experience so that VOD files that which take longer pathways to reach a viewer can be explained somehow with simple customer service messages (even if we are talking about a few seconds to start a video instead of milliseconds), then we can improve the efficiency of VOD delivery. VOD is the heavy regular user of network bandwidth in the video ecosystem. To manage it very efficiently for full-scale streaming, we need to build file management and file streaming intelligence into the Edge networks.

There is a lot of discussion about using multicast for streaming video delivery at scale. This could make sense for live events and high viewing concurrency, but as described in part 2 of this series implementing and sustaining multicast consistently across multiple diverse networks is not simple, and even if it was implemented multicast switches to unicast for personalized content delivery and for timeshifted TV (e.g., pause, rewind, fast-forward). In the end, multicast would have very narrow use cases to support, which are probably not worth the engineering and management costs required. A simpler premise that could achieve optimal efficiency is to make standard unicast (with its use of standardized internet and streaming standards like HTTPS and HLS/DASH) highly efficient through the deep distribution of the video streaming delivery network.

While Origin technologies will continue to influence how video is streamed efficiently, the next subject we will explore is how the Edge could scale very efficiently with the audience.