2013-10-05 09:00:00 | CDN Federation
About Federation, 3rd party CDNs integration
During CDN World Summit, Jet-Stream founder Stef van der Ziel discussed CDN federation in his Keynote speech. This topic was also one of the CDN Academy courses presented during the event.
Stef wrote the article below, further detailing the insights. Download the slides here! (PDF 1.3MB)
(slide 4) Intro
CDN operators are interested in the ability to offload traffic into regions beyond their footprint and to become an offload for other CDNs as well. You can draw similarities with international phone calling or with internet interconnection between networks.
CDN Federation is a widely (mis)used term for various ways to extend the footprint of CDNs. The following slides will detail most common scenarios and discuss their pros and cons. I have not described transit/peering agreements since this is so common.
(slide 5) deploy physical edge nodes or PoPs
Extending is not Federation. Traditional CDNs deploy physical edge nodes or PoPs at hosting sites, exchange points or within ISP networks. Imagine the costs of purchasing storage, proprietary (vendor) appliances and switches. Imagine the costs of scouting and negotiating housing and connectivity and SLAs. Imagine the costs of deploying on many sites. Imagine the costs of arranging access, remote hands. CAPEX and OPEX through the roof, without the guarantee of ROI with traffic volumes for these sites. This is the reason why traditional CDNs have high running costs, low efficiency and problems with profitability. More and more ISPs are kicking internet CDNs out of their network because CDNs don't want to pay a fair price to be able to keep investing in the growing demand for capacity.
(slide 6) deploy software edge nodes or PoPs on commoditized cloud infrastructures
Extending to clouds is not Federation however renders interconnection / federation unnecessary if executed right. More modern CDNs eliminate the need for specific hardware and run a full software stack of technologies. Jet-Stream pioneered software only CDNs and holds a lot of IPR around this subject. The appliance is dead. Existing cloud operators have already invested heavily in commoditized cloud infrastructures, so for software CDNs it is a matter of renting virtual machines from hosting and cloud providers all over the world, deploy their software edges and extend their footprint globally without any CAPEX and very low OPEX, pay as you grow.
Telecom operators are joining forces for Network Function Virtualization. This effort will enable telecom operators to extremely reduce costs and speed up deployments by virtualizing their entire infrastructure using standardized cloud based commodity infrastructures. They will no longer accept appliances. These cloud infastructures also allow software CDN operators to deploy edge nodes deep into telecom operator networks. There is no more need for complex CDN interoperability standards since any CDN operator can extend into any remote footprint on a much simpler, much cheaper level while maintaining a high level of features through their proprietary or open software edges.
(slide 7) CDN overlay
Overlaying is not Federation. Overlaying multiple CDNs became popular with content providers, looking for lower costs and better performance. Overlay service providers and technology vendors offer a thin load balancing layer that monitors the performance of commoditized CDNs and load balance to the cheapest and lowest cost CDN based upon a limited set of business logic.
However, the prizes of commoditized CDNs have commoditized as well, so there hardly is a price benefit anymore. Actually it can be cheaper to commit the entire volume to a single CDN to get an even better price benefit.
CDN overlay typically rely on quite passive technologies and is not integrated with underlying CDNs. Therefore it is limiting functionality to the lowest common denominator of already feature-poor commoditized CDNs.
A CDN operator could use CDN overlay to achieve footprint extension by adding an overlay service (or technology) on top of their own CDN and then offload off-net traffic into one or multiple 3rd party CDNs. However this is not a holistic, integrated approach.
CDN overlay is also complicated since there is no integration with or between CDNs. You have to integrate with each CDN separately. You have to negotiate with each CDN separately. You also have to negotiate and integrate with the overlay service (or technology) provider. So this brings a lot of costs, headaches and requires a lot of time.
Another downside is that CDN overlay services (or technology vendors) typically require all content providers to add performance monitoring code to their web pages or video clients, which is extremely hard to require from a CDN operator perspective since you are in a value chain with resellers, content providers and portal providers and hardware video player vendors which makes it impossible to enforce running code everywhere.
(slide 8) closed vendor CDN federation
Some internet CDN operators try to further reduce their delivery costs by trying to license their CDNs at low rates to telecom operators, asking free housing, network capacity and access to the market in return. These operators offer federation of traffic back into their CDN and claiming you can get federated traffic into your CDN, actually calling it open but it is very closed. This entire model is a very dangerous model for telecom operators. It is a trojan horse. CDN operators should always pay for housing and bandwidth. All these telecom operators get is a commoditized CDN that is not optimized for retail services and offers no USPs compared to competitive wholesale CDN services. What actually happens is that the CDN operator not only gets a free ride into the network, but also gets access to the telecom operators customers and directly signs up these customers on their service, bypassing and undercutting the telecom operators prices. What is in it for the operator when you as an operator have to invest in infrastructure, lock-in CDN licensing and lose customers and revenues to the CDN operator? The federated model only works within the proprietary CDN network, so you are locked in and locked out.
(slide 9) CDN interconnection / federation standards
Jet-Stream, pioneering federation, is a strong supporter of standards and has been involved in ETSI and IETF efforts to standardize interconnectivity between CDNs. In a utopian world, all CDNs support common open and free standards to interconnect, and the standards support all advanced features between CDNs. However, realistically we can only conclude that CDN interconnection efforts so far have not procuded any real-world implementations -let alone operational usage- after many years. Running pilots only show that the lowest possible common denominator has been standardized. The costs for CDN vendors and CDN operators to implement these standards can rise very high. Everyone has to rewrite large portions of their code and redesign their architectures. In addition, the pace of the industry is killing. New technologies and business opportunities emerge every few months, and standards will simply keep lagging for years. The business case for CDN federation has already been calculated to be weak, and the need for CDN interconnection has been undercut by the availability of software CDNs that can be extended in hours to cloud and virtual footprints all over the world very fast at low costs and with the full feature stack of your own CDN. Another serious threat is that vendors are trying to get specific innovations into standards, locking the standards into proprietary and expensive (and already outdated) patented technologies. We need a faster, more flexible, more open, more pragmatic approach.
Continue to read this article on "Open Play the background"