The Art of Peering: The Peering Playbook

Abstract

Several hundred Internet Service Provider (ISP) Peering Coordinators were interviewed over the past few years for the “Interconnection Strategies for ISPs”, “Internet Service Providers and Peering”, and “A Business Case for Peering” Internet Operations Research papers. In these previous works, we documented the commonly used terminology (Peering, Transit, Transport, etc.), the motivations, the financial justifications, and the process of peering.

In this paper we build upon this foundation of peering knowledge and present tactics that Peering Coordinators have used to obtain peering where they otherwise mightnot have been able to obtain peering. We have identified 20 specific maneuvers that vary from the mundane to the clever, from merely deceptive to manipulative and unethical. Nonetheless, these tactics have been successfully used to obtain peering, and in this paper we document them. Collectively, these tactics represent the “Peering Playbook”, the current “Art” of Peering.

We share 20 peering maneuvers that the Peering Coordinator Community has seen effectively used to obtain peering. (Clicking the links will scroll to the section describing the specific Peering tactic.)

To understand the 20 tactics employed by ISPs in the Art of Peering:The Peering Playbook, it is important to first understand the motivations of two major classifications of ISPs in the Internet hierarchy.

For the Tier 1 ISPs, there are eight interconnection regions in the United States where the Tier 1 ISPs peer with each other that collectively are referred to as “The Default Free Zone”. The motivation for Tier 1 peering is not to reduce transit costs since, by definition, Tier 1 ISPs don’t pay for transit. Rather, they seek to minimize their interconnection costs while providing sufficient interconnection bandwidth to support their customer base and their growth. For this reason, the only peering the Tier 1 ISPs need is with each other, and Tier 1 peering policies tend to reflect this.

The eight interconnect areas across the U.S. are in the NYC Area, Washington DC Area, Atlanta, Chicago, Dallas, Seattle, San Jose (Bay Area), and Los Angeles as shown in the diagram below.

Figure 1 - Eight Interconnection Regions for Tier 1 ISPs

The primary motivations for Tier 2 ISP Peering are to reduce transit fees . Any Internet traffic sent over peering links is traffic that does not go over the comparatively expensive transit links. For like-minded Tier-2 ISPs there is a clear financial win here to peer with each other.

Since the Tier 1 ISPs collectively represent 85% of the routing table, they represent the ideal peering candidates for the large Tier 2 ISPs. For a variety of reasons highlighted in the previous research, the Tier 1 ISPs are not as motivated to peer with the non-Tier 1 ISPs. Hence, as shown in Figure 2 above, the interest in peering is generally one-sided.

Success Stories. The research revealed success stories demonstrating ISPs that started with little or no peering and obtained wide spread peering in a short time period by using one or more of the enumerated tactics. For example, Digital Island Peering Coordinator Mitchell Rose established over 50 peering relationships using a variety of tactics described below inside of a year . In two years time, Anne Gibbons from said that Telia migrated their Internet traffic from 85% transit and 15% peering to 15% transit and 85% peering through aggressively pursuing several of these tactics. Joe McGuckin (Via.net) has emerged with a blended traffic cost much below the cost of transit and a focused 80% peering mix .

Our Graphical Representation of Peering Tactics

To describe these peering “plays” we will first introduce a graphical language we created to graphically describe the maneuvers.

The ISPs

First, the “ISP Initiator” (ISP A) is the one who is first interested in peering with the “ISP Target” as shown as ISP B below. We will apply this naming and color coded scheme throughout the paper.

The ISP Customers

The Customers of the Initiator and the Target are shown as same-colored circles attached to the ISPs as shown below.

Interactions

To convey the initiated Peering and Transit negotiations process we use the directed arc between the ISPs as shown below. Where applicable, specific roles are represented using subscript letters. For example, APC indicates the Peering Coordinator is involved, and BS refers to a sales person at the Target ISP.

Interconnection Relationships

In order to show an Established Peering Session we graphically show the transport “pipes” with a ‘T’ to indicate Transit and a ‘P’ to indicate Peering. When Transit is shown we place a ‘$’ to indicate who is getting paid for transit.

Interconnection Traffic

Finally, to demonstrate traffic going over the Peering or Transit pipe, we use directed lines as shown below. When the relevant traffic is destined to a specific network, the directed line is colored to represent traffic destined to the colored ISP. If traffic destination is not relevant, the color black is used. The thickness of the line represents the amount of traffic. Other variations will be presented as they arise during peering plays.

The Peering Playbook

This section enumerates 20 tactics that have been used to obtain peering. Where appropriate, we highlight those tactics that are only applicable for obtaining peering with Tier 2 ISPs.

For each tactic we present in this paper we demonstrate the tactic graphically.

By far the simplest approach to obtain peering is to simply ask for it. Sometimes the response includes a set of peering prerequisites, and, if the prerequisites are met, a follow up discussion with the target ISP to negotiate peering .

from the target ISP sales force, at trade show or as part of sales process,

from the target ISP NOC.

In the “Direct Approach”, the interactions (shown as directed arcs) show the ISPs engage via e-mail, phone calls, face to face, etc. directly. Obviously, the more complicated tactics will use these diagrams more fully than in this example.

About No Response to Peering Requests

There are many snafus with the Direct Approach . In many cases the Peering Prerequisites are not made publicly available -- they are protected under NDA, or are kept close to the vest. Some of these ISPs say "We know who we want to peer with, we don't need to handle peering requests generally". Many of the initiator ISP Peering Coordinators indicated great difficulty in even getting a return e-mail and/or phone call at all .

E-Mail Challenges. (Shown as "{null}" in the diagram) Email is a tough media for this interaction. It is not clear how much information is needed for the initial interaction, nor whether the target will be receptive to the overtures.

Here are a view vantage points from the field to demonstrate:

Which Email Address? In some cases it is not clear which peering e-mail address to use.

What info in Peering Request? One Peering Coordinator complained that she constantly received peering requests without the basic information like AS#, amount of traffic involved, where they want to peer, etc.

Grammar. Others complained that the requests from other countries were in broken English, very hard to decipher, and therefore the peering discussion to ensue would similarly be difficult to decipher.

Too Much Info in Peering Request. Still others complained that too much information made a request seem too burdensome to process.

Peering Process not respected. Since many of the ISPs surveyed handle "peering requests" as "on-call rotation", a duty that rotates among network engineers on a weekly basis, it is far easier to let these requests drop and let the next person in rotation pick it up. Further, many network engineers don't view the Peering Coordination role as "real engineering work", seeing it more secretarial in nature, not involving coding or configuring computers, etc. etc. It is not surprising that peering requests might not get handled promptly.

Ignorance of Peer. Further, the notion of “Peer” includes the notion of similar size of infrastructure, reach, and traffic volume. The target Peering Coordinator may not know enough about the initiating ISP and/or may not see the initiating ISP as a true “Peer” and therefore not be motivated to pursue the relationship. Startup ISPs tend to be somewhat optimistic about their traffic growth futures, and since so many of ISPs use intuition (in 2002, 95% of ISPs surveyed used brand name recognition ) to determine who to peer with, it is difficult for these unknown companies to be seen as a true “peer.”

Jeffrey Papen (formerly Yahoo!, now Peak Web Hosting) claims that persistence pays off with the direct approach. The peering aliases often include a dozen people or more that are not equally vigilant about handling the peering request e-mail. Sending e-mail to a specific person was mentioned as a method to increase the likelihood of a response. At the same time, anecdotes about expanding the e-mail interactions to include the peering@
<ispdomain>
.net alias were also mentioned as effective in ensuring the broader peering community within the target ISP is kept in the interaction. This way, if discussions get stalled, there are additional folks that are up to speed on the state of the interactions. The consensus among the Peering Coordinator community was that person-to-person, ideally face-to-face, contact for discussion helps speed things along.

The challenges with the Direct Approach have led Peering Coordinators to employ the remaining additional tactics to obtaining peering.

“When envoys are sent with compliments in their mouths, it is a sign that the enemy wishes for a truce. ” -- Sun Tzu, The Art of War

The Transit with Peering Migration tactic leverages an internal advocate (the target ISP Sales Person) to lobby for peering on behalf of the Initiating Peering Coordinator. In this tactic, a transit contract is purchased from the target ISP with an explicit contractual migration of the relationship from a Transit relationship to a Peering relationship should the Peering Prerequisites at the target ISP be met.

The difficulty with this tactic is that Peering Prerequisites evolve. The trick here is to specify the Peering Prerequisites to use at the end of the term of the transit contract. In one case study, Williams executed this tactic with Sprint, and by the end of the contract term, the Sprint Peering Prerequisites had changed . Understandably, this led to heated discussions between the parties. Sprint suggested that Williams re-up for another term and try again at the end of the next term. Perhaps a bit suspicious, Williams instead pursued the “End Run” tactic described next .

“If his forces are united, separate them. ” -- Sun Tzu, The Art of War

The End Run Tactic is intended to minimize the need for peering with (and transit through) a target ISP network by aggressively seeking interconnections with the target ISP's largest traffic volume customers (see figure below) . These largest target ISP customers are then offered free peering or very low-cost transit services by the Initiator ISP. Those customers that accept these offers reduce the load on transit services and reduce the need to peer with the target ISP.

The difficulty with this approach is that while NetFlow traffic analysis does indicate where the traffic is flowing and can help prioritize which customers to target, there may be a lengthy and costly sales cycle in order to obtain sufficient traffic volume to reach the desired End-Run goal. Ultimately the goal is to obviate the need for peering with the target ISP. Then ironically, when you need it less, you can more easily get it.

James Rice (BBC Internet) brought up the Dual Transit/Peering tactic, which is far more common in Europe that in the U.S. This approach combines a transit purchase leverage with a separate peering interconnection. The internal advocate (target salesperson) is used again here to promote the hybrid interconnection approach. This interconnect (shown pictorially below) typically utilizes separate routers and/or interface cards and separate transport to separate customer-customer traffic from transit traffic in order to make accounting easier. The Initiator ISP pays for traffic exchanged on the “Transit” interface card and doesn’t pay for traffic exchanged on the “Peering” interface card.

The benefits of this approach include the leverage of internal advocate at the target ISP and the architectural cleanness of using separate interface cards. The difficulty with this approach is that some ISPs may not have the internal mechanisms to support this dual interconnection , and might rationally prefer a simple transit relationship. Some claim that this has been tried but is ultimately gamed to force traffic along the revenue producing path rather than the intended “free peering” path .

Note: There is an expression in the Peering Community: “Once a Customer, Never a Peer.” Becoming a customer may make you an unacceptable peering candidate so relationships must be timed and managed carefully with potential peers.

”At first, then, exhibit the coyness of a maiden, until the enemy gives you an opening; afterwards emulate the rapidity of a running hare, and it will be too late for the enemy to oppose you. ” -- Sun Tzu, The Art of War

For ISPs just starting out with a desire to become a Tier 1 ISP, the selection of transit supplier(s) is critical. Since “Once a Customer, Never a Peer” will prevent peering with Tier 1 ISPs at a future date , it is often more cost effective and strategically more effective to purchase transit from a large Tier 2 ISP. As the network traffic grows, and the ISP network expands into peering points, peering can effectively reduce the cost of transit. Once enough peering points are activated, enough traffic is carried, and once the peering prerequisites are met, discussions with the Tier 1 ISPs can begin. Not being a customer of the Tier 1, means that no revenue is lost by peering, and therefore there is one less obstacle to overcome .

A close cousin of this approach is to “buy transit only from a sparsely peered Tier 1 ISP”. The anonymous contributor said it best:

“The less peering a Tier 1 has, the easier it is to get their customers to interconnect behind you. For example, if I was a U.S. Cable Company I would I would dump everyone except whoever has bad peering and stick with them for full routes. Then I would peer with as many of their customers as possible to reduce the need to upgrade my transit connection as time goes by. ”

Related articles:

“Ground on which each side has liberty of movement is open ground. ”-- Sun Tzu, The Art of War

Paid Peering is peering in the usual definition of the word but there are dollars exchanged or the costs of peering are apportioned asymmetrically. In some paid peering implementations there are traffic-based fees, sometimes based only on traffic asymmetries. Paid peering is sometimes positioned as a stepping stone toward the ultimate goal of free peering between two parties.

The router configurations, exchange point arrangements, and all peering interconnections logistics can proceed as if they were a free peering arrangement. When both parties agree the peering prerequisites are met, the settlement fees are no longer required and free peering is established.

One form of the “Paid Peering” tactic is where one side covers the cost of the transport between the two parties . Covering these expenses may make it easier to overcome objections to peering with early stage ISPs.

In this tactic, an ISP sells very low cost transit access to the entire peering population at an exchange point . This approach is similar to peering at the exchange point without the overhead of buying and deploying additional hardware, and without establishing and maintaining many relationships at an exchange point.

Note that only the routes announced to the partial transit provider at the exchange are propagated to the customer. While this is not “Peering” by my definition, it is a useful tactic to quickly obtain exchange point routes and it can be very inexpensive for the Partial Transit provider to provide.

Example: James Rice (BBC Internet Service). BBC IS sells partial transit to the members of the LINX that it peers with.

This confrontational tactic was employed in the late 1990’s when Genuity de-peered Exodus. As described in previous work, both ISPs exchanged large amounts of peering traffic. Genuity felt it was carrying Exodus traffic “for free” across the U.S. at substantial cost and wanted a more equitable (revenue generating, for example) arrangement. Exodus felt that this traffic was destined across the U.S. but only because Genuity customers desire the content. Genuity threatened to de-peer.

Exodus didn’t think Genuity would risk disrupting its customers access to Exodus customers. The end result was de-peering and operational disruptions for both Genuity and Exodus customers. Peering resumed only after both sides reached an agreement to spread the traffic load across more interconnection points across the U.S. to reduce the distance the Exodus traffic was carried on Genuity’s infrastructure .

The Chicken tactic is employed to abruptly change the peering relationship dynamic, and as the case above demonstrates, to threaten operational impact if neither side succumbs to a change. It is worth pointing out that the aggressor of the Chicken Tactic rarely increases revenue from this tactic; the disruption is usually so significant, and the destruction of relationship so severe, that the “loser ” does not choose the aggressor as a supplier of transit services.

“Startled beasts indicate that a sudden attack is coming. ”-- Sun Tzu, The Art of War

One of the most clever and devious of all the tactics presented is the Traffic Manipulation Tactic. To understand this tactic you must recognize that the nature of web traffic is asymmetric; that is, small web requests generate comparatively large responses. The Content posters therefore decides which of potentially many paths this relatively large proportion of traffic will flow.

In the Traffic Manipulation tactic, the Content-Heavy Initiator ISP forces its traffic over the potential peers’ transit services, to maximize the target ISP’s cost of accessing the Initiators customer traffic.

To illustrate, consider the figure below, where ISP A wants to peer with ISP B. Assume that the Initiator ISPs large responses normally travel through the target ISPs Peer ‘L’ as shown below.

If ISP A asks ISP B to peer, the answer may rationally be “No, we already get your traffic for free through our Peering arrangement with ISP L. So ISP A does not attempt to peer at this point.

ISP A instead forces its traffic to ISP B to go through ISP W, which is ISP B’s Transit Provider as shown below. This causes ISP B’s transit bill to increase. I heard stories of how this approach was amplified by using a traffic generator to replay traffic from previous months!

After some time elapses, ISP A opens a dialog with ISP B, who reviews the traffic analysis data and is surprised that ISP A has not appeared on the radar screen before as a potential peer. Perhaps it was a spot event, a bug in the peering analysis software. In any case, it is the Peering Coordinators job to deal with these issues rapidly. Seeing the great transit expense that is paid for access to this traffic, the peering decision is easy for ISP B; ISP A is clearly a large traffic peer that is expensive to access over a transit link. Peering is established with the target.

Traffic manipulation stops about a month after peering is established. Since only a very small percentage of ISPs do the traffic analysis necessary to detect this maneuver, this tactic often goes undetected.

The Traffic Manipulation Tactic is most effectively deployed by network savvy Content Providers. Since web traffic is asymmetric, the producer of the responses (the content player) has the greater ability to force a larger amount of traffic along one path or another.

Access Heavy ISPs play this game as well but with different techniques. The initial state is the reverse of the Content Heavy scenario described before; small requests generate large responses from the content provider.

From my conversations I heard of two tactics to force traffic to go along the path that costs the target ISP the most money to access the access providers. The first technique is to simply stop announcing its routes to the target’s Peer. This forces all traffic to use the alternative path, resulting in increased transit fees for the target ISP. Since the Initiator may be indifferent between its two transit provider paths, there is little impact on its costs of traffic exchange, but potentially large impacts on the target ISP cost .

Other Traffic Manipulation Tactics

The second method for Access-Heavy ISPs to manipulate traffic was for ISP A to prepend the AS for ISP B into its route announcement. This way, when BGP propagates the routing information to ISP B, the BGP code would detect a routing loop and invalidate its route to A along this path. This tactic is seen in the community as “evil, clever, and anti-social” at the same time.

Along the same lines, Avi Freedman shared anecdotes of ISPs using widespread web spider deployment that pull content across peering and transit sessions in order to manipulate traffic and to meet peering ratios. Similarly, special deals were made with access-heavy (traffic inbound) customers to accomplish the same thing.

Here are a few additional notes from the Peering Coordinator Community. First, this tactic requires a large amount of spare capacity to handle the manipulated traffic to go along the alternative path . Second, if the tactic is detected, the Peering Coordinator Community is small enough that everyone in the community hears about it. At the same time, Traffic Manipulation is seen by some ISPs as a valid and appropriate means to manage Traffic Volume Ratio requirements for peering with the Tier 1 ISPs.

As stated above, one amplification tactic of the Traffic Manipulation approach is to add traffic generation to the mix . Some ISPs would replay traffic in increasing multiples of Megabits per second in order to meet peering traffic minimums and/or meet traffic ratios .

This tactic refers to the game of Poker where one player over signals its strength, a bluff. Peering prerequisites often include traffic volume minimums to be met in multiple geographically distributed locations. Since many Peering Coordinators do not do the required traffic analysis to disprove an assertion , and the cost of being wrong could be an expensive transit bill, the assertion may be accepted as truth.

Bluffing Traffic Load Futures. The Peering Coordinator in this maneuver typically asserts that the required traffic volumes for peering

a) are met today, or

b) will be met at some point in the short-term future based upon some event.

A large customer soon to be installed is a common form of this bluff.

This approach is effective for several reasons:

it is difficult for the target ISP to determine how much traffic will be exchanged if a peering session is established ,

it is difficult to determine if the initiating ISP is bluffing the new customer win(s),

it is difficult to project the resulting traffic volume if there is no bluff.

In summary, if the initiating ISP is NOT bluffing, it is difficult to compare the transit cost increase against the incremental load on the targeted ISP infrastructure. Since transit is generally an order of magnitude more expensive than peering , if there is a chance the initiating ISP is not bluffing, peering generally makes sense. As with Poker, once the bluff is called and found to be false, future peering negotiations and claims may be difficult.

Bluffing Performance Problems. Eric Anderson (BT Ignite) mentioned a slightly different but related bluff. An ISP Peering Coordinator can also be motivated to peer if the other party can demonstrate a significant performance problem that can be solved by peering. Since both ISPs have customers that are suffering from packet loss for example, both parties have some motivation to fix the problem.

Since few ISPs actively perform the network traffic measurements, they can be persuaded of network problems where none exist. In one case, the evidence of poor performance was a series of traceroutes to demonstrate the packet loss and latency associated with traffic between the two route. By verifying with tools such as Looking Glass these traceroutes were determined to be a farce and peering was not established.

These two tactics generally apply to Tier 2 ISPs peering with other Tier 2 ISPs or content players. There was significant debate in the community about the effectiveness of this tactic .

“If the enemy leaves a door open, you must rush in. ”-- Sun Tzu, The Art of War

One tactic to obtain peering is to publicly promote an open peering policy to the Peering Coordinator community .

Peering Coordinators face rejection and having phone calls and e-mail messages go unanswered as a part of their job. Finding an ISP that has an open peering policy typically means that there will be little resistance in getting peering established. Since the number of peering sessions and the amount of traffic exchanged in peering relationships is often used to gauge the effectiveness of a Peering Coordinator, obtaining peering with “Open Peering ISPs ” is an easy way to make the Peering Coordinator look good.

The Wide Scale Open Peering Policy tactic is an untargeted approach and generally is executed only by Tier 2 ISPs looking to minimize their transit costs by maximizing their peering with other small and medium sized ISPs.

Along the same lines but separable from the Wide Scale Open Peering Policy is the tactic of building a large number of Points-Of-Presences (POPs) in a large number of exchange points . This tactic maximizes the possibility of meeting the collocation peering prerequisite with a large number of target ISPs in geographically dispersed locations.

"Meet you in 3 time zones? No Problem. Meet you in person at DECIX member meeting? Absolutely!" Broad participation in colocation sites leads to many avenues for dialog with peering folks and many more opportunities for interconnection.

“Forestall your opponent by seizing what he holds dear, and subtly contrive to time his arrival on the ground. ”-- Sun Tzu, The Art of War

The Aggressive Traffic Build up tactic involves acquiring a massive amount of customer traffic that an ISP can then turn around and offer to a peer by peering arrangement. Since the alternative way to access this traffic is through expensive transit relationship(s), the target ISP is motivated to peer.

This tactic is only applicable to Tier 2 ISPs . It is also a way for the Tier 2 ISP to ultimately meet the traffic volume prerequisites for peering with the larger players. Care must be taken with this tactic in order to balance peering traffic ratios at the same time as picking up massive amounts of traffic .

It is often said that peering is a game of relationships, and this tactic simply makes that point. Peering relationships have been established between networks of unequal size solely based upon friendships between Peering Coordinators. Attending NANOG, hiring Peering Coordinators with many years of experience and extensive contacts in the Peering Coordinator Community, and leveraging introductions are all ways to build these relationships.

Some exchange points have established a role of “Chief Technical Liaison” to pull together the Peering Coordinator community. This has been especially effective at International Exchange Points where the participants may come in from different countries and may not know each other .

To avoid regulation most of the Tier 1 ISPs have stringent peering request process that would not allow a casual peering session to be established. For this reason, this tactic only applies to Tier 2 ISPs.

One approach Mitchell Rose (Digital Island) used to establish peering was to send e-mail non-selectively to all participants at various exchange points. Please make sure that “Reply to Self” and not “Reply to List” is selected . This approach led to dozens of peering sessions very quickly. Since many exchange point participants adopt the Peer Widely and Peer Openly tactic, this approach effectively yields peering with a potentially large number of ISPs and Content companies.

The problem with this approach is that the result might be a large number of high maintenance low volume peers. This tactic is generally only employed to Tier 2 ISPs; Tier 1 ISPs have plenty of large volume peering candidates approaching them so they don’t generally solicit peering.

"Begin by seizing something which your opponent
holds dear; then he will be amenable to your will. " -- Sun Tzu, The Art of War

Named for the adage, Yahoo! adapted the Honey approach by promoting the desirability of its content as a key reason to peer with them. As one of the largest portals in the world, Yahoo! describes the thousands of live webcast events, the hundreds of thousands of concurrent streams of content delivered, the gigabits-per-second of raw traffic flows, etc. as reasons why an ISP should want to receive that over a peering relationship instead of through their transit relationship. Since ISPs hold their network performance dearly, Yahoo! leverages this performance aspect lure well.

This tactic is only applicable for content heavy Tier 2 ISPs and network savvy content players.

This tactic was more popular in the 1990’s than it is today, but it is worth noting. Level 3 was unable to obtain peering with the Tier 1 ISPs in the early days so it acquired networks that had already established peering with a couple Tier 1 networks. Under the assumption that this peering would transfer to the larger aggregate company, Level 3 acquired the ISP in order to leverage the pre-established peering arrangement and build upon it.

More recently, NTT purchased Verio for several reasons including the Tier 1 Peering it had obtained . Some would say that this is the easiest tactic to execute, but some caution legal review of the Peering Contracts, and warn that most peering contracts (BiLateral Peering Agreements) have 30 day termination clauses. The peering may not last beyond the acquisition date.

“Hold out baits to entice the enemy. Feign disorder, and crush him.”-- Sun Tzu, The Art of War

A large parent company may be able to initiate peering negotiations where a smaller subsidiary may not. The Bait and Switch tactic leverages this fact by negotiating peering for a large traffic source or sink, and then announcing a different and much smaller traffic source or sink when setting up peering.

As a hypothetical example, IBM might seek peering and obtain interest given the sheer size of the enterprise. When it turns out to be an IBM subsidiary and only a small portion of specific customer traffic, the ISP may decide that it had gone down the path far enough just to turn it on and be done with it.

Two ISPs, an Initiator and Target ISP are attached to a shared exchange point fabric such as an Ethernet LAN. The target ISP network operations center is contacted to “repair” a down peering interconnection. The target NOC and/or on-call engineer may edit the router configuration and establish peering where peering was never intended to be established .

The most common response from Peering Coordinators was “I wonder what our NOC would do?” The VP of Engineering for a large European ISP shared with us that their NOC refers to this tactic by number, as in "Hey, last night we had another 19".

One large ISP met the peering prerequisites of a Tier-1 ISP but was refused peering because peering would significantly reduce transit revenue . The objection was overcome by expanding the broader business relationships in exchange for peering. The resulting combined arrangements left the Tier 1 cash flow neutral or slightly cash flow positive and with a stronger customer relationship by selling its other services.

It is also well known that AOL obtained Tier 1 status by leveraging its customer relationship with the large Tier 1 ISPs. Peering became a real revenue generator for those who accepted peering as part of the deal.

“To begin by bluster, but afterwards to take fright at the enemy's numbers, shows a supreme lack of intelligence.”-- Sun Tzu, The Art of War

Conversations with Peering Coordinators revealed several approaches that were not effective:

Foreign PTTs have attempted exert market dominance in a new market as if they were the PTT in the new market. Attempting to leverage power position in a foreign land in a new market has proven ineffective and tends to have an alienating side effect.

Threatening litigation and government intervention often shuts down the conversation between Peering Coordinators .

Public Name Calling and badgering in public forums proves to bring personality conflicts into play and often results in doors being closed that should be open.

Blind request peering from the largest target peers first. Make sure you research the peering requirements and your build your people network well before initiating contact. Many peers for example insist upon geographic diversity for peering. Having some knowledge of the common collocation environments and a sense of these peering requirements signals that the peering process and ongoing operations will not be an undue burden.

Demonstrating lack of knowledge regarding backbone operations often stops the peering discussion. Interestingly, demonstrating too much knowledge was cited when arrogance led to personality conflicts. “In the end it’s knowledge and Attitude. ”

Refusal to register routing information in the Routing Registries is a quick way to have peering requests ignored .

(Note: I received push back from several ISPs -- that applying regulatory pressure has been effective. For example, during pending mergers (e.g. WorldCom and Sprint) some ISPs used peering in trade for not claiming monopoly powers of the merged entity .)

Summary

We share 20 peering maneuvers that the Peering Coordinator Community has seen effectively used to obtain peering. (Clicking the links will scroll to the section describing the specific Peering tactic.)

Who is William B. Norton?

Executive Director, DrPeering International

Chief Strategy Officer, International Internet Exchange (IIX)

WIlliam B. Norton is the author of The Internet Peering Playbook: Connecting to the Core of the Internet, a highly sought after public speaker, and an international recognized expert on Internet Peering. He is currently employed as the Chief Strategy Officer and VP of Business Development for IIX, a peering solutions provider. He also maintains his position as Executive Director for DrPeering.net, a leading Internet Peering portal. With over twenty years of experience in the Internet operations arena, Mr. Norton focuses his attention on sharing his knowledge with the broader community in the form of presentations, Internet white papers, and most recently, in book form.

From 1998-2008, Mr. Norton’s title was Co-Founder and Chief Technical Liaison for Equinix, a global Internet data center and colocation provider. From startup to IPO and until 2008 when the market cap for Equinix was $3.6B, Mr. Norton spent 90% of his time working closely with the peering coordinator community. As an established thought leader, his focus was on building a critical mass of carriers, ISPs and content providers. At the same time, he documented the core values that Internet Peering provides, specifically, the Peering Break-Even Point and Estimating the Value of an Internet Exchange.

To this end, he created the white paper process, identifying interesting and important Internet Peering operations topics, and documenting what he learned from the peering community. He published and presented his research white papers in over 100 international operations and research forums. These activities helped establish the relationships necessary to attract the set of Tier 1 ISPs, Tier 2 ISPs, Cable Companies, and Content Providers necessary for a healthy Internet Exchange Point ecosystem.

Mr. Norton developed the first business plan for the North American Network Operator's Group (NANOG), the Operations forum for the North American Internet. He was chair of NANOG from May 1995 to June 1998 and was elected to the first NANOG Steering Committee post-NANOG revolution.

About the White Papers...

The Peering White Papers are based on conversations with hundreds of Peering Coordinators and have gone through a validation process involving walking through the papers with hundreds of Peering Coordinators in public and private sessions.

While the price points cited in these papers are volatile and therefore out-of-date almost immediately, the definitions, the concepts and the logic remains valid.