ALTO Y. Wang, Ed. Internet-Draft H. Song, Ed. Intended status: Standards Track M. Chen Expires: April 19, 2010 Huawei October 16, 2009 ALTO protocol extension: aggregate network map and cost map into CPID draft-wang-alto-cpid-00 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 19, 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. Abstract The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one or several Wang, et al. Expires April 19, 2010 [Page 1] Internet-Draft ALTO protocol extension October 2009 hosts from a set of candidates, which are able to provide the desired resource. Until now the members in ALTO group propose many solutions, such as P4P and PROXIDOR. The goal of the protocol specified in this document is to try to extend the existing solutions to improve the performance of protocol and better satisfy the privacy requirements. The proposed protocol is based on the P4P or merged protocol. It introduces a way to transfer the guidance or costs using Network Location identifiers/PIDs (we called it CPID) directly. This solution can inherit the existing solution's architecture, messages, and other mechanisms. It can be an independent solution and also be a function together with other functions in the existing solution to provide the guidance for different client and balance the workload on the server. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 3 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Network Map and Path Rating in CPID . . . . . . . . . . . 5 3.1.1. Cost type and cost mode . . . . . . . . . . . . . . . 5 3.1.2. CPID Type . . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. Capabilities Query . . . . . . . . . . . . . . . . . . 6 4.1.2. Guidance . . . . . . . . . . . . . . . . . . . . . . . 7 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. ALTO Client Embedded in P2P Tracker . . . . . . . . . . . 7 5.2. ALTO Client Embedded in P2P Client . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Wang, et al. Expires April 19, 2010 [Page 2] Internet-Draft ALTO protocol extension October 2009 1. Introduction Many Internet applications, including the widely used overlay applications like peer-to-peer file sharing and video streaming, need to access the resources which are available in several equivalent replicas on different hosts, such as pieces of information or server processes. The goal of Application-Layer Traffic Optimization (ALTO) [I-D.ietf-alto-problem-statement] is to provide guidance to the applications, which have to select one or several hosts from a set of candidates, which are able to provide the desired resource. Until now the members in ALTO working group have proposed many solutions, such as P4P [I-D.wang-alto-p4p-specification] and PROXIDOR [I-D.akonjang-alto-proxidor]. The goal of the protocol specified in this document is to improve the protocol performance and to better satisfy the privacy requirements by extending the existing solutions. The proposed protocol is based on the P4P or merged protocol [I-D.penno-alto-protocol]. It introduces a way to transfer the guidance or costs using Network Location identifiers/PIDs directly. This solution can inherit the existing solutions' architecture, messages, and other mechanisms. It can be an independent solution or a function used together with other functions in the existing solution to provide the guidance for different clients and balance the workload on the server. It can also reduce the risk regarding to the privacy issue, especially for P2P application. This document is a work in progress and will be updated with further developments. 2. Terminology and Concepts The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document also reuses the concepts defined in [I-D.ietf-alto-problem-statement] and [I-D.ietf-alto-reqs]. 3. Architecture The protocol proposed in this draft can be considered as an extension of P4P or a complementary of a merged solution, and therefore, it can inherit existing architecture in the draft [I-D.penno-alto-protocol]. Wang, et al. Expires April 19, 2010 [Page 3] Internet-Draft ALTO protocol extension October 2009 +-------------------------------------------------------------------+ | ISP | | +-----------+ | | | Routing | | | +--------------+ | Protocols | | | | Provisioning | +-----------+ | | | Policy | | | | +--------------+\ | | | \ | | | +-----------+ \+---------+ +--------+ | | |Dynamic | | ALTO | ALTO Protocol | ALTO | | | |Network |.......| Server | -------------------- | Client | | | |Information| +---------+ +--------+ | | +-----------+ / / | | / ALTO SD Query/Response / | | +----------+ +--------------+ | | | External | | ALTO Service | | | | Interface| | Discovery | | | +----------+ +--------------+ | | | | +-------------------------------------------------------------------+ | +------------------+ | Third Parties | | | | Content Providers| +------------------+ Figure 1 ALTO Architecture Figure 1 declared in draft [6] shows the overall system architecture. This draft is also consistent with this architecture. In this architecture, an ALTO Client uses ALTO Service Discovery to identify an appropriate ALTO Server; an ALTO Server prepares ALTO Information; and the ALTO Client requests available ALTO Information from the ALTO Server using the ALTO Protocol. In our proposed ALTO protocol, the ALTO guidance messages are simplified to cost-peer-identifiers (CPID) request/response only. ALTO Information from the ALTO Server is abstracted and dispersed to each potential peer. When ALTO clients get the CPIDs, they also obtain the ALTO guidance regarding to those peers at the same time. Therefore, the requests and workload could be reduced lot, and the privacy risk could also be alleviated on the P2P side. Wang, et al. Expires April 19, 2010 [Page 4] Internet-Draft ALTO protocol extension October 2009 3.1. Network Map and Path Rating in CPID In the merged solutions [I-D.penno-alto-protocol], the Network Map and the cost Map are two separated part, although the cost map is based on the Network Map and it reflects the relationships of the elements in the network map. If clients want to get ALTO guidance, they first need to get the PIDs of candidate peers in the network map, and then gained path rating using the obtained PIDs. In our proposed solution, the Network Map and the cost Map are melted into one map. The element in this map can act as new type of PID. As the same as the original PID in the network map, this new type PID, which we called CPID, provides an implicit way to specify a network aggregation. Besides, it can also reflect the costs/weights between peers indirectly. Assume that CPID1 is the CPID of peer1, and CPID2 is the CPID of peer2, then cost between these two peers could be represented as the following equation. COST(peer1, peer2) = FUNC(CPID1, CPID2) Here, the cost FUNC can be a simple multiplication, a cross- production or any formula that the ISP defined. After getting CPIDs of two peers, through this simple function ALTO client can easily obtain the cost between these two peers, thus achieve path rating. 3.1.1. Cost type and cost mode Both cost type and cost mode can use existing mechanisms. The cost Type attribute indicates what the cost represents. For example, an ALTO Server could define costs representing air-miles, hop-counts, or generic routing costs. The Mode attribute indicates how costs should be interpreted. For example, the cost can be interpreted as numerical values or ordinal rankings. Note that the type of CPID is independent of cost type and cost mode. The cost between two peers is calculated by the cost function with the two CPIDs as inputs, whatever the type of CPID is. 3.1.2. CPID Type A CPID could be a simple binary code, a coordinates, or any other types defined freely. The type is decided by the method of CPID construction. The CPID construction method also decides the cost FUNC. The details of the construction method are not inside the scope of this draft. ISP may internally construct CPID using any method it chooses. A single CPID to a peer ostensibly is only an identifier no matter the type it chooses. When the CPIDs of the source peer and destination peers have been obtained, ALTO client could calculate the costs for better peer selection. Wang, et al. Expires April 19, 2010 [Page 5] Internet-Draft ALTO protocol extension October 2009 4. Protocol Overview The first step for a P2P application to use ALTO guidance is to discover one or more corresponding ALTO servers. ALTO Services and Servers are discovered through some certain mechanisms such as DNS, DHCP [I-D.song-alto-server-discovery]. After finding the correct ALTO server, ALTO client needs to know what the ALTO server could provide to assist its peer selection. By negotiation, ALTO Client will get a configuration file from a particular ALTO Server. The configuration file includes, for example, details about the type of CPID, cost FUNC, and cost metrics supported by the ALTO Server. Then, ALTO Client starts ALTO guidance requesting. In this protocol, the guidance for peer selection is derived through CPID of Endpoints. ALTO Client sends a Query to ALTO server for requesting CPID(s) of one or a set of Host Location Attributes (HLAs, [1]) of peers. ALTO Server considers the request and should reply with the corresponding CPID(s). When a P2P tracker acts as an ALTO client, it could retrieve the CPID for a peer when it joins and stores it locally for later use. If a P2P client requests for candidate source providers, P2P tracker will gather destination candidates and get the CPIDs of source and destination candidates locally. Then, P2P tracker calculates the costs of source and destination pairs by using cost FUNC with their CPIDs as the inputs. Finally, P2P tracker could determine the candidates to select according to the sorted costs. When a P2P client acts as an ALTO client, it could retrieve the CPID for itself and stores it locally for later use. P2P Applications could adopt CPID as an attribute of the application. The CPID could take part in the process of peer selection. When P2P client does resource discovery, it also gathers their CPIDs at the same time, e.g. the DHT will tell the requester the CPIDs of destination peers. Then P2P client could calculate and compare the costs, and determine the candidates to select finally. Note that the CPID should have a part to distinguish the ISP it belongs to. For the CPIDs in the same ISP, P2P client/trackers could directly calculate the cost of the path between the source peer and the destination peer. If the candidate peers in the same ISP are not enough, P2P client/tracker could use the ways in other drafts [I-D.penno-alto-protocol] for guidance requesting, or directly use an ISP priority map for crossed ISP peer selection. 4.1. Messages 4.1.1. Capabilities Query For seeking guidance in Resource Provider selection, an ALTO Client sends a Capability query to one or more ALTO Servers to discover which rating criteria are supported and at which accuracy level. Through some certain mechanisms such as DNS, DHCP Wang, et al. Expires April 19, 2010 [Page 6] Internet-Draft ALTO protocol extension October 2009 [I-D.song-alto-server-discovery], ALTO Services and Servers could be discovered. The capability query and response could be the same as other ALTO protocols. Through the queries and responses between servers and clients, ALTO server and client could negotiate about the PID type and cost FUNC for generating the cost from CPIDs, and may also about which rating criteria and which accuracy level for the ALTO server to adopt to provide CPID to ALTO client. 4.1.2. Guidance In this solution, the guidance for peer selection is through CPID of Endpoints. In draft [6], the Endpoint Property Lookup query allows an ALTO Client to query for the properties of Endpoints known to the ALTO Server. CPID is also a type of PID, so we can reuse the Endpoint Property Lookup query to retrieve the CPID of each endpoint. An ALTO Client sends an Endpoint Property Lookup query to an ALTO Server to request the guidance for peer selection. When a P2P tracker acts as an ALTO client, the query may include one or a set of HLAs of peers. This HLA represents new joint peer or the peer whose CPID need to be update. When a P2P client acts as an ALTO client, the query may include HLA itself or set null only. The response from ALTO server should provide a CPID for each peer in the associated query. ALTO Client will store the CPID(s) locally for later use, and may also maintains a back-end database that updates at pre-determined intervals or sudden changes. A Server may contain the used response cost FUNC in order to further assist the client to generate the cost for peer selection. It also could be retrieved in other ways. For example, the returned documents including cost FUNC can be downloaded by ALTO Clients or provisioned into devices. 5. Use Cases 5.1. ALTO Client Embedded in P2P Tracker A P2P tracker could handle a large number of clients. When a P2P tracker acts as an ALTO client to enable more network-efficient traffic patterns and improve application performance, the P2P tracker should request the ALTO information (CPIDs) for peers. Wang, et al. Expires April 19, 2010 [Page 7] Internet-Draft ALTO protocol extension October 2009 .---------. .---------------. | | (1) Get CPID(s) | P2P Tracker | | ALTO | <----------------------> | (ALTO Client) | | Server | | (3) | | | | Ranking | `---------' `---------------' ^ | (2) Get Peers | | (4) Selected Peer | v List .---------. .-----------. | Peer 1 | <-------------- | P2P | `---------' | Client | . (5) Connect to `-----------' . Selected Peers / .---------. / | Peer 50 | <------------------ `---------' Figure 2 ALTO Client Embedded in P2P Tracker Figure 2 shows an example that a P2P tracker as an ALTO Client uses ALTO information for peer selection. The example process is shown as follows: 1. When A P2P Client joins the swarm or need to be update, the P2P Tracker requests and obtains its CPID and then stores it locally. The P2P Tracker could collect new joint peers or the peers need to be updated together for CPID requesting. 2. A P2P Client requests a peer list from the P2P Tracker. 3. The P2P Tracker gathers destination candidates and gets the CPIDs of source and destination candidates locally. In case of sufficient candidate peers in the same ISP, the P2P Tracker then runs the COST- CALCULATE function to rank the candidate peers using their CPID. If not, P2P tracker could use the ways in other drafts [I-D.penno-alto-protocol] for guidance requesting, or directly use an ISP priority map for crossed ISP peer selection. 4. The P2P Tracker returns the selected peer list to P2P client. 5. The P2P Client connects to the selected peers. 5.2. ALTO Client Embedded in P2P Client P2P clients may also utilize ALTO information themselves for better peer selection. When a P2P Client works as an ALTO client, it typically queries only the ALTO Server that belongs to its own ISP for its own CPID. P2P Applications could adopt CPID as an attribute Wang, et al. Expires April 19, 2010 [Page 8] Internet-Draft ALTO protocol extension October 2009 of the application. This CPID could take part in the process of peer selection, such as resource discovery. When P2P client discovers the candidate peers, it also gathers their CPIDs at the same time. .---------. (1) Get CPIDs .---------------. | | | P2P Client | | ALTO | <----------------------> | (ALTO Client) | | Server | | (3) | | | | | .---------. `---------' `---------------' <- | P2P | .---------. / | ^ ^ | Tracker | | Peer 1 | <-------------- | | \ `---------' `---------' |(2) Gather Peers with CPIDs . (4) Select Peers | | \ . and Connect / .--------. .--------. .---------. / | P2P | | DHT | | Peer 50 | <---------------- | Client | `--------' `---------' | (PEX) | `--------' Figure 3: ALTO Client Embedded in P2P Client Figure 3 shows an example use the case that a P2P client as an ALTO Client uses ALTO information for peer selection. The example process is shown as follows: 1. The P2P Client requests and gets it own CPID from its ALTO Server and then stores it locally 2. The P2P Client discovers peers together with their CPIDs from sources such as Peer Exchange (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and P2P Trackers. 3. In case of sufficient candidate peers in the same ISP, the P2P client then runs the COST-CALCULATE function to rank the candidate peers using their CPID and determines the peers to be select according to the rank. If not, P2P client could use the ways in other drafts [I-D.penno-alto-protocol] for guidance requesting, or directly use an ISP priority map for crossed ISP peer selection. 4. The P2P Client connects to the selected peers. 6. Security Considerations An ALTO Server may optionally use authentication and encryption to protect ALTO information for preventing the information being disclosed on the path. This will be further discussed in other documents. Wang, et al. Expires April 19, 2010 [Page 9] Internet-Draft ALTO protocol extension October 2009 7. IANA Considerations IANA may need to assign numbers to distinguish different ISPs with this solution. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.ietf-alto-problem-statement] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", draft-ietf-alto-problem-statement-04 (work in progress), September 2009. [I-D.ietf-alto-reqs] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", draft-ietf-alto-reqs-01 (work in progress), July 2009. [I-D.akonjang-alto-proxidor] Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. Saucez, "The PROXIDOR Service", draft-akonjang-alto-proxidor-00 (work in progress), March 2009. [I-D.wang-alto-p4p-specification] Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, "P4P Protocol Specification", draft-wang-alto-p4p-specification-00 (work in progress), March 2009. [I-D.penno-alto-protocol] Penno, R. and Y. Yang, "ALTO Protocol", draft-penno-alto-protocol-03 (work in progress), July 2009. [I-D.song-alto-server-discovery] Song, H., Tomsu, M., Garcia, G., Wang, Y., and V. Pascual, "ALTO Service Discovery", draft-song-alto-server-discovery-01 (work in progress), Wang, et al. Expires April 19, 2010 [Page 10] Internet-Draft ALTO protocol extension October 2009 July 2009. Appendix A. Examples To reflect the relationships of peer pairs exactly, we can use an n-dim vector to represent the CPID. The basic idea is that each node (can be a peer or an aggregated peer group) in an n-dimension hyperplane constructed by n nodes can be represented by an n-dimension coordinate at least. We already have all the distance/ cost values between pair of nodes. Thus, we can formulae an n*n dimension weight matrix W, where ELEMENTij means the weight value from node i to node j. Presumably, ELEMENTij in the weight matrix W can be considered as the inner product of node i and node j. Thus, we can find an n-dimension vector X to represent each node through matrix decomposition W= C*C^T. Assuming that we have n nodes needed to be assigned CPID and we have obtained the weights of all node pairs, we can formulate a weight matrix W as shown in Figure 4. The row suffix i and the column suffix j of each element Wij represent the source and destination of a path with the weight value or priority value Wij. The priority value can be an ordinary number from 1 to n or other weighted number according to the sorting of weight value for the same source node i. The diagonal elements which mean the source node and the destination node are the same have the highest weight or priority, if the highest weight or priority means the nearest or lowest cost. N1 N2 ... Nn / \ N1 | W11 W12 ... W1n | | | N2 | W21 W22 ... W2n | . | ... ... ... ... | . | ... ... ... ... | Nn | Wn1 Wn2 ... Wnn | \ / Figure 4. Matrix of weight/priority There are many ways to obtain a matrix C satisfying W= C*C^T. The simplest way is Cholesky decomposition. Cholesky decomposition is a decomposition of a symmetric, positive-definite matrix into a lower triangular matrix and the transpose of the lower triangular matrix. The necessary condition for applying Cholesky decomposition is that the matrix W is symmetric and positive definite. Assuming that the weights of two directions between two nodes are the same and the Wang, et al. Expires April 19, 2010 [Page 11] Internet-Draft ALTO protocol extension October 2009 weight in same node is high enough, these conditions can be satisfied. Then we can easily apply Cholesky decomposition on W, as shown in Equation. 1. The i-th row of matrix C is the coordinates of node i as the CPID. / \ | W11 W12 ... W1n | | | W= | W21 W22 ... W2n | | ... ... ... ... | | ... ... ... ... | | Wn1 Wn2 ... Wnn | \ / / \ / \ T | C11 C12 ... C1n | | C11 C12 ... C1n | | | | | T = | C21 C22 ... C2n | * | C21 C22 ... C2n | = C * C | ... ... ... ... | | ... ... ... ... | | ... ... ... ... | | ... ... ... ... | | Cn1 Cn2 ... Cnn | | Cn1 Cn2 ... Cnn | \ / \ / Equation. 1 When selecting peers in the same ISP for peer A, what we need to do is only calculating the inner products of CPIDs of peer A and other peers. And then sort the inner products and choose peers with high inner product values. However, a problem of these above methods is the assumption that the weights from node i to j and from j to i should be same. Although it is the true in most cases, we still want to control or distinguish the weight Wij and Wji . The basic idea is to separate the coordinates of node to two parts. For node i, part of coordinate is the identifier Csoui as source, and the other is the identifier Cdesi as destination. Therefore, Wij = Csoui * Cdesj^T is different from Wji = Csouj * Cdesi^T . Similarly, what we want here is not a coordinate matrix C but a source coordinate matrix Csou and a destination matrix Cdes. And the coordinate of node i is the combination of the i-th row of Csou and the i-th row of Cdes . There are lots of matrix decomposition methods for finding Csou and Cdes satisfying W= Csou * Cdes^T such as LU, QR, Singular value decomposition (SVD). LU decomposition is a matrix decomposition which writes a matrix as the product of a lower triangular matrix and an upper triangular matrix. Cholesky decomposition is a special case of the symmetric LU decomposition, with L = U^T. Here we adopt SVD which is more efficiency and easier to extend. SVD is an important Wang, et al. Expires April 19, 2010 [Page 12] Internet-Draft ALTO protocol extension October 2009 factorization of a rectangular real or complex matrix, with several applications in signal processing and statistics. Through applying SVD on W, we could obtain an equation W=U*S*V^T , where U is an n-by-n unitary matrix, S is an n-by-n diagonal matrix with nonnegative real numbers on the diagonal, and V^T , an n-by-n unitary matrix, denotes the conjugate transpose of V,. Usually the diagonal entries Si,i are ordered in non-increasing fashion. In this case, the diagonal matrix S is uniquely determined by W (though the matrices U and V are not). The diagonal entries of S are known as the singular values of W. Through matrix transformation (choose freely) we could get the Csou and Cdes as shown in Equation. 2. Wang, et al. Expires April 19, 2010 [Page 13] Internet-Draft ALTO protocol extension October 2009 / \ | W11 W12 ... W1n | | | W= | W21 W22 ... W2n | | ... ... ... ... | | ... ... ... ... | | Wn1 Wn2 ... Wnn | \ / / \ / \ / \ T | U11 U12 ... U1n | | S11 0 ... 0 | | V11 V12 ... V1n | | | | | | | = | U21 U22 ... U2n | * | 0 S22 ... 0 | * | V21 V22 ... V2n | | ... ... ... ... | | ... ... ... ... | | ... ... ... ... | | ... ... ... ... | | ... ... ... ... | | ... ... ... ... | | Un1 Un2 ... Unn | | 0 0 ... Snn | | Vn1 Vn2 ... Vnn | \ / \ / \ / / \ / \ T | U11 U12 ... U1n | | V11*S11 V12*S22 ... V1n*Snn | | | | | | U21 U22 ... U2n | * | V21*S11 V22*S22 ... V2n*Snn | = | ... ... ... ... | | ... ... ... ... | | ... ... ... ... | | ... ... ... ... | | Un1 Un2 ... Unn | | Vn1*S11 Vn2*S22 ... Vnn*Snn | \ / \ / / \ / \ T | Csou11 Csou12 ... Csou1n| | Cdes11 Cdes12 ... Cdes1n| | | | | = | Csou21 Csou22 ... Csou2n| * | Cdes21 Cdes22 ... Cdes2n| | ... ... ... ... | | ... ... ... ... | | ... ... ... ... | | ... ... ... ... | | Csoun1 Csoun2 ... Csounn| | Cdesn1 Cdesn2 ... Cdesnn| \ / \ / T = Csou * Cdes Equation. 2 This multi-dimension CPID can be also performed in a hierarchical construction manner. We obtain the Csou and Cdes matrixes from weight or priority matrix of each level, and combine the ID of each level as the final representation. Noticed that if we want calculate the inner product of combined IDs directly, the weights or priorities in the high level should be larger enough than the low level to distinct different levels. Wang, et al. Expires April 19, 2010 [Page 14] Internet-Draft ALTO protocol extension October 2009 When peer A wants to select peers, it can send request only using the source part of CPID. The P2P tracker calculates the inner products of the source part of peer A's CPID with the destination part of CPIDs of other candidate peers in the same ISP. And then sort the inner products and choose the peers with high inner product values. It is an easy way to keep the secrecy. Representing CPID with large dimensional data may be inconvenient and lead to low efficiency in message transmission and priority calculation, since the number of nodes needed to be assigned to an CPID is too big. At the same time, there is much redundant information in the weight matrix or n-dimension coordinates, since the network design usually follows some strategies and rules to some extent. Moreover, the consistency between different groups of nodes needs to be guaranteed. Therefore, a more efficient peer representation can be found. A common way is to reduce the dimensionality to an appropriate number. There are several methods for dimension reduction, including principal components analysis (PCA), projection pursuit, principal curves, self-organizing maps, as well as provides neural network implementations of some of the reviewed statistical models. We can use PCA for the dimension reduction because PCA allows each node's coordinate values to be represented by a set of uncorrelated low dimensional parameters and can minimize reconstruction error optimally under the L2 norm. In our case, we can apply the PCA to process the weight matrix decomposition directly, which can minimize the reconstruction error of weight matrix than applying PCA to coordinate matrix. By choosing the first r (r <