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]