Transit Traffic at Internet Exchange Points?

Ask Dr. Peering

Hi DrPeering,

I am modeling the Internet Peering Ecosystem.

When an ISP connects to the IXP,

1)Is the ISP bound by their stated peering strategy or peering policy to peer or not to peer?
2)Does the ISP only peer at the IXP or is transit allowed?
3)How would the IXP detect and police undesirable transit relationships?

Thank you!

Z.M. Victor Cruise

Tsinghua University

Z.M. - Thanks for the questions.

Bound by Peering Policy? There is no requirement to define, implement or rigidly conform to a peering strategy in order to peer at an IXP. An ISP uses a peering policy to communicate to the rest of the world what they look for in a peer.

They may choose to peer with a network that doesn't meet their peering requirements, or they may deny peering for some that do meet their peering requirements. A peering policy merely communicates what conversations they would like to have.

This allows the ISP great freedom in selecting the nature of the interconnection relationship. They may decide to peer only certain routes, or negotiate partial or full transit relationships. In The Internet Peering Playbook we describe a handful of these “tricks-of-the-trade.”

Transit Sales across IXP? There are several reasons why an ISP may not want to sell transit across a public peering fabric.For example, the ISP may find it far easier to manage a customer relationship across a circuit or private cross connect. This way, all traffic coming in on an interface is known to be customer traffic, and therefore accounting is easy. Further, if there is an issue with a customer connection to the ISP network, then the ISP has an easier debugging situation.

Transit Sales Police? It used to be more common for exchange point operators to disallow selling transit over their exchange point fabric. This is not the norm anymore, and exchange point operators may not have the visibility to determine if the traffic is peering or transit traffic anyway. So, rather than confronting their customers, exchange point operators either look the other way or allow transit sales across the fabric. There are some exchange point operators that try to control or discourage transit traffic across the peering fabric, but they don't have the tools necessary to effectively detect and correct these situations.

IXPs Don’t Control - They Nudge. Having said that, I have heard stories about exchange point operators who advise customers to migrate their peering traffic to a different switch to reduce the load on the shared peering fabric. Another approach was to encourage large peers to migrate large traffic to private peering. This was done at the London Internet Exchange (LINX), and it substantially lowered the reported public peering traffic volume. This seems to be rational as it benefits both peers, it benefits the peering population, and the IXP gets a little more life from their peering fabric. I have also heard stories of peering traffic that was so large that the exchange point operator gently nudged the peers to remove this traffic off their distributed exchange point. But in all of these cases they have never been mandates – these have been advisory nudges intended to help the exchange point population and the peers.

Some IXPs Control. There are some exceptions to the rule however. I have heard a couple stories now of ISPs/Content Providers at the JPIX in Japan requesting cross connects to each other, and having their requests denied because of the negative revenue implications these cross connects might have on the ISP network that owns the KDDI Otemachi building. This is an example of neutrality clash (the interests of the IXP operator clash with the interests of the ISP/Content Provider peers) but also one example of an IXP influencing by more than a nudge. Other examples include the common U.S. IXP colocation-to-colocation cross connects that both colocation IXP operators sometimes discourage through high prices and/or long delays.

I hope this helps -