Content delivery network

Several protocol suites are designed to provide access to a wide variety of content services distributed throughout a content network. The Internet Content Adaptation Protocol (ICAP) was developed in the late 1990s[14][15] to provide an open standard for connecting application servers. A more recently defined and robust solution is provided by the Open Pluggable Edge Services (OPES) protocol.[16] This architecture defines OPES service applications that can reside on the OPES processor itself or be executed remotely on a Callout Server. Edge Side Includes or ESI is a small markup language for edge level dynamic web content assembly. It is fairly common for websites to have generated content. It could be because of changing content like catalogs or forums, or because of the personalization. This creates a problem for caching systems. To overcome this problem, a group of companies created ESI.

In peer-to-peer (P2P) content-delivery networks, clients provide resources as well as use them. This means that unlike client-server systems, the content centric networks can actually perform better as more users begin to access the content (especially with protocols such as Bittorrent that require users to share). This property is one of the major advantages of using P2P networks because it makes the setup and running costs very small for the original content distributor.[17][18]

If content owners are not satisfied with the options or costs of a commercial CDN service, they can create their own CDN. This is called a private CDN. A private CDN consists of PoPs (points of presence) that are only serving content for their owner. These PoPs can be caching servers,[19] reverse proxies or application delivery controllers.[20] It can be as simple as two caching servers,[19] or large enough to serve petabytes of content.[21]

Large content distribution networks may even build and set up their own private network to distribute copies of content across cache locations.[22][23] Such private networks are usually used in conjunction with public networks as a backup option in case the capacity of private network is not enough or there is a failure which leads to capacity reduction. Since the same content has to be distributed across many locations, a variety of multicasting techniques may be used to reduce bandwidth consumption. Over private networks, it has also been proposed to select multicast trees according to network load conditions to more efficiently utilize available network capacity.[24][25]

The rapid growth of streaming video traffic[26] uses large capital expenditures by broadband providers[27] in order to meet this demand and to retain subscribers by delivering a sufficiently good quality of experience.

To address this, telecommunications service providers (TSPs) have begun to launch their own content delivery networks as a means to lessen the demands on the network backbone and to reduce infrastructure investments.

Because they own the networks over which video content is transmitted, telco CDNs have advantages over traditional CDNs.

They own the last mile and can deliver content closer to the end-user because it can be cached deep in their networks. This deep caching minimizes the distance that video data travels over the general Internet and delivers it more quickly and reliably.

Telco CDNs also have a built-in cost advantage since traditional CDNs must lease bandwidth from them and build the operator's margin into their own cost model.

In addition, by operating their own content delivery infrastructure, telco operators have better control over the utilization of their resources. Content management operations performed by CDNs are usually applied without (or with very limited) information about the network (e.g., topology, utilization etc.) of the telco-operators with which they interact or have business relationships. These pose a number of challenges for the telco-operators which have a limited sphere of actions in face of the impact of these operations on the utilization of their resources.

In contrast, the deployment of telco-CDNs allow operators to implement their own content management operations,[28][29] which enables them to have better control over the utilization of their resources and, as such, provide better quality of service and experience to their end users.

In June 2011, StreamingMedia.com reported that a group of TSPs had founded an Operator Carrier Exchange (OCX)[30] to interconnect their networks and compete more directly against large traditional CDNs like Akamai and Limelight Networks, which have extensive PoPs worldwide. This way, telcos are building a Federated CDN offering, which is more interesting for a content provider willing to deliver its content to the aggregated audience of this federation.

It is likely that in a near future, other telco CDN federations will be created. They will grow by enrollment of new telcos joining the federation and bringing network presence and their Internet subscriber bases to the existing ones.

The latency (RTT) experienced by clients with non-local resolvers ("high") reduced drastically when a CDN rolled-out the EDNS0 extension in April 2014, while the latency of clients with local resolvers are unimpacted by the change ("low").[31]

Traditionally, CDNs have used the IP of the client's recursive DNS resolver to geo-locate the client. While this is a sound approach in many situations, this leads to poor client performance if the client uses a non-local recursive DNS resolver that is far away. For instance, a CDN may route requests from a client in India to its edge server in Singapore, if that client uses a public DNS resolver in Singapore, causing poor performance for that client. Indeed, a recent study[31] showed that in many countries where public DNS resolvers are in popular use, the median distance between the clients and their recursive DNS resolvers can be as high as a thousand miles. In August 2011, a global consortium of leading Internet service providers led by Google announced their official implementation of the edns-client-subnet IETF Internet-Draft,[32] which is intended to accurately localize DNS resolution responses. The initiative involves a limited number of leading DNS service providers, such as Google Public DNS,[33] and CDN service providers as well. With the edns-client-subnet EDNS0 option, CDNs can now utilize the IP address of the requesting client's subnet when resolving DNS requests. This approach, called end-user mapping,[31] has been adopted by CDNs and it has been shown to drastically reduce the round-trip latencies and improve performance for clients who use public DNS or other non-local resolvers. However, the use of EDNS0 also has drawbacks as it decreases the effectiveness of caching resolutions at the recursive resolvers,[31] increases the total DNS resolution traffic,[31] and raises a privacy concern of exposing the client's subnet.

Virtualization technologies are being used to deploy virtual CDNs (vCDNs) with the goal to reduce content provider costs, and at same time, increase elasticity and decrease service delay. With vCDNs, it is possible to avoid traditional CDN limitations, such as performance, reliability and availability since virtual caches are deployed dynamically (as virtual machines or containers) in physical servers distributed across the provider geographical coverage. As the virtual cache placement is based on both the content type and server or end-user geographic location, the vCDNs have a significant impact on service delivery and network congestion.[34][35][36][37]

In 2017 Addy Osmany of Google started referring to software solutions that could integrate naturally with the Responsive Web Design paradigm (with particular reference to the <picture> element) as Image CDNs.[38] The expression referred to the ability for a web architecture to serve multiple versions of the same image through HTTP, depending on the properties of the browser requesting it, as determined by either the browser or the server-side logic. The purpose of Image CDNs was, in Google's vision, to serve high-quality images (or, better, images perceived as high-quality by the human eye) while preserving download speed, thus contributing to a great User experience (UX).

Arguably, the Image CDN term was originally a misnomer, as neither Cloudinary nor Imgix (the examples quoted by Google in the 2017 guide by Addy Osmany[38]) were, at the time, a CDN in the classical sense of the term. Shortly afterwards, though, several companies offered solutions that allowed developers to serve different versions of their graphical assets according to several strategies. Many of these solutions were built on top of traditional CDNs, such as Akamai, CloudFront, Fastly, Verizon Digital Media Services and Cloudflare. At the same time, other solutions that already provided an image multi-serving service joined the Image CDN definition by either offering CDN functionality natively (ImageEngine)[39] or integrating with one of the existing CDNs (Cloudinary/Akamai, Imgix/Fastly).

While providing a universally agreed-on definition of what an Image CDN is may not be possible, generally speaking, an Image CDN supports the following three components:[40]

• A Content Delivery Network (CDN) for fast serving of images.
• Image manipulation and optimization, either on-the-fly though URL directives, in batch mode (through manual upload of images) or fully-automatic (or a combination of these).
• Device Detection (also known as Device Intelligence), i.e. the ability to determine the properties of the requesting browser and/or device through analysis of the User-Agent string, HTTP Accept headers, Client-Hints or JavaScript.[40]

The following table summarizes the current situation with the main software CDNs in this space:[41]

• Netflix[50]