Optimizing interconnection policies

  • Authors:
  • Oliver Heckmann;Jens Schmitt;Ralf Steinmetz

  • Affiliations:
  • Multimedia Communications (KOM), Darmstadt University of Technology, Merckstr. 25, D-64283 Darmstadt, Germany;Distributed Computer Systems Lab (DISCO), Computer Science Department, University of Kaiserslautern, D-67653 Kaiserslautern, Germany;Multimedia Communications (KOM), Darmstadt University of Technology, Merckstr. 25, D-64283 Darmstadt, Germany

  • Venue:
  • Computer Networks: The International Journal of Computer and Telecommunications Networking - Special issue: Internet economics: Pricing and policies
  • Year:
  • 2004

Quantified Score

Hi-index 0.00

Visualization

Abstract

There are two basic types of interconnection agreements between providers in the Internet: peering and transit. A decision every Internet network service provider (INSP) has to make is which other peering/transit INSPs to connect with. The potential peering/transit partners offer (obviously) different routes and they may differ quite drastically in the amount and type of charges (line costs, exchange point related costs, settlement costs, administrative costs) they demand as well as in reliability and quality of service. In this article, we discuss and solve problems in this context: the first problem is finding the optimal set of peering and transit partners for one INSP at one point in time, given the routing information and the cost functions of the potential peering/transit partners and the Internet exchange points. Reliability issues (for example enforcing enough spare capacity to absorb the complete failure of one provider) are considered as well as quality of service constraints (e.g., enforcing a certain average AS-hop count). These extended problems are formally described and solved with an optimal algorithm and compared with heuristics. Rates and traffic are in a permanent state of flux, thus an INSP always has to consider whether its current choice of peering/transit partners is still optimal or whether it is worth changing some of its peering/transit agreements. The last part of this article deals with this problem and adapts the algorithm from the first part for this setting.