Building your Own Private CDN

CDN is a trend. Obviously, spreading surrogates across the world is a good solution in order to help web content delivery, shorten the data travel and speed up the page rendition. But there are two point of vue of a CDN: The one of CDN providers, the one of ISPs. BOOSTedge Carrier-grade architecture is specifically designed for the ISPs.

CDN for who ?

Most of the CDN operators claim that they have deployed thousands of servers across the world. Therefore building a CDN appears to be an herculean project. However we must keep in mind that an ISP does not want to build a global CDN since its business is not to compete with actual CDNs but to build an efficient network to compete with other ISPs, that is: building a carrier-size CDN covering its Point of Presence to reduce the ingress volume.

Even if technically pursuing the same goal: delivering the content as near as possible to the user, the economic goals are entirely differents. CDN operators have web sites as customers. ISPs have end-users as customers. CDN operators care to the part of traffic that they signed for and are paid on volume delivered. ISPs cares to decrease the total backbone volume for all sites and serves end-users as fast as possible.

To achieve those goals, CDN providers invest in infrastructure provision, reporting and supervision systems, complex synchronisation protocols between data sources and heavily customized modules. All this mostly to acquire customers, retains them and gaining imore delegated traffic. ISPs, on the other hand, needs constraints free architecture working for all sites and able to guarantee continous service via fail-safe mechanisms.

This is where BOOSTedge constitutes the perfect technological platform for ISPs intending to deploy a carrier-size CDN.

Problematics and Solutions

When deploying a CDN from an ISP point of vue, one needs to address the problem of serving content as a CDN but without the Web site editor help. This leads to different problems to solve:

Directing Requests

Traditionnal CDN means that a Web site will simply serves pages containing elements to be fetched from the CDN. Mainly, this implies one should use specific domains (or allow the CDN provider to handle the main domain). This is quiet intrusive and constrains the relation between the site editor and the CDN provider.

When implementing an ISP CDN, some solution providers attempted to mimic the site elements changes by rewritting pages. It leaded to catastrophic failures and, worst, a so intrusive intervention that ISP's customers got hangry about the transparency of the service. This solution have been phased-out after so many calls to ISP support. On other words, people wants to receive the original content but do not care about the origin of the content.

This poorly designed solution was forced by lack of perfect transparency due to proxying and visible insertion of equipments in the path of the traffic.

BOOSTedge, with perfect transparency operation, avoid rewritting and modifying the content whilst it serve it from it's own storage.

Resolution

CDN providers may avoid rewritting of source page by taking over the original domain name resoluation in order to point the user to a specific server outside the original Web site. Depending on the location of the DNS request, the IP served will be the one of a near(er or est, best case) server from a network point of vue.

This means, for the customer web-site, a danger of takeover. Resolution is key of availability.

Some CDN solution are based on that capability to redirect a request from one CDN to another, depending on real-time measurement.

From the ISP point of vue, pointing a request to an internal server means it takes the risk to serve a proxied content without exactly knowing what will happens next, and even if a specific request can be detached from a sequence or not. This is carefully checked by Web site operators when talking to CDN provider but nothing indicates that from an ISP point of vue.

BOOSTedge does not employ DNS resolution technics to select the closest server. Also working without changing any IP addresses used, it avoids potential problems with servers origins.

Optimization

Production cost for CDN provider comes from provision of requests. Each request needs buffer provisionning, computing power, disk fetch, etc... This means that every bit of possible provision needs to be lowered as much as possible.

Mainly, this means limiting transmission buffers to the minimum, thus limiting the real bandwidth. Limiting to one request per connection to avoid long-lasting contexts, thus forcing reopenning connections to the same site for every request.

As CDN are measured by their time to serve the first response byte (aka "TTFB"), this is not a problem.

For an ISP, the customer service is much more important and time to last byte is a great part of customer satisfaction.

BOOSTedge provides a lot of TCP optimization to help fullfill the performance part. It can also compress content, optimize images or flash objects to help keep acceptable user QoE when load increase and ressources gets reduced on peak hours.

Localized Data

CDN goal is to target request to a closest possible server from the customer. From a network point of vue, this meant city area when Internet infrastructure was young, country-wide after improvement and continental wide by now.

As soon as serving the customer rely on a 10 to 30 ms distance, all is OK from a CDN perspective.

ISP goal is to serve content from the closest point. A POP is the perfect place, just output from the backbone and last concentration point for a maximum of end users.

BOOSTedge, using on-path interception, guarantee the closest possible service.

Building a CDN with BOOSTedge

BOOSTedge have developed various technologies to help deploying caches and CDNs. As explained above, the difference between a cache and a CDN is the level of deployment. A cache is mainly a single point equipment that need to receive HTTP requests and serve it. A CDN is a geographically deployed cache system and needs to achieve two goals: Self contained and able to fit carrier-grade routers.

The CDN usage was first implemented by our lab through IP-less interception technics for an NTT project called "Obake" ("thing that changes" in Japanese). The goal was to deploy optimizing and caching technology inside a national network to selectively enhance services without any customer disturbation. The case was complicated by the requirement to adapt to Vlanized traffic without any IP addressing coherency (multiple VLANs using same IP addressing plans). This was the first real case for what was then called an Active Network: A network that can insert services within the traffic, as opposed to the passive network that only transport packets.

Another demonstration was implemented later to demonstrate integrated load-balancing in conjonction with recently Cisco acquired Starent GGSNs. Conducted in an Cisco lab dedicated to demonstrate equipments for European Telcos, it was demonstrated that BOOSTedge AFR balancer outperformed the most powerfull Cisco router at that time in the PBR routing domain.

As the needs to intercept aggregated links in large POPs, our lab developped a new interception system using SDN switches as intelligent traffic interceptor. This allows using commodity SDN switches while accessing 40 to 100 Gbps capacities.

Each and every ISP have specific needs. There is no one-size-fits-all off the shelf product able to fullfill everyone. BOOSTedge help builds CDN installation by constructing the target platform from our lab bricks, including switches, servers, SANs, balancers, loggers, etc.. We provide fully configured and tested platforms, self-contained and ready to be hooked inside the network.