ALTO Ilkyun Park Internet Draft Byung-Tak Lee Intended status: Informational ETRI Expires: April 18, 2010 October 18, 2009 Virtual P2P Tracker for Full-Distributed P2P Applications draft-ikpark-alto-virtual-p2ptracker-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 18, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Ilkyun Park, et al. Expires April 18, 2010 [Page 1] Internet-Draft Virtual P2P Tracker October 2009 Abstract This document describes the virtual P2P tracker mechanism for ALTO clients that are embedded in P2P clients, not P2P tracker. An ALTO server does significant role that is collecting ISP's network information, and responding ALTO clients' queries of ALTO guidance. With this mechanism, ALTO server or P2P clients can reduce the load for selection of the list of optimized peers even if any P2P tracker isn't included in the P2P application. Table of Contents 1. Introduction ................................................ 3 2. Virtual P2P Tracker Mechanism ............................... 3 2.1. P2P Client with ALTO Client ............................ 3 2.2. PID Head ............................................... 4 2.3. PID Head Election ...................................... 4 3. Security Considerations ..................................... 5 4. References .................................................. 5 4.1. Informative References ................................. 5 Ilkyun Park, et al. Expires April 18, 2010 [Page 2] Internet-Draft Virtual P2P Tracker October 2009 1. Introduction As discussed in the ALTO problem statement [draft-ietf-alto-problem- statement], traffic occurred by Peer-to-Peer (P2P) applications occupies a large portion of network capacity in the Internet. P2P application selects its peers regardless of underlying information of network topology. As a result, P2P application traffic is easy to cross among different ISPs' networks in multiple times. This increases network load and reduces the performance of P2P applications. To resolve this problem, an ALTO server manages the network topology information of one or more ISPs, and P2P trackers of P2P applications use it for selecting lists of peers for the P2P clients that want to select peers. By this, much of P2P traffic will be able to be localized into fewer ISPs' networks. But some P2P applications form full-distributed P2P architecture. They manage peer lists with distributed information like distributed hash tables (DHT) or peer exchange (PEX). In this case, instead of P2P tracker, P2P clients embeds ALTO client in themselves. They send requests and receive network/link cost information from/to ALTO server, and select peers from these information. Alternatively, each P2P client sends its own peer list to ALTO server. And next, ALTO server ranks what peers are good for the P2P client. In this method, ALTO server is highly loaded for ranking peers [draft-penno-alto-protocol]. This document describes the mechanism of using ALTO server and P2P clients as virtual P2P tracker. By this, the load of ALTO server and P2P clients is reduced. And this mechanism can use with ALTO protocol [draft-penno-alto-protocol] at the same time. 2. Virtual P2P Tracker Mechanism 2.1. P2P Client with ALTO Client According to use cases from [draft-penno-alto-protocol], if ALTO client is not embedded into P2P tracker, each P2P client manages network map and cost map, and its own list of other peers. The ALTO server has to provide network information to all peers that send ALTO queries. As the number of P2P clients is increased, ALTO server's scalability problem gets more significant. Ilkyun Park, et al. Expires April 18, 2010 [Page 3] Internet-Draft Virtual P2P Tracker October 2009 In other way, P2P clients just manage the list of peers along their own P2P protocol mechanisms like distributed hash table (DHT), or peer exchange (PEX). If the client wants to select the peers along its network information from ISP, it queries to an ALTO server with the list of peers. The ALTO server ranks to each peer in the list, and then returns to the client with the ranked peers list. This method does not require ISP's network information to every P2P client. But the ALTO server's processing overhead is increased for rank- calculation every time each P2P client sends its peer list. 2.2. PID Head To avoid the overhead of every P2P client, it is possible that some P2P clients are elected from each PID as PID Heads. The role of PID Head is to manage the network map and cost map of the PID instead of all P2P clients. These PID Heads act as P2P trackers that embeds ALTO client to other P2P clients of same PID. These PID Heads become `virtual P2P tracker'. In example, if a PID Head is the member of PID1, the PID Head manages the list of endpoints consisting of PID1 and its network map and cost map. If another P2P client queries PID1 to ALTO server, it forwards the query to the PID Head. Then the head answers back to the ALTO server. Finally, the response is forwarded to the P2P client. Otherwise, the query is other than PID1, it is forwarded to other ALTO servers or other PID Heads. 2.3. PID Head Election Issues related with PID Head is that who elects some P2P clients as PID Heads, and what conditions are required to be elected to PID Head. P2P clients of each PID can elect its own PID Header. Some super P2P clients can become PID Head. But to do this, all P2P clients of that PID must formerly know everything about other P2P clients. To collect the others' information, more signaling steps and more memory capacity is required for all P2P clients. To resolve this, ALTO server can elects PID Head for each PID. To simplify the decision policy, the ALTO server can elect first P2P client sending queries in targeted PID. Those are some of conditions to be elected as PID Head in example: O CPU clock speed (Hz) O memory footprint Ilkyun Park, et al. Expires April 18, 2010 [Page 4] Internet-Draft Virtual P2P Tracker October 2009 O max. continuous lifetime O distance between the node and ALTO server 3. Security Considerations High-level security considerations can be found in the [draft-ietf- alto-problem-statement]. 4. References 4.1. Informative References [draft-ietf-alto-problem-statement] J. Seedorf, and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", draft-ietf-alto-problem-statement-04, September 2009. [draft-ietf-alto-reqs] S. Kiesel, L. Popkin, S. Previdi, R. Woundy, and Y R. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", draft-ietf-alto-reqs-01, July 2009. [draft-penno-alto-protocol] R. Penno, and Y. Yang, "ALTO Protocol", draft-penno-alto-protocol-03, July 2009. Author's Addresses Ilkyun Park ETRI 1110-6 Oryong-dong, Buk-gu, Gwangju, 500-480, Republic of Korea Phone: +82-62-970-6651 Email: ikpark@etri.re.kr Byung-Tak Lee ETRI 1110-6 Oryong-dong, Buk-gu, Gwangju, 500-480, Republic of Korea Phone: +82-62-970-6624 Email: bytelee@etri.re.kr Ilkyun Park, et al. Expires April 18, 2010 [Page 5]