CDN Strategy Blog

HTTP streaming is seen as the holy grail. It is hot. But what are the benefits and downsides?

Let’s start with the technical differences of digital video delivery:

Read more »

Telecom operators have a four-way strategy to own an on-net CDN. On-net CDNs offer deeper network penetration with better QoS and larger capacity. The CDNs that we deploy support all popular delivery technologies for the web, mobile and IPTV. This means that the telecom operators can:

1. optimize on-net traffic flow, reduce backbone and peering load
2. host and deliver on-net web, mobile and IPTV services
3. sell CDN resources to content owners
4. Take back the distribution role in the value chain

External CDNs could only have addressed number 3 in this list. Read more »

VideoExchange (VDO-X) is our killer app. It is a suite of cutting edge CDN technologies. It is the modern version of good old logistics.

VDO-X is an industry disruptive technology because now any network owner can design, deploy and operate a competitive Content Delivery Network.

Read more »

So you have a large number of servers. How do you load balance viewers over those servers?

You could build a giant farm and use hardware load balancers. Or DNS round robin. This is called a farm, not a CDN.
This implies that all servers need to be able to deliver every asset. Lots of storage costs. No bursting optimization. And there is no geo optimization.

You could redirect viewers by using DNS. Most CDN’s use this.
But DNS can be cached by ISP’s. If you dynamically redirect a user, reroute traffic from geo networks to certain servers, and an ISP overrules your TTL, the users can have a black hole for 24 to 48 hours every time you switch. Ouch.

You could redirect viewers by using BGP. Some CDN’s use this.
But BGP routing could very well imply that you can only distribute from your own network, it requires a lot of knowledge, and it could mean that you have to change the entire network setup. Hmm.

When we had to build our own temporary CDN in the mid 90′s,  we used a simple technology:

Application redirection.
Read more »

So you have a large number of servers and you want assets and live streams to be available on those servers…

You could sync all assets to all servers. Easy.
That takes a lot of time. And expensive storage. It is not dynamic. Why sync unpopular assets to all servers?

You could setup permanent relays for all the live streams. Easy.
That requires a lot of inter-server traffic. It is not dynamic. Why relay unpopular streams to all servers?

You could use caching servers.
We call this PULL. You redirect a user to a cache. If the cache doesn’t have the asset, it will pull it from an origin server, cache it an serve it. The cache flushes the asset after a certain time.
But this means you cannot fully control which assets are allowed to be on which servers for which customers. You cannot manage thresholds per customer. You cannot assign resources per customer. Caching servers don’t cache streams…

So we wrote our own engine called Replicator. Read more »

2003. StreamStat is a fully rewritten, highly optimized, commercialized version of the first rudimentary scripts I had for processing our media server log files.

Media server log files are the most detailed, rich and exact resources for analysis of viewing behaviour of streaming content.

If you use multiple servers and multiple services, the challenge is to get the log files from all the servers on a central server, then merge the log files into global log files.

Read more »

2002. Our first commercial product was XL Media Server. This was a commercialized version of the old parallelization trick I used to run multiple streaming services on a single web server.

XL Media Server now supported Darwin Streaming Server, Apache, RealVideo Server and Windows Media Server. It ran on Windows 2003 server.

I added user management, quota management features and standardized URL’s, content paths and log paths, so the server could be integrated in larger server environments.

Read more »

Until 1998 we streamed in RealVideo. In 1999 QuickTime and Windows Media streaming came to market. (We had ignored Netshow).

We did some tests and wanted to be able to stream in these formats as well. But we did not want to buy extra servers for each format.

So we had to think of a clever way to run multiple services on existing hardware.

Read more »