Traffic Localization for P2P-Applications: The ALTO Approach

Transcription

1 Traffic Localization for P2P-Applications: The ALTO Approach Jan Seedorf, Sebastian Kiesel, Martin Stiemerling NEC Laboratories Europe Kurfuerstenanlage 36 Heidelberg, Germany Abstract Today, most P2P applications do not consider locality on the underlying network topology when choosing their neighbors on the P2P routing layer. As a result, participating peers may experience long delays and peers ISPs suffer from a large amount of (costly) inter-isp traffic. One potential solution to mitigate these problems is to have ISPs or third parties convey information regarding the underlying network topology to P2P-clients through a dedicated service. Following this approach, the IETF has recently formed an Application Layer Traffic Optimization (ALTO) working group for standardizing a protocol to enable P2P applications to obtain information regarding network layer topology. This paper comprises the problem space for such an ALTO approach, taking into account recent developments in the IETF ALTO Working Group. In particular, we will describe requirements for an ALTO protocol identified in the IETF, concrete protocols which have been proposed so far, and the overall challenges. In addition, we will discuss related issues such as privacy considerations, the relationship of an ALTO service with existing caching solutions, discovery mechanisms for an ALTO service, and security considerations. Keywords-P2P traffic localization; layer cooperation I. INTRODUCTION At large, P2P applications do not consider locality on the underlying network topology when choosing their neighbors on the P2P routing layer. As a result, participating peers may experience long delays and peers ISPs suffer from a large amount of (costly) inter-isp traffic. To cope with these problems, several potential solutions have been suggested which propose P2P traffic localization, i.e., having peers take the underlying network topology into account when selecting their neighbors. For instance, peers can measure message delay to other peers themselves or exploit existing content distribution networks to infer network layer topology distance [1]. One promising approach for P2P traffic localization is to have ISPs or third parties convey information regarding the underlying network topology to P2P-clients through a special service. To this end, the EU FP7 project Napa-Wine [2] is investigating solutions for providing network layer information to peers through such a dedicated service. In addition, the IETF has recently formed a working group for Application-Layer Traffic Optimization (ALTO) [3]. This working group has the intention of developing Internet standards which will help P2P-clients choose better neighbors in terms of mapping the overlay topology to the underlying IP network. Specifically, the main goal of the ALTO WG is to design a query-response protocol for an ALTO service which P2P-applications can query for information to achieve better-than-random neighbor peer selection [3] [4] [5]. In this paper, we summarize challenges and design issues for such an ALTO approach, especially focusing on recent developments in the IETF ALTO WG. Our goal is to highlight the status quo of ALTO standardization and to discuss open issues. The rest of this paper is organized as follows. In section II, we survey existing approaches for P2P traffic localization where network layer information is provided to the P2Player for improved P2P neighbor selection. In section III, we describe current work in the IETF ALTO working group. In addition, in III-D we discuss related issues such as privacy considerations (i.e., ISPs potentially disclosing network topology information to P2P-clients as well as P2P-clients potentially disclosing candidate neighbor peers to ISPs), the relationship of an ALTO service with existing caching solutions, discovery mechanisms for an ALTO service (i.e., how to find an ALTO server given mobility of P2P-nodes), and security considerations. Section IV concludes the paper with a summary. II. PROVIDING NETWORK LAYER INFORMATION TO P2P APPLICATIONS: EXISTING WORK Researchers have started to propose and investigate approaches where information (such as topology, cost, or policies) provided by the underlying network layer can help reduce problems caused by P2P-traffic (such as a high volume of inter-isp traffic). The overall idea is that P2Pclients can choose their neighbors more efficiently (for both the application and the network) by using such information. In particular, the amount of inter-isp traffic which is costly for the network and generates congestion for the application may be reduced. One key goal of such approaches is localization: giving peers information which enables them to choose neighbors not randomly but close to themselves in the underlying network topology. One of the first works to consider locality information provided by the ISP in order to improve P2P-traffic has been [6]. This work studies regular BitTorrent and shows

2 that it is very inefficient from an ISP s perspective, i.e., regular BitTorrent is locality-unaware. To circumvent this, the authors briefly sketch a solution where ISPs intercept P2P-traffic at edge routers and redirect them to P2P-clients within the same ISP. However, they do not investigate such a solution in detail. A more concrete proposal to improve P2P-locality through network layer topology information has been proposed in [7]. The overall idea is simple: Instead of random peer selection, peers are supposed to select all but k peers from their ISP. For instance, if peers have a connectivity degree d (i.e., they are connected to d peers on the overlay layer), d k neighbours for each peer are supposed to be located within the same ISP while k links exist to peers in different ISPs for each peer. This obviously increases locality in peer selection. This is called biased neighbour selection. In [7] the authors envision two ways to implement biased neighbour selection: Either by using a modified tracker or by modifying traffic shaping devices which intercept P2P traffic at edge routers of each ISP. Both solutions assume a way (for trackers or traffic shaping devises) to access information regarding ISP locality. A similar approach has been presented in [8]. This approach is more general and in principle enables neighbour selection on other criteria than network locality. The authors propose to have an oracle to be operated by each ISP, which the P2P-clients in the ISP s network can query to obtain information about the underlying network. The overall idea is that instead of choosing their neighbours randomly, P2P clients can use the ISP oracle in order to choose neighbours with care and insight. More specifically, the oracle ranks a list of potential neighbours based on the ISP s preferences. Such a list can be obtained by the P2P-client through regular P2P operations and then sent to the oracle for guidance on which peers to prefer. The authors evaluate this sorting oracle approach through simulation as well as actual implementation. Their results demonstrate that this approach can increase locality of P2P-traffic with respect to AS diameter, while not increasing the average hop count or node degree. A decentralized alternative for conveying network layer information to P2P-clients is proposed in [1]. This approach re-uses information provided by content delivery networks (CDNs) to guide peer selection for P2P-applications. This idea is based on the fact that CDNs try to minimise download latency. To achieve this, clients are directed to CDN replica servers via dynamic DNS. It is reasonable to assume that if two clients are sent to the same CDN replica server they are likely to be located close to each other on the network topology. As a metric to express network layer locality between peers based on CDN redirection, using the cosine similarity of the replication server ratio maps between two peers is proposed [1]. More recently, [9] investigated what extent of locality is beneficial to P2P-applications in general. Clearly, some degree of inter-isp links needs to be preserved in order to guarantee robustness and prevent network partitioning in the case of node failure. The authors define locality as the percentage of intra-isp connections over all connections with respect to the average peer. Their study concludes that compared to the regular BitTorrent protocol up to two orders of magnitude can be saved on inter-isp traffic if locality is used. Further, they show in a test environment with modified BitTorrent implementations that the capacity of the initial content-seed has strong implications on the potential benefit of employing locality-biased neighbor selection. The P4P [10] research project has developed a framework which ISPs can use to convey network information to P2P applications [10] [11]. The framework of the P4P project is based on two main architectural entities: the itracker and the p-distance. P4P envisions each network provider to operate a so-called itracker. This itracker serves as the portal to be used by P2P applications within this network provider s network to acquire network layer information. Such an itracker can either communicate with the P2P-client directly or indirectly via a P2P-application tracker. At the heart of the P4P framework lies the notion of the p-distance. An itracker can be queried by P2P applications about the p-distance between peers. This p-distance is computed by the network provider (e.g., based on routing policies, topology information, inter-isp cost agreements, etc.). For instance, an ISP could compute p-distances in such a way that connections with higher financial costs for the ISP result in a higher p-distance. The P4P framework has been evaluated through simulation and PlanetLab experiments [11]. In addition, several ISPs have conducted field tests [12]. All these studies provide strong indication that the P4P architecture is suitable for improving download speeds for P2P users while decreasing inter-isp traffic caused by P2Papplications. In summary, research indicates that improved peer selection algorithms based on information provided by an ISP, such as network layer topology or maximum available access bandwidth at a peer, can indeed help in reducing costs for ISPs as well as increase overall download rates for P2P applications 1. These research results made the IETF realize the importance of layer-cooperation in the context of P2P communications. To investigate potential IETF standardization work in this area, the IETF organized a P2P infrastructure workshop [14] in May At this workshop three complimentary work areas for the IETF were identified: provisioned QoS (not followed up), new approaches to congestion (followed up in the LEDBAT working group) and finally traffic localization (handled in the IETF ALTO working group). 1 A good survey on related work can also be found in [13].

3 ALTO service Application overlay topology Resource Query ALTO Guidance Client Application Protocol Peer 1 Peer 2 Peer 3?? Resource From ISP: Static topology information Operational costs Policies text text text Routing state information Physical topology Figure 1. ALTO scenario III. THE IETF ALTO WORKING GROUP As a result of efforts to investigate traffic localization, the IETF formed a working group for Application-Layer Traffic Optimization (ALTO). This working group shall develop Internet standards for better-than-random peer selection by providing information regarding the underlying network. A. Goals and Rationale As noted in the charter of the ALTO WG [3], the goal of this working group is to design a query-response protocol for a service which P2P-applications can query to optimize peer selection: The Working Group will design and specify an Application-Layer Traffic Optimization (ALTO) service that will provide applications with information to perform better-than-random initial peer selection. ALTO services may take different approaches at balancing factors such as maximum bandwidth, minimum cross-domain traffic, lowest cost to the user, etc. The WG will consider the needs of BitTorrent, tracker-less P2P, and other applications, such as content delivery networks (CDN) and mirror selection. Figure 1 shows the overall idea behind such an ALTO service. Assume that Peer 2 in the figure wants to download a particular resource. Assume further that Peer 2 has received (e.g., using a tracker, a DHT, or similar resource directories) several candidate peers from the P2P network which can offer the desired resource. In the figure, Peer 2 can potentially download the desired resource from Peer 1 or Peer 3. At this stage, Peer 2 can query an ALTO service for guidance on which peer to select for downloading. The ALTO service is a source of information for the querying peer regarding network layer information which the peer cannot obtain (or not obtain easily) otherwise. The ALTO service can answer queries based on information provided by the peer s ISP 2 such as information regarding the topology, routing state, policies, or operational costs. In the example depicted it is likely that the ALTO service would suggest to download from Peer 3 because this peer is physically located in the same network as Peer 2. Figure 2 illustrates the scope of ALTO standardization in a schematic way [4] [5]. The ALTO protocol specifies the query-response message exchange between an ALTO client and an ALTO service. The provisioning of topology information (or other kinds of information, e.g., policies) to an ALTO service as well as the P2P application protocol itself are out of scope for ALTO. Note that an ALTO client can be a P2P-client application (Figure 2(a)) or a P2P resource directory such as a BitTorrent tracker (Figure 2(b)). In the latter case, peers would not query the ALTO service directly. Instead, the resource directory of the P2P application would query the ALTO service frequently and use this information as part of the P2P application, i.e., when directing peers to resources (see Figure 2(b)). The underlying assumption for an ALTO service to work and be used in practice is that a Win/Win-situation between P2P-applications and network providers arises. Network providers can benefit from offering an ALTO service by reducing the amount of inter-isp traffic and potentially also by 2 In principle, such information can be provided by the peer s network operator or a third party.

4 Source of topo. info ALTO service Source of topo. info ALTO service Resource directory ("tracker") ALTO client protocol Application protocol Provisioning protocol Peers ALTO client protocol Application protocol Provisioning protocol Peers (a) Application without tracker (b) Application with tracker Figure 2. ALTO architecture achieving better intra-isp localization (e.g., reducing intra- ISP backbone traffic by localization within access networks). Thus, network providers have a clear incentive to offer an ALTO service. P2P applications, on the other hand, can hardly be forced to use an ALTO service. Thus, such a service is optional and will only be used by P2P applications if they experience a gain by using it. A possible benefit experienced by P2P applications can be faster starting of downloads. Also, benefits related to pricing models in users contracts may make an ALTO service attractive for P2P applications. For instance, in the case an operator allows unlimited (flatrate) traffic within its own network but puts a cap on external traffic per user, it can be very useful for a P2P application to know which peers offering a desired resource are located with its own ISP. The overall rationale behind ALTO is that presumably both parties, network providers and P2P applications, will benefit from such a service and therefore will offer/use it. B. Requirements for an ALTO protocol Besides general requirements and detailed requirements regarding protocol semantics, the following high-level requirements for an ALTO protocol have been identified in [5]: Error handling and overload protection: An ALTO server must be able to express certain errors which can occur. Specifically, an ALTO server must be able to inform clients in the case it is overloaded. ALTO server discovery: There must be a discovery mechanism available so that ALTO clients can find ALTO servers. Security and privacy: Authentication and authorization between ALTO entities must be supported by the protocol. In addition, the ALTO protocol must include some protection against Denial-of-Service attacks against ALTO servers. To protect the privacy of users as well as to support the desire of network providers to hide details of their interior network topology, the ALTO protocol must support different levels of granularity regarding ALTO guidance in queries and responses. C. Proposed Solutions While the work of the IETF ALTO working group still focuses on a clear definition of the problem and the requirements, there are already several solution proposals from individual contributors. In addition to smaller issues such as the encoding of messages, the main difference between the proposed protocols and architectures is the allocation of functions between ALTO clients and servers, respectively. These decisions are mainly motivated by scalability and privacy requirements. In all proposals, the basic steps are as follows: 1) The application instance learns the IP addresses (and other connection-relevant parameters, if applicable) of candidate resource providers, which can be contacted to access the desired resource. This aquisition of candidate IP addresses can be done using centralized or distributed databases, such as BitTorrent Trackers, DNS, DHTs, through message exchange (e.g., gossiping), or any other application-specific mechanism. 2) The application passes the list of candidate IP addresses to the local ALTO client. The ALTO client contacts the ALTO server(s) as needed and together they generate the ALTO guidance. This invocation of ALTO can be done by the peer which will eventually access the desired resource (see Figure 2(a)), or it can be done by a third party, such as a tracker, on behalf of the peer (see Figure 2(b)). 3) The ALTO client returns the list of addresses to the application, together with the ALTO guidance. The guidance can be expressed implicitly by sorting the address list according to some rating criteria, and/or explicitly by giving rating attribute values for each address.

5 4) The application instance can combine the ALTO guidance with locally generated ratings (e. g., based on measurements) and then connect to one or several resource providers that have been rated best. If the application is not satisfied with the actually experienced performance, it can connect to other resource providers further down the sorted list, it may query ALTO again, or it can proceed without ALTO guidance. Proxidor: The PROXIDOR protocol [15] is based on the sorting oracle approach [8]. Here, the ALTO client sends the list of candidate IP addresses to the ALTO server, which sorts them according to evaluation criteria. The sorted list is returned to the ALTO client and eventually to the application. P4P: This protocol proposal [16] follows a different approach than proposed in [15]. Here, the ALTO client can download a more-or-less static set of guiding information, which describes regions in the network topology or groups of hosts (usually expressed as IP address ranges) and the parameters that are valid for these regions or groups, respectively. The assessment and comparison of specific candidate peers is then performed inside the ALTO client instance. H12: The two proposals introduced so far have significant differences with respect to information disclosure between the involved parties and privacy concerns (i. e., what can ALTO operators infer about the user s behavior and what can the users learn about the network topology see next section). A second difference is the amount of data that has to be exchanged. When using the approach proposed in [16], the downloaded information may contain detailed information about network regions that do not contain a single candidate peer. On the other hand, the information may be cached at the client and used for the evaluation of candidate peers that were not even known at the time the ALTO guidance was requested. The H12 protocol proposal [17] tries to balance the interests of Internet Service Providers and users. The ALTO client may not only send the addresses of individual candidate peers to the server for having them rated, but also larger network regions or host groups. This reduces the amount of data that has to be transmitted and allows the client to conceal the candidate peer s true identity in an anonymity group. Following the same rationale, the server may answer with more or less detail to the query, according to its own privacy policies. D. Current Issues In this section, we discuss issues which the ALTO WG is currently facing and addressing. For a better understanding of these issues the reader is referred to [4]. Privacy considerations: With the envisioned ALTO protocol, an ALTO client queries an ALTO service for guidance. In order to guide the client, the ALTO service needs at least some information regarding the client s candidate peers. Some P2P applications might consider such information about their potential neighbors in the P2P routing topology as private. In particular, P2P applications might be reluctant to disclose a list of concrete IP-addresses from candidate peers to an ALTO service. Also, applications might consider their criteria for rating candidate peers private and would not be willing to share this information with an ALTO service. However, the less knowledge the ALTO service has about the client s actual needs, the less help its responses might be to the client. On the other hand, ISPs might fear that ALTO responses disclose too much information about their interior network topology or routing policies. Potentially, an answer to an ALTO query might enable the client to infer (at least in part) some details regarding its ISP s business relationship with neighboring autonomous networks. In particular, even if ALTO responses only contain a punctual view on the ISPs preferences, sensitive information could be deduced by sending multiple varying queries to an ALTO server and carefully analyzing the responses. A potential solution to this privacy trade-off could be to convey only disguised or partial information to each other party. For instance, an ALTO client may only send a list of IP-prefixes to an ALTO service and request a sorting of such a list. Depending on the prefix length, the client would disclose only few or partial information regarding its candidate peers. Similarly, an ALTO service may only return a list of very few preferred prefixes or address ranges even if the client requested a sorting of a long list of concrete IP-addresses. In general, the ALTO protocol should not mandate the disclosure of sensitive information by either party and be flexible enough to allow different levels of granularity in requests and responses. Security considerations: Potentially, ALTO servers can misguide ALTO clients on purpose [4]. For instance, an ALTO server could try to prevent a peer from downloading from a certain other peer or a certain administrative domain through its responses. Also, an ALTO server could intentionally guide the requesting peer towards a certain peer which would offer a modified version of the desired resource. However, since ALTO is optional for P2P applications, it is believed that such hostile ALTO servers would eventually be detected by P2P applications and avoided. Furthermore, it is likely that P2P applications will not solely rely on ALTO for peer selection. Instead peers may combine information retrieved through an ALTO service with information retrieved on their own (e.g., through measurements). In other words, P2P applications will only use ALTO services in the long run if they experience a benefit by using ALTO. Another possible security concern for ALTO servers are Denial-of-Service attacks. Depending on the workload a simple ALTO query generates at the server, there is a risk that ALTO servers can be easily overloaded with a large

6 amount of bogus requests. A possible countermeasure could be to use a cookie mechanism 3 as used in other protocols (e.g., IPSec) to protect against Denial-of-Service attacks. In addition, ALTO implementations could be attacked by exploiting software vulnerabilities such as buffer overflows. However, such software security issues are not specific to ALTO and generic techniques may be applied to harden ALTO implementations (e.g., security testing using fuzzing, static analysis of code, or similar techniques). Relationship of an ALTO service with existing caching solutions: Installing caches in or close to the network core is another effective means for optimizing the performance of P2P systems, and ALTO can assist finding a cache which is nearby or has other desired connectivity properties. Advanced issues in the interaction between ALTO and caches, e. g., using ALTO to direct a peer to the cache if the information is already stored there but directing it to other peers otherwise, are still the subject of ongoing research. Discovery mechanisms for an ALTO service: The ALTO guidance will be used for rating alternative resource providers. This must also consider the topological location of the resource consumer, which will eventually initiate the data transfer, because all predictions regarding performance, cost, or other rating criteria have to be made from the viewpoint of this resource consumer. An ALTO server s knowledge may depend on the deployment scenario. It is possible to setup an ALTO server that has a model of the overall Internet topology and can consequently create ratings for any combinations of resource provider and resource consumer location. However, it is also possible that an ALTO server is provided by an ISP and has only a partial view on the overall topology. This kind of server would only be able to produce recommendations for resource consumers that are located in the respective ISP s access network. In the latter case it is important for a peer seeking ALTO guidance to send the ALTO queries to the right ALTO server, in order to receive suitable recommendations. If the ALTO client is integrated into the resource consumer (see Figure 2(a)), the problem boils down to finding the ALTO server of the ISP of the client s access network. This can be done using, e. g., a DHCP or PPP option, which will have to be standardized. If, however, the ALTO query is performed by a third party (e. g., a tracker) on behalf of the acutal resource consumer (see Figure 2(b)), the situation becomes more difficult, as a cross-domain discovery mechanism and/or a referral mechanism between ALTO servers is needed. Several proposals, mostly based on the Domain Name System (DNS), are still under investigation. 3 where each request is first answered with a cookie to prevent fake queries from spoofed IP-addresses IV. CONCLUSION Recent research activities have shown that P2P traffic localization can help in reducing the overall amount of inter- ISP traffic caused by today s P2P applications. At the same time, traffic localization can improve the performance of P2P applications. One promising approach for P2P traffic localization is to explicitly convey network layer information to P2P applications through a dedicated service. Following this approach, the IETF has recently formed a working group for Application Layer Traffic Optimization (ALTO). The goal of the ALTO working group is to define a queryresponse protocol so that P2P-clients can query a dedicated service regarding the underlying network topology. In this paper, we have presented the problem space for such an approach and the corresponding issues for standardizing an ALTO protocol. We explained the overall rationale behind this approach and pointed out requirements for an ALTO protocol. In addition, we discussed current issues such as privacy considerations, security considerations, cooperation with caching mechanisms, and discovery mechanisms for ALTO services. Our goal is to help in defining a proper protocol so that network providers and P2P applications can benefit from ALTO in the near future. ACKNOWLEDGMENT This work was partially supported by NAPA-WINE, a research project supported by the European Commission under its 7th Framework Program (contract no ). The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the NAPA-WINE project or the European Commission. The authors would like to thank Vijay Gurbani, Enrico Marocco, Eric Burger, Jon Peterson, and the members of the IETF ALTO working group for extensive discussions regarding ALTO standardization. In addition, the authors would like to thank the Napa-Wine team for various discussions related to network-aware P2P applications. REFERENCES [1] D. R. Choffnes and F. E. Bustamante, Taming the Torrent: A practical approach to reducing cross-isp traffic in peer-topeer systems, ACM SIGCOMM Computer Communications Review (CCR), vol. 38, no. 4, pp , Oct [2] EU FP7 Project NAPA-WINE, [3] J. Peterson, V. Gurbani, E. Marocco et al., ALTO Working Group Charter, alto-charter.html. [4] J. Seedorf and E. Burger, Application-Layer Traffic Optimization (ALTO) Problem Statement, Internet Engineering Task Force, Internet-Draft draft-ietf-alto-problem-statement- 01, May 2009, work in Progress. [Online]. Available:

7 [5] S. Kiesel, L. Popkin, S. Previdi, R. Woundy, and Y. R. Yang, Application-Layer Traffic Optimization (ALTO) Requirements, Internet Engineering Task Force, Internet-Draft draft-ietf-alto-reqs-00, Apr. 2009, work in Progress. [Online]. Available: [6] T. Karagiannis, P. Rodriguez, and K. Papagiannaki, Should Internet Service Providers Fear Peer-Assisted Content Distribution? in ACM Internet Measurement Conference, Oct [16] R. Penno and Y. Yang, ALTO Protocol, Internet Engineering Task Force, Internet-Draft draft-penno-alto-protocol-01, Mar. 2009, work in Progress. [Online]. Available: org/html/draft-penno-alto-protocol [17] S. Kiesel and M. Stiemerling, ALTO H12, Internet Engineering Task Force, Internet-Draft draft-kiesel-alto-h12-00, Mar. 2009, work in Progress. [Online]. Available: [7] R. Bindal, P. Cao, W. Chan, J. Medved, G. Suwala, T. Bates, and A. Zhang, Improving Traffic Locality in BitTorrent via Biased Neighbor Selection, in 26th IEEE International Conference on Distributed Computing Systems, ICDCS 2006, Jul. 2006, pp [8] V. Aggarwal, A. Feldmann, and C. Scheideler, Can ISPs and P2P Systems Co-operate for Improved Performance? ACM SIGCOMM Computer Communications Review (CCR), vol. 37, no. 3, pp , Jul [9] S. Le Blond, A. Legout, and W. Dabbous, Pushing BitTorrent Locality to the Limit, Technical Report, Inria, Dec [Online]. Available: v1/ [10] R. Alimi, D. Pasko, L. Popkin, Y. Wang, and Y. Yang, P4P: Provider Portal for P2P Application, Internet Engineering Task Force, Internet-Draft draft-p4p-framework- 00, Nov. 2008, work in Progress. [Online]. Available: http: //www-net.cs.yale.edu/projects/p4p/draft-p4p-framework.txt [11] H. Xie, R. Y. Yang, A. Krishnamurthy, Y. G. Liu, and A. Silberschatz, P4P: Provider Portal for Applications, ACM SIGCOMM Computer Communications Review (CCR), vol. 38, no. 4, pp , Oct [Online]. Available: [12] C. Griffiths, J. Livingood, and R. Woundy, Comcast s ISP Experiences In a Recent P4P Technical Trial, Internet Engineering Task Force, Internet-Draft draftlivingood-woundy-p4p-experiences-07, May 2009, work in Progress. [Online]. Available: draft-livingood-woundy-p4p-experiences [13] V. Hilt, I. Rimac, M. Tomsu, V. Gurbani, and E. Marocco, A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem, Internet Engineering Task Force, Internet-Draft draft-hilt-alto-survey-00, Jul. 2008, work in Progress. [Online]. Available: html/draft-hilt-alto-survey [14] J. Peterson and A. Cooper, Report from the IETF workshop on P2P Infrastructure, May 28, 2008, Internet Engineering Task Force, Internet-Draft draft-p2pi-cooper-workshop-report-01, Feb. 2009, work in Progress. [Online]. Available: internet-drafts/draft-p2pi-cooper-workshop-report-01.txt [15] O. Akonjang, A. Feldmann, S. Previdi, B. Davie, and D. Saucez, The PROXIDOR Service, Internet Engineering Task Force, Internet-Draft draft-akonjang-alto-proxidor-00, Mar. 2009, work in Progress. [Online]. Available: http: //tools.ietf.org/html/draft-akonjang-alto-proxidor