Content Delivery Networks and Traffic Engineering

Increasingly, “Internet” based content is no longer being delivered by the Internet. The notion that Web sites are on one side of the Internet and consumers are on the other is antiquated. Today, Web sites are engineered into the network. A small few can afford to do this themselves (e.g., Google (News - Alert)), but most outsource this task to content delivery networks or CDNs. This article looks at the role played by CDNs and how they could evolve to offer truly engineered services.

 

In the early days of the Internet, the majority of connectivity was through dial-up 56kbps links, and this metric principally dictated the performance of Web sites. I can even remember how most Web sites shied away from fancy Applets or Javascript, because it was too expensive to download. As the millennium approached, broadband started to become more prevalent, Web sites evolved, and network-based issues began to come to the fore.

 

By far the greatest issues were and remain network latency and packet loss. Websites, which are centrally hosted, can experience significant latency and delay as packets transited the Internet. Every router hop adds a few milliseconds of delay and increases the probability of packet loss. The largest of the dot.coms addressed this issue by purchasing either connectivity or physical space (using their inflated market capitalization) within the larger network access points. These so-called Big 5, (Google, Yahoo, Amazon, eBay (News - Alert), MSN) were able to differentiate themselves, by offering noticeably better response times. Google still returns the number of milliseconds a search took to be serviced, in part a metric of network latency, but also service distribution/scalability.

 

Clearly, not every organization with a Web presence has the wherewithal to build an overlay network. And this is where CDNs come into the picture. While their origins and secret sauce are varied, the formulas are the same: get the content out to where the subscribers are. They reduce latency and packet loss by reducing the number of router hops it takes to access a Web site.

 

By and large the various CDNs dictate the footprint a Web site must adhere too. Each CDN typically has a unique technology for distribution and geographic selection (e.g., what’s the closest server to a given end customer?). As a result, when a Web site is designed, it needs to take into consideration who and how that site is going to be distributed.

 

Having conformed to the template offered by a selected CDN, Web sites receive scalability and enhanced quality of service (QOS). Inherent in the design of a CDN is the distribution of not just content, but also the processing behavior that goes along with it. Transaction processing needs to scale every bit as much as the data or content that goes with it. Scalability is a necessary requirement for the profitability of any Web site – eyeballs matter.

 

The second function, QOS, is equally important. The definition of QOS for data applications is largely defined by latency and packet loss. Given that content is pushed further into the network, this goal can be achieved. Many CDNs, however, claim to specialize in streaming content, with an implication that there is a QOS component to this value proposition. While CDNs can excel at latency sensitive issues, they cannot guarantee streaming QOS, because it is a function of the weakest network link. If the servicing broadband service provider (BSP) offers a low bandwidth or massively oversubscribed network to its customers, that will define the overall QOS. To be fair, however, the CDN does eliminate numerous “weak links” in the network, just not the last access link.

 

While not an exhaustive list, there appears to be three general categories of CDN from a network topology perspective. Traditional CDNs, such as Akamai (News - Alert) or Limelight, connect into key access points in a geography of networks (multiple BSPs). This is done through dedicated high-speed connectivity or co-location of servers in BSP central offices. Each CDN has a unique technology to distribute web site content and behavior, but delivery is through direct connectivity into a given geography. For example, when I go to iTunes, I’m likely talking to a different server/location than the reader might encounter.

 

The second general category is really highlighted by Level 3’s entry into this market. As a backbone inter-exchange provider, L3 has specialized in connecting the diverse BSPs or geographies that make up the Internet. In doing so, it has a bird’s eye view of where data is coming from and where it’s going to. With this knowledge, they have expanded their offering by adding CDN hosting at their inter-exchange network points. A curious aspect of this model, is that it allows for revenue double dipping. As an inter-exchange provider, revenue is generated from traffic that crosses the peering point (these charges typically only apply to traffic that terminates within the BSP). By offering CDN services on the backbone side of the peering point, not only does the CDN generate hosting revenue, but the traffic that crosses the peering point will most certainly be terminated within the BSP, triggering peering revenue.

 

The third general category is what I would call the virtual CDN. This category is more focused on the server and distribution side of the equation. What is interesting in this model is that a target market is the BSP. The BSPs ultimately own the access networks which define the user experience and by definition have the closest proximity to the subscriber. Both latency and QOS are attributes the BSP can define. By leveraging their geographic footprint, they can expand into the hosting business with an explicit advantage. Rather than offering rack space to someone else, they can now offer, through partnership with the virtual CDN, hosting to the end customer. It is arguable that this is really the best model, because issues around QOS can potentially be more tightly integrated into the physical network. It is certainly more attractive to the BSPs, if only to eliminate the peering fees associated with some of the other categories. Recent examples would both BT and Verizon (News - Alert) partnering with Velocix.

 

CDNs offer a scalable and engineered distribution model to the internet, a “global walled garden” into all networks if you will. The question becomes how BSPs view this traffic. Is it competitive with their own service offerings, or is it something that makes their offering better? To date, it has been viewed as benign at best. Traffic coming from these sources retains best-effort markings through the access network. Latency and packet loss is improved by the sheer fact that fewer hops are needed to get to the web sites, but QOS for more sophisticated streaming traffic is lost.

 

However, if the BSP viewed this traffic as services their customers valued, then there becomes an interesting technical challenge. Traditional walled garden services are engineered by the BSP from its source through to the subscriber’s home. More or less a 1-to-1 mapping of service to network resource. With multiple CDNs dropping multiple engineered services into the access network, it quickly becomes a many-to-1 mapping of services to networking resources. This challenge will be explored in future articles.

 

CDNs offer all Web sites the same preferential treatment enjoyed by the greatest of Internet powerhouses. They provide scalability and forms of QOS to address latency and packet loss. CDNs are a natural partner with the BSPs when it comes to end-to-end engineered services. What is missing is the appropriate business model to motivate all stakeholders, and the technology needed to mitigate this convergence of services to the consumer.