The peering coordinators’ toolbox - part 3

• Part 1 - Economics: How to understand the cost of your connectivity
• Part 2 - Performance: How to understand the services used by your customers
• Part 3 - Analyze: How to improve your CDN and peering connectivity
• Part 4 - Select: How to find the right transit provider

The peering coordinator’s toolbox is a blog series where we dive deep into the peering coordinator workflow and show how the right tools can help you be successful in your role.

Part 3: Analyze

How to improve CDN and peering connectivity

In part 1 and part 2 of our series, we focused on how to understand the most important services on your network. We also identified the sources and destinations for these services by looking at which CDNs are in the digital supply chain. In this post, we’ll assume you’ve already identified which CDNs to embed and which ones to peer with. That means you already have the beginnings of your peering-prospect list. The next step is to find the peering prospects for the rest of your traffic.

Finding peers

Kentik’s Discover Peers tool shows you top-potential peers based on traffic volume. You can restrict the tool to only look at traffic from your transit interfaces or you can include all your external-facing interfaces. You can also exclude ASNs that are not interesting for the analysis (for example, those you already have found a solution for).

There are a couple of dimensions to use when looking for peering prospects. In part 2 of the series, we talked about the need to balance cost and quality. In that example, you’ll want to see if you can move traffic to a more cost-effective connection according to the analysis you have from part 1 or create a shorter path for the traffic by peering. But how do you get that level of detail?

Once you have your raw prospect list you can start evaluating each of the networks on the list.

Using the Discover Peers tool, you can filter the list of prospects based on whether they have an open, selective or restrictive peering policy. This is based on registration information in PeeringDB, the global community database where networks that peer register and maintain their peering details.

The basics of peering policies

A peering policy is a declaration of a network’s intentions to peer. A network can state if it has the following:

• Open peering policy - will peer with everyone and everywhere possible
• Selective peering policy - will generally peer, but there are a set of requirements that define how mutual benefit can be gained from peering
• Restrictive peering policy - will peer, but not seeking new peers and will generally decline any requests

The peering prospects with an open peering policy are straightforward — it’s just a question of reaching out and agreeing on where and when.

It’s most common that networks agree to peer in all mutual locations. That’s because, well, it’s mutually beneficial. Most networks will hand off the traffic as soon as possible. And peering in all mutual locations makes it more likely that there is fair share in terms of the burden of carrying the traffic. When that is not the case — for example, when an eyeball network peers with a content network — the parties work out an agreement on where to peer so it makes sense for both parties.

As for the networks with a selective peering policy, they usually document their requirements and lay out their justification for saying no to peering. The most common requirements or restrictions are:

• Ratio - the network requires a certain balance between the sent and received traffic from the potential peer
• Volume - the network requires a certain volume to justify the increased workload involved in setting up and maintaining connections
• Locations - the network requires a certain geographic overlap between the networks so they can hand off traffic most efficiently and save bandwidth within their own network
• Customers of an existing peer - if your network is a customer of an existing peer to your peering prospect, your traffic is already on a free connection for them and your traffic might be needed in a potential ratio-relationship between your peering prospect and your provider

How to manage selective peering policies

You may be wondering: Can I do anything so that networks with a selective peering policy (where I don’t meet all the requirements) will agree to peer with me?

The thing to remember is that the policy creates a basis for the prospect to say no. That doesn’t necessarily mean that a peering relationship won’t be of mutual benefit. It just makes it your job to prove it. You might also need to implement some changes in your network and your routing to meet their criteria.

Flow tools, like those that Kentik offers, are essential for documenting exactly what the volume and ratio of the current traffic between you and your peer prospect is. And you already did this when you identified this network as a desirable peer.

But how can you identify potential opportunities to increase the volume in one direction to fix a ratio or to simply boost the traffic? To do this you need to identify traffic-flows that move to the potential direct connection between you and the prospect, but that which, today, is not routed through the prospect’s network at all.

You need to be able to answer: “Who are the customers of my peering prospect?”

Kentik Market Intelligence (KMI) can answer this question for you. With KMI, you can find information about the customers of a network. Using the Kentik Data Explorer, you can also see the traffic to and from your network to each of the multi-homed customers. With that, you should look for traffic that flows via a path outside of your potential peer’s network.

In the example below, we’d like to peer with AS12345 with a selective peering policy, but our current traffic to them is not high enough for us to meet their traffic volume requirement.

With KMI we can see their customer AS4567 after we exclude our mutual customers and their single-homed customers:

A quick glance at Customer 1 shows us their provider list:

We then use the Kentik Data Explorer to investigate if we have traffic to AS4567 that can help us. In this example, we search for traffic going to AS4567.

If we break that out by the BGP next-hop and the second hop ASN, we find traffic going through our transits to their transit AS3356:

We can now use this data to argue that a new peering with prospect AS12345 will increase the total traffic from us to them with ~1 Gbps to better meet their traffic requirement. In addition, they might increase their revenue from the customer.

Now you might be asking: How can I select the best transit provider to support my peering strategy? And how can I minimize my total network cost? Stay tuned for part 4 of our peering coordinator’s series, where we’ll answer those questions.

Ready to try it yourself? Start a 30-day free trial.

START NOW