Interconnection is All About the Blend

Ask Dr. Peering

Greetings. I have heard you speak about Internet peering and interconnection.

My firm operates an e-commerce site that sells the illudium Q-36 explosive space modulator and our world famous Intergalactic Flying Space Saucer.

DrPeering - Which interconnection method would you recommend for our e-commerce site?

Marvin D. Martian

Marvin -

Welcome to the DrPeering Interconnection Cafe.

The challenge for network architects and engineers is to create and evolve the optimal blend of interconnection strategies for the business. Our interconnection menu is shown below - I would recommend the Content Kava Blend.

DrPeering Interconnection Cafe Menu

The Startup Blend

Initially, network operators and content companies connect to the Internet by simply purchasing Internet. If network connectivity is a strategic part of the business, they may blend Internet Transit from different providers into a multi-homing interconnection solution. When a regional customer base is identified, extending the network with Internet Peering and/or Remote Peering may be explored as a networking optimization.

Content Kava Blend

Content-heavy network operators tend to blend Internet Transit with CDN services to get their static content deployed as close to the consumers as possible. They may also blend in Internet Peering and Remote Peering to distribute their real-time dynamically generated content directly to the access network customers. These content-heavy network operators then focus their attention on optimizing the traffic delivery to the appropriate interconnection vehicle. Viral videos for example might best live on the CDN while long-tailed less popular content may be delivered via the peering and transit paths.

Local Content Blend

The lowest latency solution for Content Providers is a full POP deployment, where the network is extended into a region and the content is delivered from within that regional POP. Many content providers strategically deploy a full POP system into Internet Regions to service a strong and growing customer base. Full-POP deployments however can be time-intensive and cost-prohibitive. As a result, some content-heavy network operators employ Remote Peering to service these markets until they transition to a full-POP deployment. The other model in the field is to deliver regional content from adjacent or nearby Internet Regions. For example, A common tradeoff is to deliver content to India from Hong Kong, Singapore or Tokyo until a local full POP deployment is warranted.

International Blend

Some international ISPs extend a Remote Peering presence to peer traffic away for free in a foreign market, and perhaps purchase inexpensive transit. Across Africa for example, Internet Transit in 2013 is priced around $380/Mbps, and 98% of their traffic is coming from the U.S. and Europe. (We will talk more about this example in the next chapter.) An African ISP may therefore decide to deploy Remote Peering into London to pick up cheap transit ($2/Mbps) and peer away as much traffic as possible. Given the right traffic volume and transport price points, this may be a clever financial maneuver.

Access Network Blend

Finally, a common blend for cable companies in North America includes extending Remote Peering into Los Angeles and Miami to pick up Asian and South American routes and traffic. There may not be enough traffic to justify a full peering deployment but enough traffic to justify a Remote Peering extension.

In any case, the optimal blend will vary based on the network flows, the traffic volumes, and the network requirements of the applications. The job of the network architect and engineer is to determine how to best blend the interconnection methods.

Best of luck with your deployment.

DrPeering@DrPeering.net

Quick - DrPeering - I don’t totally recall - Should my peering use protected or unprotected transport into the IXP?

Douglas Quaid

Douglas -

There tend to be two camps on this issue.

Protected transport is implemented by deploying across two diverse paths, typically with equipment to automate recovery in the event of an outage. Those that insist on protected transport want their peering infrastructure to be as reliable and robust as their Internet Transit service, and they are willing to pay the premium for it (about double the price of unprotected transport.)

Others prefer the lower cost unprotected transport option for their Remote Peering. They view their peering as a local optimization, and the underlying transport breaks, they automatically failover to their Internet Transit service. Many of the network operators in this camp prefer as few active electronics in between them and their peering point. They prefer to know when the underlying transport fails and deal with these temporary failure themselves.

Both sentiments make sense to me. Since peering already has transit as a backup I tend to lean towards unprotected. Save the money. Protected feels like buying an insurance policy to protect against failures of an insurance policy. As long as the transport service comes back up in a reasonable time (an hour or two) you would have to make the case that the value of this optimization is worth the cost.