Cloud computing typically implies data centers, but network operators—Telcos and MSOs that operate access networks—recognize that the same advantages apply to the network edge, albeit with an edge-specific twist:

• With respect to resource elasticity, being able to deploy network services in virtual machines running on commodity processors instead of deploying purpose-built appliances means reducing the time-to-market for new services and making it easy to re-provision the resources allocated to existing services as demand dictates.

• With respect to the software ecosystem, being able to leverage general-purpose building block services instead of integrating stove-piped applications from a limited set of vendors makes it easier to introduce incremental value-added functionality into the network, and as a consequence, opens the space for innovation by third-party service providers.

• With respect to reducing operating costs, extending the cloud into the access network introduces both a risk and an opportunity. Since network operators are both cloud users (they introduce and operate applications running on the cloud platform) and cloud providers (they own and operate the underlying network/computing infrastructure), the risk is that a proliferation of services will introduce a proliferation of OSS/BSS procedures, but at the same time, there is an opportunity to introduce a unified approach to OSS/BSS across a wide set of services.

In telling this story to different audiences, I’m often asked about the relationship between network services running in virtual machines and Software-Defined Networking (SDN), the former not yet having a catchy name and the latter getting significant traction in the cloud community. The short answer is that they are complementary ideas: the former is essentially about replacing purpose-built network appliances with functionally equivalent services implemented in software and running in VMs, while SDN is primarily about decoupling the network control and data planes, and putting the former under the control of software running in a (logically) central location rather than being hard-coded into individual appliances.

The slightly longer answer is that SDN will likely play a role in managing virtualized network services, much in the same way that SDN is starting to play a role in making cloud services easier to manage. Just as in the data center, VMs running services at the network edge must be interconnected (so they can be composed) and isolated (so they do not interfere with each other), new VMs must be brought on-line, unneeded and failed VMs must be taken off-line, and existing VMs must be re-provisioned. SDN can help operators manage these processes.

But when you move beyond network management, and consider the potential of SDN to catalyze new capabilities, it is important to keep in mind that operator networks are very different from data centers. First, it matters where in the network a VM is instantiated, meaning that VM migration will have different constraints at the edge than in the data center. Second, edge resources are not as abundant as in the data center (meaning that VM provisioning is not as fluid), and the multi-tenancy requirement is not as severe at the edge since the operator will want to select (and qualify) the services that run rather than open its edge resources to arbitrary 3^rd-party applications. Third, many network services are already scalable and robust—i.e., they are self-balancing and self-healing by design—and so will not need to leverage SDN-enabled load balancing and failure recovery support.

On the other hand, there may also be new opportunities for SDN at the edge that are not relevant in the data center. For example, a service that transparently intercepts HTTP requests might use SDN to dynamically configure the network to pass-through (rather than divert) certain flows once the service determines those flows are not of interest.

Popping up to the 10,000-foot level, two approaches seem to be emerging. In one, the cloud and the operator network are treated as two distinct technologies (with the latter still largely constructed from purpose-built network appliances), where SDN  comes into play by moving the network control plane from the individual appliances to software running in the cloud. The other approach goes a step further by extending the cloud into the operator’s network, with virtualized services running in both the data center and at edge sites in the operator’s network. Just as in the first approach, SDN can still be used to simplify management across the resulting center-to-edge cloud, but taking this more expansive approach is essential to fully exploiting the advantages of cloud computing at the edge, which derive from being able to enjoy the cost/performance and elasticity benefits of virtual machines running on commodity processors. (For an analysis of commodity versus not-quite-commodity appliance blades, the interested reader might check out Jim Dolce’s recent blog posting.)

Setting aside the relative strengths and weaknesses of individual proxies, as well as the open source versus commercial product debate—and given the rate of feature requests we see at Verivue, the latter is no small consideration—this is a fair question. In what way is a CDN more than a distributed set of caches?

The obvious answer is that a CDN includes several other components, including request routers that redirect user requests to the best cache and a traffic analytics facility that aggregates, analyzes, archives, and visualizes traffic data generated by individual caches. But there is a more important answer that can be summarized in one word: scalability. The key is to organize and manage a set of caches in a way that scales to form a content delivery service… a CDN. In other words, caches are a key building block, a brick so to speak, but a CDN is a house constructed from a large stack of bricks that have been arranged according to a sound architectural design and engineering practices. Without the correct design, you have a pile of bricks, not a house.

There are two dimensions to scalability. The first and most obvious is performance. If you have 1000 caching nodes that can individually deliver, say, 10Gbps of performance, then a properly designed CDN ought to be able to deliver 10Tbps of aggregate performance across a wide-spectrum of workloads. The key challenge is distributing the workload over the available caches in a way that avoids hotspots that limit aggregate performance. On this point, there is a fundamental balancing act in selecting a cache that is simultaneously (a) close to the end-user, (b) not overloaded, and (c) has a copy of the desired object. In other words, the challenge is to balance network proximity, load balancing, and cache locality in the face of variable request workloads and object popularity distributions.

A superficially designed CDN will easily find itself in one of two sub-optimal situations: either a popular object (movie) is delivered by too few caches while other caches sit idle, reducing the aggregate throughput of the CDN, or an unpopular object is unnecessarily replicated across multiple caches, displacing objects that would make more effective use of the cache. That is, the first situation results from favoring cache locality over a balanced load, while the latter situation results from favoring a balanced load over cache locality. Plus, both options potentially suffer from less-than-perfect information about the current state of the system.

Moreover, striking the right balance is not a matter of having a sufficiently clever algorithm—the underlying problem is NP-complete, that is, there is no known efficient algorithm. Instead, a robust design is a matter of decomposing the problem in just the right way. To see this, consider a critical subset of the larger problem: how to get scalable performance out of a cluster of proxy servers in a single site. One option is to put a load balancer in front of the cluster, but this makes little sense from a cost perspective (the load balancer is a disproportionally expensive element), not to mention that it ignores the role locality plays in cache effectiveness. A second option is to push the problem onto the Request Routing service, but this just moves the problem—it doesn’t solve it. Fortunately, there have been important advances in the design of scalable systems involving the use of consistent hashing to simultaneously distribute load evenly and retain favorable cache locality. The use of such mechanisms is considered an essential best practice in CDN design.

The second dimension of scalability is operational overhead. Although less easy to quantify, it should not be the case that managing 1000 cache nodes is 1000 (or even 100) times the effort needed to manage a single cache node. This means the configuration uploaded to each cache must be automatically generated from a single CDN-wide specification of how the CDN is to behave—how the individual caches are organized into a caching hierarchy, how request routing is mapped onto the caching hierarchy, what restrictions are imposed on when and where content can be delivered, how delivery is to be customized for different end-users, and so on. It is simply not practical to treat each cache as an independent appliance, subject to the inevitable operator errors that will occur when each appliance is managed as a distinct element.

A comprehensive CDN-wide configuration, in turn, depends on a management interface that models the rich set of abstractions and operational workflow of a full-featured CDN. Even though this is a difficult dimension to quantify, people that have built and operated wide-area network services uniformly agree that time spent incorporating a new feature into the configuration management system often dwarfs the time needed to implement the feature itself, but without investing that time, the system quickly becomes unmanageable.

The challenge of building distributed and parallel systems from component parts has always been how to make the system scalable. CDNs are no different.

First, there are few more expensive places to put a cache and its associated storage than in a router slot.  Intense competition has cut profit margins for servers to around 20% (e.g. Dell reported GM of 22% for Fiscal Year ending Feb 3, 2012), while gross margins at router companies run more than 3 times that amount (Juniper and Cisco GM for FYE 2011 were 64.5%  and 61.3% respectively).  Hence, the same collection of Intel processors, memory, disk drives and other components required to build a server will inherently cost you far more when assembled into a router blade versus a Commercial Off-The-Shelf (COTS) server.

In addition, the annual maintenance contract for router equipment can cost 15-20% of the net purchase price every year.  In contrast, HP servers come with a 3 year warranty covering parts, labor and onsite support at no additional charge.  While some might claim these commodity servers don’t provide “carrier grade” reliability, a strong case can be made for continuous availability provided by self healing software running on top of commodity parts (see Larry Peterson’s “Devices vs Services” blog post).

But the problem isn’t limited to initial capital and maintenance costs alone.  Finance departments typically depreciate Telecom equipment, including routers and switches, over a relatively long period—generally seven years or more.  COTS server technology, on the other hand, is depreciated over a 3 year useful life.  The paradox here is that while router blades use the same processor, memory and storage components as COTS servers, they’re somehow expected to operate over a longer lifetime just because they’re slipped into a router slot.  Despite what the accountants say, technology innovation will render that router blade obsolete before it can be fully depreciated.  The operator must then decide whether to continue using an obsolete router blade for 4+ more years, or upgrade to a new version and write-off its remaining life.

The basis for this faster depreciation is simple – rapid advances in processor and storage technology force servers into obsolescence almost immediately.  In the past 24 months, multi-core capacity of x86 CPUs grew from 4 to 12 per CPU, and processor manufacturers have announced plans to exceed 12 cores soon!  Similar innovation is also occurring on the memory side, with DRAM chip density growing from 4GB per DIMM to 8 and 16GB per DIMM and new types of storage technologies, such as solid state drives (SSD), becoming mainstream.  It’s no surprise the IT industry is keen to ride the commodity performance curve.  Why would the Telco industry do otherwise?

There is yet another paradox here that cannot be overlooked.  Proponents of the router blade solution contend that they’re just using “spare” slots, as if these slots are free!  The spare slots of a router are only “free” if you believe you will never again have to increase your IP routing capacity.  How many network operators are planning for no IP traffic growth?  Instead, they are constantly adding capacity in the form of router ports and blades and, yes, entirely new chassis when they eventually run out of those “free” slots.  This means that deploying caching on router blades will consume the very resource that future IP capacity growth depends on—available slots.  Sorry, but that doesn’t seem logical.

This leads us to the related issue of space.  A Juniper MX960 Edge Router requires 16U of rack space while offering up to 12 line card slots.  Assuming at least one slot for Ethernet ports (DPC), an operator can potentially deploy up to 11 caching blades in the MX chassis.  In contrast, 15 rack-optimized servers and an inexpensive 1U Top-of-Rack Ethernet Switch could occupy the same real estate, offering better space utilization at far lower cost.  Not to mention the list price of that MX960 can top $100,000 when equipped with redundancy.

And now the final point.  A cache/CDN strategy that’s based on a switch or router blade is vendor-specific, i.e. Juniper blades will not fit in a Cisco router or vice versa.  Since most network operators deploy router equipment from multiple vendors, the cache router blade approach forces the operator into two discrete CDN architectures.   Two CDNs, each with their own operating procedures, OSS/BSS integration, training requirements, etc, create additional operating overhead and further increases TCO.

A prominent psychology professor, Abraham Maslow, originated the phrase “if all you have is a hammer, everything looks like a nail“.  This concept, known as Maslow’s hammer, is a fitting description for the proprietary router blade approach.  Instead, the new era of cloud computing powered by thousands of low-cost, interconnected commodity servers, provides an alternative paradigm that deserves serious consideration.

This is not to say the WG is making the problem harder than it is—CDNs are a semantically rich service and interconnecting them is bound to be a significant challenge. At a high level, CDNI requires a pair of CDNs—an upstream CDN (uCDN) serving the content provider and a downstream CDN (dCDN) serving the end-user—to exchange two sets of information: The uCDN tells the dCDN its policies for how its content is to be delivered (the IETF calls this the metadata interface) and the dCDN advertises its capabilities to the uCDN (the IETF calls this the request routing interface).

The challenge is how much information to include in these two sets. If the uCDN expects to delegate all enforcement over the delivery of its content to the dCDN, then the first set has to be extensive… e.g., not only the availability window for the content, but also the ability to authorize end-users. Similarly, if the uCDN expects to route requests to several candidate dCDNs, then the second set also has to be extensive… e.g., not only the dCDN’s network footprint, but also its ability to process different types of manifest files for HTTP adaptive streaming. Moreover, this all needs to happen under the assumption that CDN peering agreements result in arbitrary topologies.

When the general problem is hard, one needs to keep an eye open for a simpler scenario that has immediate value, resulting in a classic case of an ambitious effort being overtaken by events. My view is that delivery termination is the near-term scenario that is most likely to beat general-purpose CDN interconnection to the punch, where by delivery termination I mean regional CDNs terminating content delivery on behalf of one or more global CDNs.

Delivery termination has the potential to be is a win-win scenario. Regional operators own both the last mile and the middle mile of the end-to-end path. They are able to put caches significantly closer to end-users than the global players, which are limited (at best) to placing their caches just inside the operator’s Internet peering point. This both reduces the operator’s cost of delivering over-the-top content to their broadband subscribers, and at the same time, improves the end-user experience that global CDNs are able to promise content providers.

Delivery termination is not trivial. It will require more cooperation between the regional and global CDNs than simple transparently caching. At a minimum, the global CDN requires visibility into delivery over the regional CDN for the sake of reporting and monitoring, the regional CDN must respond to purge (delete) requests from the global CDN, the regional CDN will need to coordinate end-user authorization with the global CDN, and the regional CDN will need to produce transaction logs for the purpose of billing. But the list of requirements is bounded and manageable, the peering topology is simple, and the value proposition provides a clear mandate for making design decisions.

Delivery termination does not come without risks to the global CDNs, but the bigger risk is that regional CDNs will federate with each other in an effort to reach more eyeballs, and then take that proposition to content providers. As the IETF effort reminds us, enabling the general-purpose interconnection that full federation requires is a significantly higher bar than delivery termination, and by embracing delivery termination, global CDNs may just take enough wind out of the sails of ubiquitous CDN federation to delay it for years.

Transparent caching is often viewed as something distinct from an Operator CDN—it is used to cache over-the-top (OTT) content from content providers and aggregators with which the network operator does not have an explicit delivery arrangement. But a better model is to view transparent caching as one use (application) of a CDN, no different than other uses (e.g., multi-screen video delivery, multi-tenant CDN for B2B customers, CDN-assisted VoD). In each case, the application leverages a core caching service, plus one or more auxiliary mechanisms. In the case of transparent caching, the delta is an alternative content acquisition mechanism—one that transparently intercepts requests rather than explicitly redirecting requests for pre-registered content. Or said another way, transparent request interception is a means rather than an end.

A general-purpose transparent request interceptor does three things. First, it interacts with the surrounding network infrastructure to divert candidate requests to the interceptor. This can be accomplished through proper configuration of some standard protocol—e.g., DNS, BGP, PBR, WCCP—at the operator’s discretion. Second, for diverted requests for cacheable content, the interception service redirects the end-user to the caching service, which in turn acquires the content from the origin server if it is not currently cached. Third, for diverted requests for non-cacheable content, the interception service either proxies the corresponding flow to the origin server or re-configures the network to forward the flow rather than divert it. The better job a transparent request interceptor does at diverting only cacheable content at step one, the fewer “false positives” need to be proxied at step three.

Note that the only difference between transparent caching and the other example CDN applications is that for the latter, step one involves the content provider explicitly diverting user requests to the request router using a CNAME or by making the request router an authoritative DNS server for some region of its URI name space. This, in turn, means there are no false positives, so step three is not required. As for step two, both transparent caching and all the other CDN applications leverage exactly the same request routing service and caching service.

In other words, we can think of these various CDN applications as being constructed from building block services:

• Transparent Caching = Cache + Interceptor + Request Router + Analytics
• Multi-Screen Video = Cache + Request Router + Analytics
• Multi-Tenant Operator CDN = Cache + Request Router + Analytics
• CDN-Assisted VoD = Asset Manager + Streamer + Cache + Request Router + Analytics

where each component is a general-purpose, stand-alone service. The power of this building block approach is that the next application that comes along can either be constructed from a different configuration of existing services, or requires only an incremental addition to the current service catalogue. This both reduces the time-to-market for new applications, and increases the operator’s ability to leverage (and possibly re-purpose) its existing investment.

Of course, this is easier said than done. One key enabler is to run on a virtualized platform, which simplifies the process of provisioning services on the underlying hardware infrastructure. This is the central insight of cloud computing, except applied to the network edge instead of the data center. A second key enabler is an extensible management framework that unifies how operators control and monitor the available services. Having to deal with one-off OSS/BSS processes is an unacceptable burden. The third key enabler is truly general-purpose building block services that work across a wide-range of usage scenarios. In contrast, purpose-built mechanisms generally result in stovepipes solutions that cannot be reused.

In trying to put my finger on whether there’s something fundamentally different in how these two communities build and operate systems, I keep coming back to the following distinction. Network operators think in terms of appliances and devices, and how they can be architected to build a network, whereas the IT perspective decouples hardware and software (treating the former as commodity), and focuses on how the software can be architected to provide a global service. This device/appliance versus software/service distinction then permeates the language: one talks about managing individual devices and the other talks about managing the service as a whole; one talks about appliance performance and the other talks about aggregate service performance; one talks about device reliability and the other talks about service-level reliability. Of course the network operator also thinks about network-wide behavior and IT people also think about per-server behavior, but their respective viewpoints start at opposite ends from each other.

So does it matter, or is it a distinction without a difference? Here’s where I think it matters. If you are focused on appliances or devices, then you would naturally equate the appliance with the highest performance and highest reliability rating with the best-of-breed. On the flip side, if you are focused on service-wide behavior, then you equate best-of-breed with the software approach that scales to the best aggregate performance and offers the best service-level reliability, independent of how fast/reliable each individual server is. In fact, the more a software service is able to extract good performance and reliability out of slow/unreliable servers, the better.

To see how this plays out in practice, consider the following simple scenario. Suppose you need to support 10Gbps of customer-facing content delivery bandwidth, and you have the option of either a single 10Gbps appliance or a cluster of four commodity servers running clustering software that delivers 10Gbps in aggregate. Which is the better choice? (To simplify the story, assume the same underlying processor is used in both options, and that the software throttles each box to 2.5Gbps in the latter case.) From a cost/performance perspective, both options offer the same performance, but the latter incurs a modest incremental cost for the extra hardware, and the corresponding rack space. However, the cluster-based solution offers two distinct advantages: (1) it is easier to incrementally increase the aggregate capacity since opening up a bandwidth throttle is easier than installing another appliance, and (2) a node failure results in a loss of 1/N^th the aggregate capacity rather than taking down the whole site (and to avoid the latter, many operators adopt a 1+1 redundancy strategy whereby they install two 10Gbps appliances, making the total cost of ownership substantially higher).

Note that these advantages are amplified if the software is deployed on virtual machines rather than physical machines, as would be the case if the operator’s underlying infrastructure were cloud-based. Running on such a platform means faster provisioning and re-provisioning as workloads change, quicker time-to-market for new software services, and greater capacity to absorb the failure of individual hardware devices.

The caching hierarchies offered by CDNs are widely understood to work well for video-on-demand applications, but not necessarily for linear applications, such as emerging “TV Everywhere” offerings. That situation is changing. The key technical advance is low-latency cut-through proxy support, so that the delay pulling content through a caching node is significantly lower than a typical store-and-forward proxy. In the case of caching, this delay is essentially the ingest latency—how long it takes to ingest content from upstream so that it is available to serve downstream. Low-latency cut-through is not only possible (we have demonstrated sub-10ms latencies with the Verivue HyperCache), but also a reality in Verivue deployed CDN solutions for live delivery using HTTP adaptive streaming.

There are several keys to achieving such performance. The first is obvious, but bears mentioning because so many CDNs running today are based on caches that were originally web servers rather than reverse proxies: don’t store the ingested content to disk before delivering it to the downstream users. A Store-to-Disk-and-Forward approach is a non-starter. The second is to begin delivering bytes downstream before the entire object is received into the node. This must happen at the granularity of packets rather than whole objects. Third, a viable approach to low-latency cut-through proxy has to efficiently support many concurrent user requests waiting for the object to be delivered from an upstream cache. Serializing requests introduces unacceptable latency into the cut-through mechanism and is particularly problematic in the delivery of live content where clients are naturally synchronized to request the same content objects.

A caching hierarchy that is as efficient delivering live content as a multicast tree gives operators a powerful new tool. Operators can deliver both live and VoD content on the same caching substrate, and as a bonus, the live content isn’t limited to being strictly live. Because content is cached throughout the hierarchy, it is readily available for time-shifting (e.g., catch-up TV). In other words, the distinction between live, live-with-catch-up and VoD is blurred. (The distinction is blurred at the CDN level, independent of whether the service provider continues to offer multiple services to customers.) Moreover, at the live end of the spectrum, the latency is so low that concurrent cut-through makes Internet-based CDNs a viable option for even the “first screen” (the home television), which has fast-channel-change expectations.

That a single technology can seamlessly serve such a range of requirements is an important technical breakthrough, but the frosting on the cake is that it does so without introducing additional complexity, but rather, by using a simpler mechanism. Instead of the complexity of multicast tree maintenance—managing user joins and departures across the set of multicast channels carrying different bit-rate streams—the entire flow of content (at different bit-rates) comes for free as end-users issue HTTP GET requests for the content they want to see. Content is pulled down the caching hierarchy, on-demand, in response to those requests. From an operational perspective, the choice between multicast tree maintenance and leveraging the RESTful HTTP protocol is an easy one.

 Hence, it’s no surprise that the combination of operator CDN technology and transparent caching has received particular attention lately.  For example, EdgeCast and PeerApp teamed up in September to combine EdgeCast’s licensed CDN software with PeerApp’s transparent caching platform.  Alcatel-Lucent and Blue Coat Systems also consummated a global reseller agreement to jointly market their respective CDN and transparent caching platforms to network operators.

 The goal in both these cases was a worthy one, i.e., to let operators cache all content – managed and unmanaged – that is carried across their networks.  Unfortunately, both approaches are based on discrete platforms, leaving network operators with higher capital expenses while fending for themselves in areas such as operations, management and reporting integration.

 This week, however, Verivue addressed this integration dilemma with the first and only solution that offers both carrier CDN and transparent caching in a single, unified platform.  The true integration of these two functions helps streamline network operations while reducing deployment cost.  Now intelligent caches deployed strategically throughout the CDN network can serve dual-purpose as a transparent cache, reducing the network infrastructure and bandwidth costs associated with ‘over the top’ (OTT) content.

 By adding transparent caching as a software feature atop the OneVantage Content Delivery Solution rather than as discrete infrastructure, Verivue addresses both managed and unmanaged content across a single set of devices.  Best of all, the entire platform is software-based, harnessing the advantages of industry-standard server and storage components while providing a more flexible alternative to proprietary server appliances offered by many of our competitors.

With online video showing no sign of slowing down, operators continue to seek innovative ways to optimize revenue while reducing cost.  Verivue’s holistic approach to content delivery solves both problems together, allowing operators to develop a comprehensive content distribution strategy rather than an assortment of costly, discrete solutions.

The first is technology-focused. Commodity processors that can be virtualized to simultaneously run multiple services will inevitably find their way deeper and deeper into the network. The case for riding the cost/performance curve of general-purpose commodity processors is well understood. What virtualization brings to the network is the ability to safely co-locate multiple services on the same hardware – each running in a different virtual machine – thereby giving operators the ability to dynamically activate new services and re-allocate resources among existing services as demand dictates. Time-to-market for new services is dramatically lowered, and costs are reduced through more efficient resource usage.

The second storyline is network-focused. At the same time traffic demands are driving traditional data center services like CDNs towards the edge of the network, traditional network-level services already running at the edge can also benefit from virtualized commodity processors. This seems particularly relevant to AccessNet-to-Internet junction points (e.g., PDN-GW, B-RAS, and CMTS), where the opportunity to manage and customize subscriber sessions seems almost limitless – mobility, security, quality-of-service…

Considering all three storylines as a whole – application-level services to the edge, virtualized commodity processors to the edge, and customizable session management at the edge – it is easy to see the possibility of a perfect storm that changes the foundation of how network services are delivered. There are, however, three keys challenges that must be addressed.

The first is tuning virtualization technology (both software and hardware) to support both application-level services and network-level services on the same platform. It’s not clear that virtualization techniques optimized for compute-heavy applications can be applied directly to I/O-centric environments. The second is providing a service management system that gives operators a coherent way to activate and configure a wide range of application-level and network-level services. Avoiding management silos will be necessary to keep operational costs in check. The third, and most interesting, is to leverage the opportunity to integrate application-level functionality with network-level functionality to create new value in the network. This is a fertile space for innovation.

For example, Google’s answer to the traffic and congestion problems created by Google and YouTube content is to offer operators the option of deploying Google Global Cache (GGC).  GGC is a cluster of Google provided servers installed inside an operator’s network to improve performance by caching popular content locally.  Serving content from the edge of an operator’s network eases backbone congestion and relieves traffic on peering and transit links, saving cost and improving QoE.

On the surface, this concept appears to be a win-win for both Google and the network operator.  But is it really good for operators?  With GGC, Google is put in an exceedingly advantaged position relative to other content providers.  As online streaming becomes ubiquitous and the competition heats up, Netflix and other well financed companies like Apple, Microsoft, Amazon and Dish/Blockbuster may demand this same advantage.  For most operators, physical space for cabinets and cages, conditioned power (including battery backup and power generators) and adequate cooling are in scarce supply.  Hence, it may be impractical to provide a similar arrangement to a broad set of content providers, even as regulators require network operators to treat everyone equally.

To address this dilemma, operators are opting to offer multi-tenant CDN services.  Because they own the access infrastructure, they are able to strategically locate their own caching servers deep in the network, bypassing most network congestion points.  This close proximity to the user base allows them to deliver rich-media content with the lowest latency for a superior QoE.

More importantly, the multi-tenant model allows operator’s to deliver content on behalf of all parties across a single, unified infrastructure rather than deploying individual, physical caches for each content provider.   Instead of becoming real estate agents, networks operators look more like building managers collecting rent in the form of new, revenue-generating services.

For operators that offer their own content, such as Cable MSOs and Telco/IPTV Service Providers, the multi-tenant CDN provides a service delivery platform whose cost can be spread across multiple customers, including the content delivery offerings of the service provider. Economies of scale dictate this shared resource model. After all, the whole idea with cloud services is to share compute cycles and storage among multiple tenants. Why should it be any different at the customer-facing edge of the network when it comes to content caching and delivery?

It is abundantly evident from the many conversations we have with major operators that the time has come for the multi-tenant CDN model.  It’s no longer “every man for himself”, but instead, a new paradigm where content providers “ride the coattails” of network operator deployed content caching and delivery infrastructure.