By Rob Parker, Interconnection Director

Optimize network performance by ensuring both you and your peers are locally connected.

When it comes to Internet Exchanges (IXs), there are two types of peering: local peering and remote peering. And depending on your network setup and goals, the type you use can have a significant impact on your network performance.

While remote peering has valuable use cases, we often see customers using it in scenarios where it is actually doing more harm than good to their network performance. Below, we compare local peering and remote peering so you can choose the right method for your business.

Choosing an IX

Typically, when selecting an IX, your priorities might include:

• which IX has the most networks
• the highest volume of traffic
• identifying specific networks to reduce transit use.

Whatever metric you use to make your decision, the ultimate goal is to increase performance, which requires each present network to operate equipment that is physically located in the same metro area as the IX. This is a common assumption to make, but is it always the case?

About local peering

The mantra of “keep traffic local” is often touted as a key reason to join an IX, and for good reason.

One of the most valuable reasons to peer at an Internet Exchange (IX) is to improve performance by reducing latency and ensuring traffic is exchanged between your networks as expeditiously as possible. Peering at an IX achieves this by ensuring all participants have access to each other within a local fabric, available across a number of data centers within a metro area.

To achieve these performance improvements, the coverage of an IX remains within a single metro area – perhaps a single city (such as Frankfurt or Sydney) or small group of cities in close proximity with each other (such as New York and New Jersey, or the San Francisco Bay Area). With this sort of geographic coverage, participants would typically be within approximately 50-100 miles (80-160km) of each other at most, and at the speed of light, fractions of a millisecond apart.

The low-latency interconnection of a single-metro IX enables higher throughput, faster response times, and less dependence on a transit provider and the wider internet – so less potential for problems like packet loss or routing issues. To end users, of course, this manifests as valuable improvements like faster website loading times, seamless content streaming, and more responsive online gaming.

About remote peering

The alternative to local peering is remote peering: when a network connects to an IX in a different metro area to their equipment, perhaps using some form of third-party provider to reach the IX. Sometimes the IX itself may offer a remote peering product.

There are many valid reasons a network might choose to remotely connect to an IX, for example:

• they are present in an adjacent city with no IX
• they have valuable traffic to exchange with a specific peer
• they wish to increase geographic reach to pick up new customers
• they wish to connect in another geography to avoid expensive local transit providers.

This of course poses no issue for the IX, or the network that is remotely connected, since they are fully aware of the latency between their equipment and the IX. But what impact does this have on other peers at the IX who may not be aware that this new peer is actually located some distance away?

The most immediate effect of this setup will be impaired throughput and latency. But remote connectivity to an IX may also introduce single points of failure that are completely invisible to all connected networks until a problem occurs, making one of the main benefits of peering at an IX redundant. This is the major reason Megaport encourages peering at more than one IX per metro area.

How to peer for optimal performance

When joining an IX, it is important to identify which networks are essential to you—that is, which ones you’ll exchange the highest volume or most valuable traffic with—and where their equipment is in relation to yours.

You can often determine this information using tools like PeeringDB or bgp.tools, or a looking glass with ping capabilities such as that provided by Hurricane Electric or RIPE. Some IXs may also make this information easily accessible in their looking glass, too.

Identifying the latency or distance between your network and the peer you’re interested in exchanging traffic with is essential, as this will directly influence the throughput (and potentially the quality) of interconnection.

In summary, when selecting your next IX, we suggest following this simple process:

1. Identify your most important flows and volumes, and find IXs where they are present.
2. Use publicly available tools to determine latency between the IX and the networks that are most important to you.
3. If you’re still unsure which participants are local and which are remote, ask the IX operator or remote network for more information.
4. If the traffic exchanged via an IX is business-critical and you’re able to connect to more than one IX, it’s a great idea to do so.
5. If you require a remote connection to an IX, talk to your remote peering provider and ask them about single points of failure and network resilience.

Get personalized guidance on your peering setup and discover how MegaIX can help. Book a chat with our friendly team.

Learn more about MegaIX