idnits 2.17.1 draft-ikpark-alto-virtual-p2ptracker-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2009) is 5296 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO Ilkyun Park 3 Internet Draft Byung-Tak Lee 4 Intended status: Informational ETRI 5 Expires: April 18, 2010 October 18, 2009 7 Virtual P2P Tracker for Full-Distributed P2P Applications 8 draft-ikpark-alto-virtual-p2ptracker-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 18, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document describes the virtual P2P tracker mechanism for ALTO 47 clients that are embedded in P2P clients, not P2P tracker. An ALTO 48 server does significant role that is collecting ISP's network 49 information, and responding ALTO clients' queries of ALTO guidance. 50 With this mechanism, ALTO server or P2P clients can reduce the load 51 for selection of the list of optimized peers even if any P2P tracker 52 isn't included in the P2P application. 54 Table of Contents 56 1. Introduction ................................................ 3 57 2. Virtual P2P Tracker Mechanism ............................... 3 58 2.1. P2P Client with ALTO Client ............................ 3 59 2.2. PID Head ............................................... 4 60 2.3. PID Head Election ...................................... 4 61 3. Security Considerations ..................................... 5 62 4. References .................................................. 5 63 4.1. Informative References ................................. 5 65 1. Introduction 67 As discussed in the ALTO problem statement [draft-ietf-alto-problem- 68 statement], traffic occurred by Peer-to-Peer (P2P) applications 69 occupies a large portion of network capacity in the Internet. P2P 70 application selects its peers regardless of underlying information of 71 network topology. As a result, P2P application traffic is easy to 72 cross among different ISPs' networks in multiple times. This 73 increases network load and reduces the performance of P2P 74 applications. 76 To resolve this problem, an ALTO server manages the network topology 77 information of one or more ISPs, and P2P trackers of P2P applications 78 use it for selecting lists of peers for the P2P clients that want to 79 select peers. By this, much of P2P traffic will be able to be 80 localized into fewer ISPs' networks. 82 But some P2P applications form full-distributed P2P architecture. 83 They manage peer lists with distributed information like distributed 84 hash tables (DHT) or peer exchange (PEX). In this case, instead of 85 P2P tracker, P2P clients embeds ALTO client in themselves. They send 86 requests and receive network/link cost information from/to ALTO 87 server, and select peers from these information. 89 Alternatively, each P2P client sends its own peer list to ALTO server. 90 And next, ALTO server ranks what peers are good for the P2P client. 91 In this method, ALTO server is highly loaded for ranking peers 92 [draft-penno-alto-protocol]. 94 This document describes the mechanism of using ALTO server and P2P 95 clients as virtual P2P tracker. By this, the load of ALTO server and 96 P2P clients is reduced. And this mechanism can use with ALTO protocol 97 [draft-penno-alto-protocol] at the same time. 99 2. Virtual P2P Tracker Mechanism 101 2.1. P2P Client with ALTO Client 103 According to use cases from [draft-penno-alto-protocol], if ALTO 104 client is not embedded into P2P tracker, each P2P client manages 105 network map and cost map, and its own list of other peers. The ALTO 106 server has to provide network information to all peers that send ALTO 107 queries. As the number of P2P clients is increased, ALTO server's 108 scalability problem gets more significant. 110 In other way, P2P clients just manage the list of peers along their 111 own P2P protocol mechanisms like distributed hash table (DHT), or 112 peer exchange (PEX). If the client wants to select the peers along 113 its network information from ISP, it queries to an ALTO server with 114 the list of peers. The ALTO server ranks to each peer in the list, 115 and then returns to the client with the ranked peers list. This 116 method does not require ISP's network information to every P2P client. 117 But the ALTO server's processing overhead is increased for rank- 118 calculation every time each P2P client sends its peer list. 120 2.2. PID Head 122 To avoid the overhead of every P2P client, it is possible that some 123 P2P clients are elected from each PID as PID Heads. The role of PID 124 Head is to manage the network map and cost map of the PID instead of 125 all P2P clients. These PID Heads act as P2P trackers that embeds ALTO 126 client to other P2P clients of same PID. These PID Heads become 127 `virtual P2P tracker'. 129 In example, if a PID Head is the member of PID1, the PID Head manages 130 the list of endpoints consisting of PID1 and its network map and cost 131 map. If another P2P client queries PID1 to ALTO server, it forwards 132 the query to the PID Head. Then the head answers back to the ALTO 133 server. Finally, the response is forwarded to the P2P client. 134 Otherwise, the query is other than PID1, it is forwarded to other 135 ALTO servers or other PID Heads. 137 2.3. PID Head Election 139 Issues related with PID Head is that who elects some P2P clients as 140 PID Heads, and what conditions are required to be elected to PID Head. 142 P2P clients of each PID can elect its own PID Header. Some super P2P 143 clients can become PID Head. But to do this, all P2P clients of that 144 PID must formerly know everything about other P2P clients. To collect 145 the others' information, more signaling steps and more memory 146 capacity is required for all P2P clients. 148 To resolve this, ALTO server can elects PID Head for each PID. To 149 simplify the decision policy, the ALTO server can elect first P2P 150 client sending queries in targeted PID. 152 Those are some of conditions to be elected as PID Head in example: 154 O CPU clock speed (Hz) 156 O memory footprint 157 O max. continuous lifetime 159 O distance between the node and ALTO server 161 3. Security Considerations 163 High-level security considerations can be found in the [draft-ietf- 164 alto-problem-statement]. 166 4. References 168 4.1. Informative References 170 [draft-ietf-alto-problem-statement] J. Seedorf, and E. Burger, 171 "Application-Layer Traffic Optimization (ALTO) Problem 172 Statement", draft-ietf-alto-problem-statement-04, September 173 2009. 175 [draft-ietf-alto-reqs] S. Kiesel, L. Popkin, S. Previdi, R. Woundy, 176 and Y R. Yang, "Application-Layer Traffic Optimization 177 (ALTO) Requirements", draft-ietf-alto-reqs-01, July 2009. 179 [draft-penno-alto-protocol] R. Penno, and Y. Yang, "ALTO Protocol", 180 draft-penno-alto-protocol-03, July 2009. 182 Author's Addresses 184 Ilkyun Park 185 ETRI 186 1110-6 Oryong-dong, Buk-gu, Gwangju, 500-480, 187 Republic of Korea 188 Phone: +82-62-970-6651 189 Email: ikpark@etri.re.kr 191 Byung-Tak Lee 192 ETRI 193 1110-6 Oryong-dong, Buk-gu, Gwangju, 500-480, 194 Republic of Korea 195 Phone: +82-62-970-6624 196 Email: bytelee@etri.re.kr