traffic on an ISP network. This may cause the ISP to change some routing metrics and therefore some paths (at the routing layer) in order to improve its network utilization. This can however cause a change of routes (at the application layer) by the P2P system, which may again trigger a response by the ISP, and so on. In summary, we identify the following drawbacks:
The ISP has limited ability to manage its traffic and therefore incurs potentially increased costs for its interdomain traffic, as well as for its inability to do traffic engineering on its in- ternal network.
The P2P system has limited ability to pick an optimal over- lay topology and therefore provide optimal performance to its users, as it has no prior knowledge of the underlying In- ternet topology. It therefore has to either disregard or reverse engineer it.
Different P2P systems have to measure the path performance
While we do not know of a P2P network that tries to reverse- engineer the Internet topology, there are some proposals that sug- gest that P2P networks should bias their overlay topology by choos- ing neighbors that are close in the sense of high throughput or low latency, e.g., [18, 19, 20] or that are within the same AS, e.g., [10, 21]. Others such as the Brocade  system propose to build an overlay on top of a structured DHT P2P system that exploits knowl- edge of the underlying network characteristics. Yet another sys- tem  proposes to use caching to relieve the tension between ISPs and P2P systems.
We, in this paper, propose and evaluate the feasibility of a sim- pler solution where ISPs help P2P systems by offering an oracle service. The oracle acts like an abstract routing underlay to the overlay network but as it is a service offered by the ISP it has di- rect access to the relevant information and does not have to infer or measure it. For example, an ISP knows whether a customer has a DSL broadband or a modem connection, its link delay, etc. The benefit to the ISP is twofold: first, it can now influence the P2P routing decisions via the oracle and so regain its ability to perform traffic engineering (control the traffic flow) and second, the P2P measurement traffic to infer network distances is omitted. The P2P users benefit as explained below.
An oracle service
Let’s consider how unstructured P2P networks tend to maintain their topologies. New P2P nodes usually retrieve a list of members of the P2P network either via a well known Web page, a configu- ration file, or some history mechanism [2, 5]. They then pick some subset of these as possible neighbors either randomly  or based on some degree of performance measurement . If the chosen neighbor cannot serve the new node it might redirect the new node by supplying an alternative list of P2P members.
Instead of the P2P node choosing neighbors independently, the ISP can offer a service, which we call the oracle, that ranks the potential neighbors according to certain metrics. This ranking can be seen as the ISP expressing preference for certain P2P neighbors. Possible coarse-grained distance metrics are:
inside/outside of the AS
number of AS hops according to the BGP path 
distance to the edge of the AS according to the IGP met-
ACM SIGCOMM Computer Communication Review
For P2P nodes within the AS the oracle may further rank the nodes according to:
geographical information such as: same point of presence
(PoP), same city
performance information such as: expected delay, bandwidth
link congestion (traffic engineering)
This ranking can then be used by the P2P node to select a closeby neighbor although there is no obligation.
The benefit to P2P nodes of all overlays is multifold: (1) they do not have to measure the path performance themselves; (2) they can take advantage of the knowledge of the ISP; (3) they can expect im- proved performance in the sense of low latency and high throughput as bottlenecks  can be avoided. That P2P networks benefit by increasing traffic locality has also been shown by Bindal et. al  for the case of BitTorrent.
The benefit to the ISPs is that they can influence the neighbor- hood selection process of the P2P network to, e.g., ensure locality of traffic flows and therefore again have the ability to manage the flow of their traffic. This will also allow them to provide better ser- vice to their customers and ensure fairness for other applications like Web traffic, etc. Besides, the ISPs will gain cost advantages, by reducing costs for traffic that leaves their internal network.
As the ability to control/manage its traffic is crucial to the oper- ating costs of every ISP, we expect that the benefit accruing from this ability will outweigh the potential risks of providing an or- acle, namely that the oracle exposes some information about the ISP topology and the network performance. As the oracle server only needs to roughly rank the IP nodes, it does not need to reveal more information about its network than can anyhow be inferred by reverse-engineering the ISP network via measurements .
The oracle is available to all overlay networks. One does neither need nor want to use a separate oracle for each P2P network. Fur- thermore, as an open service, it can be queried by any application and is not limited to file-sharing systems. Hence, querying the ora- cle does not necessarily imply participation in file sharing systems. This should limit the desirability of the oracle logs to, e.g., the mu- sic industry. Moreover the P2P system could permute, e.g., the last byte of the IP addresses it is interested in or use an anonymization service for querying the oracle.
Realizing an oracle service: It may seem rather challenging to build such an oracle in a scal- able manner, but much more complicated services, e.g., DNS, al- ready exist. The oracle service can be realized as a set of replicated servers within each ISP that can be queried using a UDP-based pro- tocol or run as a Web service. It can rely on a semi-static database with the ISP’s prefix and topology information. Updating this in- formation should not impose any major overhead on the ISP.
While the oracle service is not yet offered by the ISPs, P2P nodes have the chance of using a simple service to gain some of the or- acle benefits already using the “pWhoIs” service . This ser- vice is capable of satisfying 100,000 queries using standard PC- hardware  in less than one minute. It enables the P2P node to retrieve information about possible P2P neighbors such as the AS and some geographic information. This information can then be used by the P2P node to bias its neighbor selection. But purely us- ing the “pWhois” service only helps the P2P system. It does not enable the ISP to express its preference and therefore does not en- able cooperation.
Volume 37, Number 3, July 2007