You’ve read so far in Peering Week about the many hundreds of thousands of connections that join together the 30,000 or so networks on the Internet. Some of these connections are negotiated in minutes by specialist engineers who work for these networks at one of the many peering events that happen throughout the year. The result is a “settlement free” connection between the networks, and traffic between the customers on each network starts to willingly flow.

However, some networks require potential peers to meet and continue to meet various specific technical or commercial criteria before agreeing to peer.

Most of the time such criteria, known in the trade as ‘Peering Policies’ make a huge amount of sense. For example, a peer will often state that they will not make a free peering with someone who is also buying IP Transit from them. Or will not peer with a network that is a “customer of a customer”, so as not to deny revenue from their own customers.

Although many peering policies are beneficial, sometimes peers have policies which have a detrimental effect on their business and the internet as a whole. I’ve picked some of my particularly favourite policies which have the worst unintended side-effects for us all to mock.

Though experienced peering co-ordinators will spot the usual offenders please don’t name the guilty parties in any comments or follow ups.

Traffic Direction Ratio Balance
Peers sometimes require potential peers to maintain a roughly equal amount of traffic exchanged in the inbound and outbound direction. The reason is because the network with this policy is placing an implicit value on the traffic based on its direction, and that for the relationship to have equal value to both parties, the traffic exchanged should be therefore roughly equal in both directions. This policy often exists when a network is large and has a great deal of both content and access traffic.

In this case the policy argument is detrimental to their network because it encourages networks that have a ratio imbalance to give away traffic in the other direction in order to maintain traffic ratios. It means that in the Internet’s grey market, routes to networks with this peering policy exist at a fraction of market rates and sometimes even are offered for free.

This policy is designed to make it hard for a typical network to reach a level in which settlement free peering can be justified, encouraging access networks without content, or content networks without access customers to buy access to the network, though quite the opposite outcome, a grey market, is the outcome.

Backbone size
Peers with a policy that mandates a minimum network size are implicitly valuing traffic based on the distance that each of the peers carries the traffic to each other. The reason this argument exists is because a network with a lot of access customers will need to carry traffic learned from a content network on a national or international backbone, whereas a savvy content network will generate the traffic in the same data centre as the peer and hand it off on a single cable or at the local internet exchange.

However it is wrong to value traffic in this way, when a network with an Internet Access product has such a product for the single and exclusive reason that their customers want to access the content on the peer’s network. It also seems illogical to calculate (and value) the traffic based on distance carried when the content networks face additional costs to originate traffic as closely to the access customers as possible.

Content companies can source their content from more distant locations in order to equal up the amount of backbone work done, but the net result would be higher latency, which means lower video quality, longer page loading times, and a lower general user experience. And the network which has the peering policy faces the same costs whether the content company moves the traffic a long distance, or a short distance.

The network with this policy is trying to encourage the content company to pay for access to the network. In other words, networks with this peering policy are behaving in a way that says their access customers are the product, not their customer. Being paid twice for traffic (from your access customer and from the network customer) is a great outcome for the network, but risking lower quality service for your hard earned Internet Access customers is a significant risk.

Good Peering Policies
Some networks use their peering policy for good, such as mandating that the other party investigates potential network abuse within a particular time, or mandates that the network uses best practice like (BCP38) to prevent abuse from using the peering link. Serious networks do de-peer their opposite numbers (remove the peering link) who do not prevent and investigate abuse in order to ensure that internet abusers do not get a free ride.

Another great policy is one that causes traffic to stay local. Mandating that you peer with all of your peers in every point of possible interconnection means that the peering can take place as closely as possible to your customers, and your peers’ customers. This means that traffic will follow the shortest route between your customers improving latency, and leading to faster and more reliable connections.

Planning your own policy
When building a peering policy for your own network it is important to consider some of the unintended consequences which can occur. Your peering policy and interconnection strategy is one way that your organisation’s culture is reflected. When you place your users experience first, and use policies to trap network abuse and maintain service quality, this should lead to higher performance for your customers, and ultimately more customers. Attempting to hold other networks to ransom with your peering policies carries significant risk and may lead to lower quality services for your customers – a dangerous idea in competitive markets like the UK.

UK internet history – The Early Days of LONAP by Raza Rizvi
INEX’s IXP Manager – Tools to help manage an Internet Exchange by Barry O’Donovan
Regional Peering in the UK by James Blessing
Co-operation makes internet exchanges future proof by Pauline Hartsuiker
Experience of launching an IXP in North America by Ben Hedges
The evolution of an IXP network engineer by Rob Lister
Why does Scotland need an Internet Exchange? by Charlie Boisseau
IX Manchester – It’s quiet up North by James Blessing