2013-10-05 13:30:00 | CDN Federation Technology

Open Play - the background

During CDN World Summit, Jet-Stream founder Stef van der Ziel introduced Open Play CDN federation in his Keynote speech. This topic was also one of the CDN Academy courses presented during the event.

(Important: read the article About Federation first) and download the slides here (PDF 1.3MB). This article by Stef describes the background of how Jet-Stream conceptualized, materialized and developed full CDN integration:

CDN interconnection has been on our agenda for many years. We built the first federated CDN in 2000 and had taken part of many discussions in the early years of CDN around the concept of federation on all levels: business, strategy, technology, standardization, business logic. However CDN interconnection is one of the hardest problems to solve. It is so complex, because you need to oversee and consider the entire spectrum of the CDN space. The pitfalls are easy, you can completely lose yourself in theoretical business models and scenarios which will never materialize, but you can also very quickly develop a blinding focus on too narrow scenarios. You can completely lose yourselves in feature hell for years, but you can also make too easy architecture decisions that will have dramatic impact in the future, rendering a solution useless when the industry evolves. The CDN interconnection feature was put on our roadmap many years ago but we felt the ideas were not materialized enough to start development. Sometimes it just takes time to execute things right. 

We knew that a locked in Jet-Stream-to-Jet-Stream solution would be a lock-in and unacceptable for the industry. We knew that it would take too much time for standards to become usable and that standards would be limiting us and our customers. We knew that developing a separate translation layer between CDNs was not a good option, too many elements. We also knew that overlaying was too simple, we needed actual integration with CDNs. We knew that a solution should be usable both as an upstream and a downstream CDN.

We also knew that we wanted to treat other CDNs as a logical server node, just as if it was an actual edge server or edge PoP. That was an important decision. Which we actually could do, since we had designed our architecture quite abstracted. We had done quite some core innovations before which helped us implement a true holistic CDN integration environment. Many prior Jet-Stream inventions helped us to implement a true holistic integrated multi-CDN solution:

  • Software only CDN invention: delivery and management in software enables the ability to run on top of commoditized servers: physical, virtual, cloud, and any mix of these
  • Parallelization invention: the ability to support and run multiple applications in parallel on a single node to prevent performance and stability issues when stacking of virtualization on top of virtualization
  • Separation of the data plane and the control plane invention (which is now coined as Software Defined Networking)
  • Reduction of complexity in the data plane (dumb boxes) and an intelligent control plane (active core CDN management system)
  • Abstraction of delivery technologies through APIs invention: the ability to integrate with various delivery technologies on the delivery plane, enabling a homogenous management plane and simplified communication between abstracted layers
  • Intelligent management plane invention, enabling instant intelligence about status and functionality within the underlying data plane
  • Software assigned delivery node roles invention: intake(origin), core, overflow, edge roles
  • Tiered distribution and delivery layers invention: the ability to dynamically send users to multiple layers inside the CDN
  • Active request routing invention: the ability to dynamically send users to delivery nodes per individual request instead of passive low-granular DNS or basic request routing
  • Request analysis invention: active analysis of requests using multiple internal and external parameters to select the most optimal delivery node and layer per individual request
  • Business logic invention: the ability to set dynamic rules and receive external information to optimize the selection of the most optimal delivery node per object request
  • Dynamic caching management invention: the ability to rewrite requests dynamically to support multiple origin services enables easy integration with simplified data planes

Before we started implementing the additional required technologies, I started to analyze business scenarios. Jet-Stream is not a regular vendor that innovates technology, we always start from strategic and business analysis and then R&D technologies that can be optimally used to support these business opportunities. This process took a long time. I've always known we were thinking in the right direction but the ideas were not clear enough to start development.

The ideas materialized beginning this year. Our own StreamZilla CDN service was only focussing on Europe: our customers typically have a European audience and our performance to the US was ok. However a number of customers asked for improved performance in the USA. So we looked at our options:

  1. Deploy a physical edge node. Too expensive for the volumes required
  2. Rent virtual machines through an online hosting provider with US presence. Low cost, fast deployment, pay as you grow.
  3. Offload into Amazon Cloudfront. Low cost, fast deployment, pay as you grow. Required simple integration.
  4. Offload into generic CDNs. Low cost, fast deployment, pay as you grow. Required medium integration.

We decided to kill option one, go for option two in the short term and investigate options 3 and 4 as well. We litterally ordered and paid for the virtual machines through an online store, got access within four hours and two hours later the edges were configured, tested and added to our pool of resources. That is the power of cloud. That is the power of software CDNs.

At around the same time we had meetings with various telecom operators who were sharing their ideas about Network Function Virtualization, and that fully aligned with our ideas to run CDNs on clouds. Jet-Stream demonstrated the ability to run both the control and data planes fully on Amazon years ago. After some technical and business sessions both Jet-Stream and the operators concluded that the need for the complex, expensive and limiting CDN federation standards was rendered useless by the ease of use of commoditized cloud infrastructures. The appliance is dead, CDN federation unnecessary and software CDNs were the future. A future Jet-Stream invented over ten years ago :)

When we started to investigate the capabilities of other CDNs for integration purposes it was actually the first time we encountered the features and APIs of other CDNs. And we had mixed feelings. On one side it was a shock to see how poor the feature set of regular CDNs typically is. You can set some parameters like C-naming and TTL and hopefully you can get some logs out of these systems, but that is about it. If you compare that to our advanced media workflow management environment and rich APIs it's really a shocker. On the other hand we managed to make integrated offloading work with a number of CDNs in a few days time, with some hacks in an isolated development environment: our management system didn't know any better than that it was talking to a physical edge node, while in reality it was an account on a third party CDN. And live streams flowed through. Score!

So we reached out to a number of CDNs and asked them to implement some additional features, or to explain why basic features such as anti-deep-linking token management didn't work according to their documentation, or to ask adjustments to logs, et cetera.

It was interesting to hear that these CDNs were very open to cooperate. We had always seen other CDNs as competition for StreamZilla. However, we started to see other CDNs as commoditized infrastructures which we could use to offload (overflow) to. And they were happy to become a resource supplier they have overcapacity, need volume and liked us adding unique value to their systems.

It also aligned with my vision with StreamZilla: do not invest in commodities, invest in innovation instead. Regular CDNs invest millions in PoPs, operational staff, sales staff. StreamZilla's strategy has always been to outsource commodities and automate everything via software to reduce costs.

And that was where all ideas came together: the ability to really integrate multiple CDNs in a rich CDN management system. Suddenly we could support a whole range of new business options. One of the benefits of running your own CDN is that you pragmatically encounter content owner requests and operational challenges on a daily basis which you immediately can translate into innovations. Not that many vendors who can do that.

The actual development of integrated 3rd party CDN support in our technology took less than three months to implement, including the framework, the enhancements of existing technologies and basic support of a limited number of CDNs:

  • Upgrade of our multi-granular topo/geo system to support multiple granularities (for instance countries and ISPs) at the same time, so we can prioritize small edge nodes within ISP networks over edge definded CDNs that define a larger area (like a country)
  • Rewriting of our caching back-end system to be able to dynamically rewrite inbound requests from 3rd party CDNs to be able to dynamically send their requests to the right origins and the right services (multiple web and caching services) within the Jet-Stream CDN
  • Upgrade from three distribution tiers to four (from intake->core->overflow/edge to intake->core->overflow->edge/3rdpartyCDN
  • Upgrade from three request routing tiers to four (from core->overflow->edge to core->overflow->3rdpartyCDN->edge
  • Added the ability to define accounts on third party CDNs as delivery nodes within the Jet-Stream CDN management system
  • Added support for tokenized access control to third party CDNs to prevent anti-deep-linking
  • Added support for 3rd party access log processing
  • Minor enhancements

We found out that the access logs and the access management tokens were the hardest nut to crack, and they still are with several CDNs. Many CDNs have quite exotic and limited implementations which in some cases makes access control and log processing impossible. We also encountered CDNs who claim to support HTTP adaptive streaming but in reality they have quite some caching issues and also struggle with the Thundering Herd problem for HTTP live streaming. But in general my (amazing!) development team was able to make basic integration and basic functionality work with some CDNs and got things working. Compared to having to implement proposed CDN interconnectivity implementation was a breeze on Jet-Stream side an almost nonexistent on the third party CDNs sides while Jet-Stream can offer much higher standards in terms of features, flexibility and performance.

The most important is that the core foundation for integrated third party CDN support as overflow or edge nodes within the Jet-Stream CDN is fully implemented. No additional screens, no separate tools. Between our list of delivery nodes you will find third party CDNs. Just as if they were always there.

This means that it is now relatively simple to add support for new CDNs and also simple to enhance the feature set with pre-integrated CDNs. And it is very easy to keep adding additional business logic to further optimize costs and performance, and offer more USPs compared to relatively simple overlay systems. Oh and we don't force anyone to run code within clients. CDNs cannot enforce this, remember?

(slides 10 and 11) In less than three months time, our system had become a meta-CDN management system, that allows you to mix all kinds of resources within one CDN: mix physical servers, virtual servers, cloud based servers and 3rd party CDNs as if they are logical building blocks. All our existing logic applies to all delivery nodes. It is not a bolted-on feature. 

All premium features apply, and the CDN management system is intelligent so it knows which services and features are and are not supported per logical delivery resource. It automatically geo load balances requests dynamically over any mix of nodes, including 3rd party CDNs, based upon business logic, popularity, performance and many other static and dynamic values. 

(slides 13 and the rest) Some interesting new business scenarios thanks to Open Play:

  • Load balance requests on-net and off-net to internal and external resources right within one integrated CDN management environment, without the need for separate overlay services or technologies. Operators can offer global capacity to their content provider customers and extremely optimize costs by keeping traffic on-net and sending traffic off-net using smart business rules.
  • Build a massive virtual CDN: host our software on 2-8 cloud servers, use multiple CDNs (pay as you grow) for delivery. No CAPEX, no OPEX. (Let us) deploy (and host and manage) your own competitive feature-rich CDN in weeks at the lowest possible investments.
  • Content providers: load balance over multiple CDNs without the need for negotiating contracts and integrating APIs with multiple CDNs and also with an additional overlay service provider. Just one contract partner with a much richer feature stack compared to simple overlay systems. 
  • Become a broker: sell traffic volumes to content providers, then purchase volumes from the best/cheapest CDN
  • Start a marketplace: sell traffic volumes to content providers, let third party CDNs bid for the volume at the lowest price.

Oh and of course virtually all 3rd party CDNs, clouds and hosted services can be used as a remote origin for the Jet-Stream CDN. So it can also be used as a downstream CDN. 


Open Play is the first real CDN interconnectivity technology and it is executed in a beautiful integrated way. Contact us for information and a demo! The new StreamZilla CDN will be the first CDN to operationally implement it. The technology includes many unique Jet-Stream innovations and these are protected. Note that all described technologies are unique Jet-Stream IPR, we explicitly do not give you the right to mimick or replicate any of the described mechanisms or technologies in any way. Jet-Stream is opening up our code through licensing to anyone. Stealing is intellectual poverty. License and let's share innovation! 


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"


2013-03-25 07:25:02 | CDN Federation

CDN federation or cloud resources?

Although CDN Federation was quite the hype for two years, not much happened in the past year. Some pilot projects are still going on, and interconnectivity standardization efforts are continuing.

What is the future for CDN interconnectivity and federation?

Read more


2011-10-31 00:00:00 | CDN Federation

CDN interoperability reality check

Jet-Stream has been involved in CDN interoperability and federation efforts since 2002. We pioneered CDN resources sharing, CDN overlaying, CDN interconnection meetings and pilot projects. Jet-Stream technology is prepared for various intelligent CDN cooperative models. On this blog and our website we have shared many projects and insights.

In the past few weeks, we have seen an increasing debate about CDN federation and standardization. We see more companies specializing in CDN overlaying. We see more vendors adding proprietary features for federated models. We see multiple standardization bodies working on interoperability standards. We see telecom operators who think their business case relies on federated and exchange business models. And we see a lot of discussion around the topic on summits and in fora.

How serious is the requirement for CDN federation? Let's first discuss what federation is and what it is not...

Read more


2011-10-03 00:00:00 | Business CDN Federation Event Fiber to the Home History Mobile OTT Streamzilla

CDN projects by Jet-Stream

Projects and milestones
Jet-Stream has been involved in more CDN projects than most other vendors have deployed together. We have over 15 years of hands-on experience with CDN challenges, pitfalls and business cases. We have learned how some CDN technologies are limiting customers so we invented better technologies. We have experience with projects from a telecom operators view, but even more importantly also from a system integrator and content owners view. We have learned why some CDN business cases have failed and why others have succeeded, and therefore we can better advise our customers. As the described projects below demonstrate, Jet-Stream has unique experience with CDNs from both ends of the spectrum: from operated CDNs to licensed CDN technologies and any hybrid solution in between.

Read more