Taking Snapshots of the Internet

True to its name, the Internet is a network of networks. Each network, whether a local Internet Service Provider (ISP) or a global content provider, must connect with others to enable the worldwide flow of data we know as the Internet.

There are two ways networks can interconnect:

• Transit is where one network pays another for connectivity to the rest of the Internet.
• Peering is where networks agree to exchange traffic directly.

As a network operator, your willingness to peer is stated in your ‘peering policy.’ There are three types of policies:

1. Open – the network peers with everyone,
2. Selective – the network has defined a set of rules that describes who they peer with and how,
3. Restrictive – these networks have very little interest in expanding their peering.

The set of rules is (also) called a peering policy, which allows you to say “no” for the more open end of the spectrum or set strict requirements to meet for the more restrictive end.

A standard policy that is often difficult to meet requires balanced traffic exchange between the networks. This is popular among transit networks and removes the discussion with potential customers who want to be peers instead.

There are valid reasons to decline the ability to peer with a specific network, even when your business doesn’t sell Internet access to other networks. One example is a wish or need to reduce operational overhead; another is load on the edge routers. Every network and organization running it is different, as are their specific reasons.

How RouteViews Helps Make Sense of Interconnections

RouteViews collects real-time information about the global routing system from the perspectives of several different backbones and locations around the Internet. This information helps users understand who is connected to who and how. Internet operations and research communities often use this information to:

• Debug routing issues.
• Monitor prefixes to discover and mitigate routing hijacks.
• Analyze and evaluate potential peers or new markets for your services.
• Track the deployment of new protocols and security technologies.
• Study the evolution of the Internet’s topology.

All this helps to safeguard the resilience and security of the Internet.

RouteViews has traditionally operated with an open peering policy since more peering would give us more data. However, the landscape of Internet routing data collection is evolving, as demonstrated by our sister project, The Routing Information Service (RIS), maintained by the Réseaux IP Européens Network Coordination Center (RIPE NCC).

RIS introduced a selective policy some years ago and a proactive approach to ensure that collected data would remain useful. RIS’s choice of metrics for the usefulness are:

• The number of routes – do we have every prefix on earth?
• Closeness to the origin of prefixes, grouped by countries – what is the local reach per country?

These are good metrics, and RIS’s approach is successful. Considering this context, let’s understand why we’re changing our peering policy.

Flat vs. Hierarchical Internet

In the old-fashioned Internet, where traffic flowed up and down in the ‘tier 1,’ ‘tier 2,’ and ‘access network’ hierarchy, it was easier to take a snapshot of the connections where the Internet traffic flows.

Today, large traffic volumes flow on the edges of the Internet to and from content delivery networks (CDNs) and cloud systems deployed close to consumers. This interconnectivity information does not propagate up in the old hierarchy but must be collected directly from the edge.

RouteViews’ open peering policy captured the most relevant routing relationships in the traditional hierarchical Internet. However, today’s flat Internet architecture requires us to be more strategic about where and with whom we peer to capture what is happening on the edge.

With these considerations in mind, we are updating the RouteViews Peering Policy to help us balance valuable data for the community and a stable and reliable platform. You can read more about the updates via our Blog.

If you want to support us by peering, please email us at [email protected]. You can also stay up to date with the project via our mailing list.

Adapted from the original post that first appeared on the RouteViews Blog.

Nina Bargisen is a Peering Coordinator at RouteViews.