2014-09-30 16:00:00 | Streamzilla
StreamZilla introduces the largest CDN in the world
Mobile CDN challenges
It's a busy show at Mobile World Congress, with a lot of buzz around video and delivery, so it's time for a reality check on the status of Mobile CDNs.
Mobile technical challenges
CDNs from Internet CDN service providers and technology vendors use passive technologies such as DNS and caching to geo load balance and distribute content. However inside a mobile network you need active technologies to be able to enforce policy control, lawful interception, billing and to optimize storage and traffic flows.
The Jet-Stream active CDN request router can be integrated with mobile network policy controllers. Policy controllers can be told to improve the QoS for individual content requests. We enable mobile operators to instruct the CDN to reduce or increase video bit rates for specific subscribers. This opens up new business opportunities: operators can sell high performance services to subscribers, and can sell premium delivery capacity to content providers. More importantly, the Jet-Stream CDN enables mobile operators and content providers to offer bundled services: subscribers love to pay for premium services if popular services such as Netflix, Whatsapp and Spotify are bundled.
All CDNs from Internet CDN service providers and technology vendors are DNS based because they assume that the IP address of the user(s ISP) can be used to locate this users proximity to an edge cache. However inside a mobile network, users do handover and roam so the IP address is a useless parameter, so DNS is useless as a geo load balancing solution. That is why Jet-Stream invented active request routing. The Jet-Stream request router can be integrated with mobile networks to identify to which radio tower a user is connected, so we can actively send end user requests to the right delivery nodes.
All CDNs from Internet CDN service providers and technology vendors always send end user requests to the delivery edges. However, a mobile network is a three tier layered network with severe backhaul limitations and serious edge capacity limitations. You can't put caches in all the radio towers. You can't delivery all the traffic from the core. Jet-Stream invented multi-tier CDNs with multi-tier delivery and request routing: we send end user requests to caches at the Core, at the GGSN and at the NodeBs, dynamic on a per request basis, policy based. This dramatically optimizes storage, backhaul and performance.
Although Internet CDNs today can stream to a wide variety of devices, they do a lousy job in optimizing content for mobile devices. The Jet-Stream CDN video player is deeply integrated with our active request router. The Jet-Stream video player intelligently loads the right player for the right device and requests the right content via the right services and protocols, for each individual request. So even older Android and 3GPP devices will be able to play back content. Content providers can integrate the player as an iFrame into their portals.
Mobile CDN industry challenges
Technology-wise, Jet-Stream invented a lot of great features that solve core problems for mobile content delivery. However, the largest problems are not in technology (anymore). These are solved and can be solved. What we learned is that the culture inside operators and within large vendors is the real limiting factor. This is about old tech versus Internet tech...
Traditional telco vendors used to be very dominant. They decided which cell phones were allowed on the network. They controlled all the standards as well. But look at who's really in charge in the mobile space these days. Mobile infrastructure is highly commoditized. Radio network vendors get fierce competition from emerging price fighters such as Huawei. European and North American based vendors are unable to innovate. They have no real clue what's really happening around them.
Cell phone vendors used to dominate the space. Then came Apple. Google. Samsung. With smart phones, much better and easier. These companies use the Internet to radically change the mobile industry. They don't care about calling minutes or text messages. They sell devices. They make money out of services. And apps.
Mobile operators got addicted to texting. And then out of nowhere, Whatsapp killed that business. An Internet tech company of less than 55 employees simply killed texting and was purchased for $19 billion by Facebook. This is about software. Apps. Services. New business models. It's radical and it's faster than the telco industry can move. It's not just Whatsapp or Twitter, Facebook. Think Netflix. Think Skype. Calling and texting is dead and the mobile industry is not ready for the data explosion and the business model shakeout.
Some personal experiences:
(large mobile operator) "We need traffic shaping and transparent caching to reduce traffic on our network"
No, mobile operators don't want less traffic on their network, they should want much more, but with a working business model.
(large mobile operator) "We don't want intelligent data traffic management in our network because it could affect voice".
Subscibers prefer data over voice.
(large telco vendor) "we have to pretend we have a working solution for the growth of online video".
OK, that will convince mobile operators to invest billions using your technology.
(large telco vendor) "we are interested in your solution. We want to test it for 6 months, then go through a resel partnership agreement which takes another 6 months, then we want to do a lab trial for 6 months, then we want to train our staff for 6 months).
New radical CDN technologies emerge every 6-12 months so the vendor and their mobile operator customers will never get into business with these long-term processes.
(large mobile operator) "we spend 9 months on an RFP, please respond to our +500 questions by the end of the week and based upon that we will spend another 9 months on selecting a vendor"
OK, let's talk about strategy, vision and challenges before we talk about features, or go waste someone elses time please.
(large telco vendor) "we need you to take responsibility for using open source components".
If you want to play a part in this new world, open source components and cloud based services are what this new industry is built upon.
Traditional vendors are bureaucratic and have no idea what is happening around them. Small startup firms and large Internet companies are disrupting the entire industry while traditional vendors are stuck in their slow processes.
And that is such a waste, because if these companies would be less protective and more agile, they could drive innovative services.
Jet-Stream code licensing
On CDN World Summit, Jet-Stream founder Stef van der Ziel announced a surprise for the CDN industry by unveiling a Jet-Stream CDN technology code licensing program.
Jet-Stream is a true pioneer in the CDN space. Before Akamai was launched, Jet-Stream founder Stef van der Ziel built his first CDN to improve scale and performance of live webcasts in the Netherlands.
Jet-Stream pioneered many inventions in the CDN space, including abstracted delivery and control planes, parallelization of delivery services, cloud-based CDN, active request routing, active content distribution, active policy management, log processing, CDN federation, media workflow integration, automated management and much, much more.
Jet-Stream is proud to have conceptualized, researched and developed all these technologies in-house. We are proud that our technologies have proven over and over to be leading, reliable and commercially successful.
Jet-Stream owns a very rich stack of unique IPR.
Why we license our code?
There are a number of reasons why Jet-Stream has decided to start sharing code.
1) The CDN industry is extremely volatile. New and radical technologies emerge every 9 to 16 months. A CDN is like a living organism that changes, grows and upgrades at a very high pace, while constantly having to support new media workflows with changes and updates every second. We see that traditional IPTV hardware vendors and traditional telecom vendors simply cannot keep up with that pace and don't understand the complexity of what it takes to design a future proof, dynamic, holistic CDN solution. They are stuck. But they have to move forward. The IPTV business is dead. The appliance is dead. Large telecom operator vendors are dead because their organization scale and form simply can't keep up with the pace of the Internet. But their customers need CDNs for their strategies, businesses and cost reductions. These vendors need access to Jet-Stream technologies and need more than just licensing: they need to be able to further develop with our support and they need knowledge as well.
2) Vendors tried to copy Jet-Stream technologies. Without our permission. Jet-Stream is rightfully defending its IPR. We invested years, blood sweat and tears into our technologies. On more than one occasion, various companies tried to partner with Jet-Stream and after a while we found out that they started to mimick our innovations, features, functions, designs and methods into their own products. Jet-Stream sued and won. These companies needed access to our technologies but thought it would be easier, or faster, or cheaper to steal instead of buy. They were wrong. Their technologies were horrible. Development cost them serious money and time, their customers walked away (to Jet-Stream) and their reputation was severely damaged. Jet-Stream does not want to be in courtrooms, we want to R&D great new technologies and do business. So by licensing our code we are helping vendors, hosting providers, system integrators and telecom operators to quickly enter the market with proven and leading technologies and knowledge.
3) Bring the industry to a higher level. Jet-Stream exists because we want to raise the bar for video delivery over IP. That is our mission. We are here to help. We are not a competitor. With our knowledge, experience and technologies, we can burst you into CDN space. By licensing our code, vendors get access to almost two decades of experience with streaming media and CDN, with leading CDN technologies. Costs are low, and Jet-Stream offers various options such as plain code licensing, code sharing and development support, in combination with knowledge sharing programs.
Would you like a demo of our latest technologies? Call +31 50 800 33 00 (EU business hours) or email firstname.lastname@example.org for a 1-hour walk-through of our advanced CDN solution.
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:
- Deploy a physical edge node. Too expensive for the volumes required
- Rent virtual machines through an online hosting provider with US presence. Low cost, fast deployment, pay as you grow.
- Offload into Amazon Cloudfront. Low cost, fast deployment, pay as you grow. Required simple integration.
- 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"