idnits 2.17.1 draft-wang-alto-cpid-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 12, 2010) is 5029 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 236 -- Looks like a reference, but probably isn't: '6' on line 282 == Unused Reference: 'I-D.akonjang-alto-proxidor' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'I-D.wang-alto-p4p-specification' is defined on line 440, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-alto-reqs-05 == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-04 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO H. Song 3 Internet-Draft M. Chen 4 Intended status: Standards Track Huawei 5 Expires: January 13, 2011 Y. Wang 6 Unknown 7 D. Bryan 8 Cogent Force, LLC / Huawei 9 July 12, 2010 11 An Aggregate Network and Cost Map (CPID) Extension for the ALTO Protocol 12 draft-wang-alto-cpid-01 14 Abstract 16 The goal of the Application-Layer Traffic Optimization (ALTO) 17 protocol is to provide guidance to applications which have to select 18 one or several hosts from a set of candidates, all of which are able 19 to provide the desired resource. The goal of the mechanisms 20 specified in this document is to extend the existing solution, and 21 provide basic attributes to each end terminal to make it network- 22 aware. These mechanisms introduce a way to directly transfer the 23 guidance or costs using Network Location identifiers/PIDs, called 24 CPIDs. And the exisiting The proposed solution inherits the existing 25 solution's architecture, messages, and other mechanisms. It can be 26 used as an independent solution or function together with other 27 functions in the existing solution to provide guidance for different 28 client and balance the workload on the server. Additional details 29 for the process will be provided in the next version of the draft. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 13, 2011. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 3 66 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. CPID Defined . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1.1. What is a CPID? . . . . . . . . . . . . . . . . . . . 5 69 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 70 4.1. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.1.1. Capabilities Query . . . . . . . . . . . . . . . . . . 7 72 4.1.2. Guidance . . . . . . . . . . . . . . . . . . . . . . . 7 73 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 5.1. ALTO Client Embedded in P2P Tracker . . . . . . . . . . . 8 75 5.2. ALTO Client Embedded in P2P Client . . . . . . . . . . . . 9 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 81 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 84 1. Introduction 86 Many Internet applications, including widely used overlay 87 applications for peer-to-peer file sharing and video streaming, need 88 to access resources available in several equivalent replicas on 89 different hosts, for example pieces of information or server 90 processes. The goal of Application-Layer Traffic Optimization (ALTO) 91 [I-D.ietf-alto-problem-statement] is to provide guidance to the 92 applications, which have to select one or several hosts from a set of 93 candidates able to provide the desired resource. 95 Participants have proposed a number of solutions to the ALTO WG, 96 which have been merged to produce [I-D.ietf-alto-protocol]. The goal 97 of the mechanisms specified in this document is to extend the 98 existing solution to improve the performance of the protocol and 99 better satisfy the privacy requirements. These mechanisms introduce 100 a way to directly transfer the guidance or costs using Network 101 Location identifiers/PIDs, called CPIDs. The proposed solution 102 inherits the existing solution's architecture, messages, and other 103 mechanisms. It can be used as an independent solution or function 104 together with other functions in the existing solution to provide 105 guidance for different client and balance the workload on the server. 106 It can also reduce the risk regarding to the privacy issue, 107 especially for P2P applications. This document is a work in progress 108 and will be updated in the future. 110 2. Terminology and Concepts 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 This document also reuses the concepts defined in 117 [I-D.ietf-alto-problem-statement] and [I-D.ietf-alto-reqs]. 119 3. Overview 121 The protocol proposed in this draft can be considered as an extension 122 of or a complementary to the merged ALTO protocol, and inherits 123 existing architecture from the draft [I-D.ietf-alto-protocol]. 125 +-------------------------------------------------------------------+ 126 | ISP | 127 | | 128 | +-----------+ | 129 | | Routing | | 130 | +--------------+ | Protocols | | 131 | | Provisioning | +-----------+ | 132 | | Policy | | | 133 | +--------------+\ | | 134 | \ | | 135 | \ | | 136 | +-----------+ \+---------+ +--------+ | 137 | |Dynamic | | ALTO | ALTO Protocol | ALTO | | 138 | |Network |.......| Server | -------------------- | Client | | 139 | |Information| +---------+ +--------+ | 140 | +-----------+ / / | 141 | / ALTO SD Query/Response / | 142 | / / | 143 | +----------+ +--------------+ | 144 | | External | | ALTO Service | | 145 | | Interface| | Discovery | | 146 | +----------+ +--------------+ | 147 | | | 148 | | Figure 1: Basic ALTO Architecture. | 149 | | | 150 +-------------------------------------------------------------------+ 151 | 152 +------------------+ 153 | Third Parties | 154 | | 155 | Content Providers| 156 +------------------+ 158 ALTO Architecture 160 Figure 1 (extracted from [I-D.ietf-alto-protocol]) shows the overall 161 system architecture of the ALTO protocol. This draft is also 162 consistent with this architecture. In this architecture, an ALTO 163 Client uses ALTO Service Discovery to identify an appropriate ALTO 164 Server; an ALTO Server prepares ALTO Information; and the ALTO Client 165 requests available ALTO Information from the ALTO Server using the 166 ALTO Protocol. 168 In our proposed ALTO protocol, the ALTO guidance messages are 169 simplified to cost-peer-identifiers (CPID) request/response only. 170 ALTO Information from the ALTO Server is abstracted and dispersed to 171 each potential peer. When ALTO clients get the CPIDs, they also 172 obtain the ALTO guidance regarding those peers at the same time. As 173 a result, requests and server workload, as well as privacy risks, are 174 significantly reduced. 176 3.1. CPID Defined 178 3.1.1. What is a CPID? 180 In [I-D.ietf-alto-protocol], the Network Map and the Cost Map are two 181 separate data objects, even though the Cost Map is based on and 182 reflects the realtionship between the elements of the Network Map. If 183 clients want to get ALTO guidance, they obtain both the the PIDs of 184 candidate peers in the Network Map, as well as path ratings using the 185 obtained PIDs. In our proposed extension, the Network Map and the 186 Cost Map are combined into one map. The elements in this map act as 187 new type of PID. As with the original PID in the network map, this 188 new PID type, which we called CPID, provides an implicit way to 189 specify a network aggregation. CPIDs reflect the costs/weights 190 between peers indirectly. Assuming that CPID1 is the CPID of peer1, 191 and CPID2 is the CPID of peer2, then cost between these two peers 192 could be represented as the following equation. 194 COST(peer1, peer2) = FUNC(CPID1, CPID2) 196 Here, the cost FUNC can be a simple multiplication, a cross- 197 production or any formula that the ISP [QUESTION:should this be ISP, 198 or ALTO server?] defines. After getting CPIDs of two peers, through 199 this simple function ALTO clients can easily obtain the cost between 200 these two peers for use as a path rating. 202 Both cost type and cost mode can use existing mechanisms. The cost 203 Type attribute indicates what the cost represents. For example, an 204 ALTO Server could define costs representing air-miles, hop-counts, or 205 generic routing costs. The Mode attribute indicates how costs should 206 be interpreted. For example, the cost can be interpreted as 207 numerical values or ordinal rankings. Note that the type of CPID is 208 independent of cost type and cost mode. The cost between two peers 209 is calculated by the cost function with the two CPIDs as inputs, 210 whatever the type of CPID is. 212 A CPID could be a simple binary code, a coordinates, or any other 213 types defined freely. The type is decided by the method of CPID 214 construction. The CPID construction method also decides the cost 215 FUNC. The details of the construction method are not inside the 216 scope of this draft. ISP may internally construct CPID using any 217 method it chooses. A single CPID to a peer ostensibly is only an 218 identifier no matter the type it chooses. When the CPIDs of the 219 source peer and destination peers have been obtained, ALTO client 220 could calculate the costs for better peer selection. 222 4. Protocol Overview 224 The first step for a P2P application to use ALTO guidance is to 225 discover one or more corresponding ALTO servers. ALTO Services and 226 Servers are discovered through some certain mechanisms such as DNS, 227 DHCP [I-D.song-alto-server-discovery]. After finding the correct 228 ALTO server, ALTO client needs to know what the ALTO server could 229 provide to assist its peer selection. By negotiation, ALTO Client 230 will get a configuration file from a particular ALTO Server. The 231 configuration file includes, for example, details about the type of 232 CPID, cost FUNC, and cost metrics supported by the ALTO Server. 233 Then, ALTO Client starts ALTO guidance requesting. In this protocol, 234 the guidance for peer selection is derived through CPID of Endpoints. 235 ALTO Client sends a Query to ALTO server for requesting CPID(s) of 236 one or a set of Host Location Attributes (HLAs, [1]) of peers. ALTO 237 Server considers the request and should reply with the corresponding 238 CPID(s). When a P2P tracker acts as an ALTO client, it could 239 retrieve the CPID for a peer when it joins and stores it locally for 240 later use. If a P2P client requests for candidate source providers, 241 P2P tracker will gather destination candidates and get the CPIDs of 242 source and destination candidates locally. Then, P2P tracker 243 calculates the costs of source and destination pairs by using cost 244 FUNC with their CPIDs as the inputs. Finally, P2P tracker could 245 determine the candidates to select according to the sorted costs. 246 When a P2P client acts as an ALTO client, it could retrieve the CPID 247 for itself and stores it locally for later use. P2P Applications 248 could adopt CPID as an attribute of the application. The CPID could 249 take part in the process of peer selection. When P2P client does 250 resource discovery, it also gathers their CPIDs at the same time, 251 e.g. the DHT will tell the requester the CPIDs of destination peers. 252 Then P2P client could calculate and compare the costs, and determine 253 the candidates to select finally. Note that the CPID should have a 254 part to distinguish the ISP it belongs to. For the CPIDs in the same 255 ISP, P2P client/trackers could directly calculate the cost of the 256 path between the source peer and the destination peer. If the 257 candidate peers in the same ISP are not enough, P2P client/tracker 258 could use the ways in other drafts [I-D.ietf-alto-protocol] for 259 guidance requesting, or directly use an ISP priority map for crossed 260 ISP peer selection. 262 4.1. Messages 263 4.1.1. Capabilities Query 265 For seeking guidance in Resource Provider selection, an ALTO Client 266 sends a Capability query to one or more ALTO Servers to discover 267 which rating criteria are supported and at which accuracy level. 268 Through some certain mechanisms such as DNS, DHCP 269 [I-D.song-alto-server-discovery], ALTO Services and Servers could be 270 discovered. 272 The capability query and response could be the same as other ALTO 273 protocols. Through the queries and responses between servers and 274 clients, ALTO server and client could negotiate about the PID type 275 and cost FUNC for generating the cost from CPIDs, and may also about 276 which rating criteria and which accuracy level for the ALTO server to 277 adopt to provide CPID to ALTO client. 279 4.1.2. Guidance 281 In this solution, the guidance for peer selection is through CPID of 282 Endpoints. In draft [6], the Endpoint Property Lookup query allows 283 an ALTO Client to query for the properties of Endpoints known to the 284 ALTO Server. CPID is also a type of PID, so we can reuse the 285 Endpoint Property Lookup query to retrieve the CPID of each endpoint. 287 An ALTO Client sends an Endpoint Property Lookup query to an ALTO 288 Server to request the guidance for peer selection. When a P2P 289 tracker acts as an ALTO client, the query may include one or a set of 290 HLAs of peers. This HLA represents new joint peer or the peer whose 291 CPID need to be update. When a P2P client acts as an ALTO client, 292 the query may include HLA itself or set null only. 294 The response from ALTO server should provide a CPID for each peer in 295 the associated query. ALTO Client will store the CPID(s) locally for 296 later use, and may also maintains a back-end database that updates at 297 pre-determined intervals or sudden changes. 299 A Server may contain the used response cost FUNC in order to further 300 assist the client to generate the cost for peer selection. It also 301 could be retrieved in other ways. For example, the returned 302 documents including cost FUNC can be downloaded by ALTO Clients or 303 provisioned into devices. 305 5. Use Cases 306 5.1. ALTO Client Embedded in P2P Tracker 308 A P2P tracker could handle a large number of clients. When a P2P 309 tracker acts as an ALTO client to enable more network-efficient 310 traffic patterns and improve application performance, the P2P tracker 311 should request the ALTO information (CPIDs) for peers. 312 .---------. .---------------. 313 | | (1) Get CPID(s) | P2P Tracker | 314 | ALTO | <----------------------> | (ALTO Client) | 315 | Server | | (3) | 316 | | | Ranking | 317 `---------' `---------------' 318 ^ | 319 (2) Get Peers | | (4) Selected Peer 320 | v List 321 .---------. .-----------. 322 | Peer 1 | <-------------- | P2P | 323 `---------' | Client | 324 . (5) Connect to `-----------' 325 . Selected Peers / 326 .---------. / 327 | Peer 50 | <------------------ 328 `---------' 329 Figure 2 ALTO Client Embedded in P2P Tracker 331 Figure 2 shows an example that a P2P tracker as an ALTO Client uses 332 ALTO information for peer selection. The example process is shown as 333 follows: 335 1. When A P2P Client joins the swarm or need to be update, the P2P 336 Tracker requests and obtains its CPID and then stores it locally. 337 The P2P Tracker could collect new joint peers or the peers need to be 338 updated together for CPID requesting. 340 2. A P2P Client requests a peer list from the P2P Tracker. 342 3. The P2P Tracker gathers destination candidates and gets the CPIDs 343 of source and destination candidates locally. In case of sufficient 344 candidate peers in the same ISP, the P2P Tracker then runs the COST- 345 CALCULATE function to rank the candidate peers using their CPID. If 346 not, P2P tracker could use the ways in other drafts 347 [I-D.ietf-alto-protocol] for guidance requesting, or directly use an 348 ISP priority map for crossed ISP peer selection. 350 4. The P2P Tracker returns the selected peer list to P2P client. 352 5. The P2P Client connects to the selected peers. 354 5.2. ALTO Client Embedded in P2P Client 356 P2P clients may also utilize ALTO information themselves for better 357 peer selection. When a P2P Client works as an ALTO client, it 358 typically queries only the ALTO Server that belongs to its own ISP 359 for its own CPID. P2P Applications could adopt CPID as an attribute 360 of the application. This CPID could take part in the process of peer 361 selection, such as resource discovery. When P2P client discovers the 362 candidate peers, it also gathers their CPIDs at the same time. 363 .---------. (1) Get CPIDs .---------------. 364 | | | P2P Client | 365 | ALTO | <----------------------> | (ALTO Client) | 366 | Server | | (3) | 367 | | | | .---------. 368 `---------' `---------------' <- | P2P | 369 .---------. / | ^ ^ | Tracker | 370 | Peer 1 | <-------------- | | \ `---------' 371 `---------' |(2) Gather Peers with CPIDs 372 . (4) Select Peers | | \ 373 . and Connect / .--------. .--------. 374 .---------. / | P2P | | DHT | 375 | Peer 50 | <---------------- | Client | `--------' 376 `---------' | (PEX) | 377 `--------' 379 Figure 3: ALTO Client Embedded in P2P Client 381 Figure 3 shows an example use the case that a P2P client as an ALTO 382 Client uses ALTO information for peer selection. The example process 383 is shown as follows: 385 1. The P2P Client requests and gets it own CPID from its ALTO Server 386 and then stores it locally 388 2. The P2P Client discovers peers together with their CPIDs from 389 sources such as Peer Exchange (PEX) from other P2P Clients, 390 Distributed Hash Tables (DHT), and P2P Trackers. 392 3. In case of sufficient candidate peers in the same ISP, the P2P 393 client then runs the COST-CALCULATE function to rank the candidate 394 peers using their CPID and determines the peers to be select 395 according to the rank. If not, P2P client could use the ways in 396 other drafts [I-D.ietf-alto-protocol] for guidance requesting, or 397 directly use an ISP priority map for crossed ISP peer selection. 399 4. The P2P Client connects to the selected peers. 401 6. Security Considerations 403 An ALTO Server may optionally use authentication and encryption to 404 protect ALTO information for preventing the information being 405 disclosed on the path. This will be further discussed in other 406 documents. 408 7. IANA Considerations 410 IANA may need to assign numbers to distinguish different ISPs with 411 this solution. 413 8. References 415 8.1. Normative References 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, March 1997. 420 8.2. Informative References 422 [I-D.ietf-alto-problem-statement] 423 Seedorf, J. and E. Burger, "Application-Layer Traffic 424 Optimization (ALTO) Problem Statement", 425 draft-ietf-alto-problem-statement-04 (work in progress), 426 September 2009. 428 [I-D.ietf-alto-reqs] 429 Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 430 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 431 Requirements", draft-ietf-alto-reqs-05 (work in progress), 432 June 2010. 434 [I-D.akonjang-alto-proxidor] 435 Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. 436 Saucez, "The PROXIDOR Service", 437 draft-akonjang-alto-proxidor-00 (work in progress), 438 March 2009. 440 [I-D.wang-alto-p4p-specification] 441 Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, 442 "P4P Protocol Specification", 443 draft-wang-alto-p4p-specification-00 (work in progress), 444 March 2009. 446 [I-D.ietf-alto-protocol] 447 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 448 draft-ietf-alto-protocol-04 (work in progress), May 2010. 450 [I-D.song-alto-server-discovery] 451 Yongchao, S., Tomsu, M., Garcia, G., Wang, Y., and V. 452 Avila, "ALTO Service Discovery", 453 draft-song-alto-server-discovery-03 (work in progress), 454 July 2010. 456 Appendix A. Examples 458 To reflect the relationships of peer pairs exactly, we can use an 459 n-dim vector to represent the CPID. The basic idea is that each node 460 (can be a peer or an aggregated peer group) in an n-dimension 461 hyperplane constructed by n nodes can be represented by an 462 n-dimension coordinate at least. We already have all the distance/ 463 cost values between pair of nodes. Thus, we can formulae an n*n 464 dimension weight matrix W, where ELEMENTij means the weight value 465 from node i to node j. Presumably, ELEMENTij in the weight matrix W 466 can be considered as the inner product of node i and node j. Thus, 467 we can find an n-dimension vector X to represent each node through 468 matrix decomposition W= C*C^T. 470 Assuming that we have n nodes needed to be assigned CPID and we have 471 obtained the weights of all node pairs, we can formulate a weight 472 matrix W as shown in Figure 4. The row suffix i and the column 473 suffix j of each element Wij represent the source and destination of 474 a path with the weight value or priority value Wij. The priority 475 value can be an ordinary number from 1 to n or other weighted number 476 according to the sorting of weight value for the same source node i. 477 The diagonal elements which mean the source node and the destination 478 node are the same have the highest weight or priority, if the highest 479 weight or priority means the nearest or lowest cost. 481 N1 N2 ... Nn 482 / \ 483 N1 | W11 W12 ... W1n | 484 | | 485 N2 | W21 W22 ... W2n | 486 . | ... ... ... ... | 487 . | ... ... ... ... | 488 Nn | Wn1 Wn2 ... Wnn | 489 \ / 491 Figure 4. Matrix of weight/priority 492 There are many ways to obtain a matrix C satisfying W= C*C^T. The 493 simplest way is Cholesky decomposition. Cholesky decomposition is a 494 decomposition of a symmetric, positive-definite matrix into a lower 495 triangular matrix and the transpose of the lower triangular matrix. 496 The necessary condition for applying Cholesky decomposition is that 497 the matrix W is symmetric and positive definite. Assuming that the 498 weights of two directions between two nodes are the same and the 499 weight in same node is high enough, these conditions can be 500 satisfied. Then we can easily apply Cholesky decomposition on W, as 501 shown in Equation. 1. The i-th row of matrix C is the coordinates of 502 node i as the CPID. 504 / \ 505 | W11 W12 ... W1n | 506 | | 507 W= | W21 W22 ... W2n | 508 | ... ... ... ... | 509 | ... ... ... ... | 510 | Wn1 Wn2 ... Wnn | 511 \ / 513 / \ / \ T 514 | C11 C12 ... C1n | | C11 C12 ... C1n | 515 | | | | T 516 = | C21 C22 ... C2n | * | C21 C22 ... C2n | = C * C 517 | ... ... ... ... | | ... ... ... ... | 518 | ... ... ... ... | | ... ... ... ... | 519 | Cn1 Cn2 ... Cnn | | Cn1 Cn2 ... Cnn | 520 \ / \ / 522 Equation. 1 524 When selecting peers in the same ISP for peer A, what we need to do 525 is only calculating the inner products of CPIDs of peer A and other 526 peers. And then sort the inner products and choose peers with high 527 inner product values. 529 However, a problem of these above methods is the assumption that the 530 weights from node i to j and from j to i should be same. Although it 531 is the true in most cases, we still want to control or distinguish 532 the weight Wij and Wji . The basic idea is to separate the 533 coordinates of node to two parts. For node i, part of coordinate is 534 the identifier Csoui as source, and the other is the identifier Cdesi 535 as destination. Therefore, Wij = Csoui * Cdesj^T is different from 536 Wji = Csouj * Cdesi^T . Similarly, what we want here is not a 537 coordinate matrix C but a source coordinate matrix Csou and a 538 destination matrix Cdes. And the coordinate of node i is the 539 combination of the i-th row of Csou and the i-th row of Cdes . There 540 are lots of matrix decomposition methods for finding Csou and Cdes 541 satisfying W= Csou * Cdes^T such as LU, QR, Singular value 542 decomposition (SVD). LU decomposition is a matrix decomposition 543 which writes a matrix as the product of a lower triangular matrix and 544 an upper triangular matrix. Cholesky decomposition is a special case 545 of the symmetric LU decomposition, with L = U^T. Here we adopt SVD 546 which is more efficiency and easier to extend. SVD is an important 547 factorization of a rectangular real or complex matrix, with several 548 applications in signal processing and statistics. Through applying 549 SVD on W, we could obtain an equation W=U*S*V^T , where U is an 550 n-by-n unitary matrix, S is an n-by-n diagonal matrix with 551 nonnegative real numbers on the diagonal, and V^T , an n-by-n unitary 552 matrix, denotes the conjugate transpose of V,. Usually the diagonal 553 entries Si,i are ordered in non-increasing fashion. In this case, 554 the diagonal matrix S is uniquely determined by W (though the 555 matrices U and V are not). The diagonal entries of S are known as 556 the singular values of W. Through matrix transformation (choose 557 freely) we could get the Csou and Cdes as shown in Equation. 2. 559 / \ 560 | W11 W12 ... W1n | 561 | | 562 W= | W21 W22 ... W2n | 563 | ... ... ... ... | 564 | ... ... ... ... | 565 | Wn1 Wn2 ... Wnn | 566 \ / 568 / \ / \ / \ T 569 | U11 U12 ... U1n | | S11 0 ... 0 | | V11 V12 ... V1n | 570 | | | | | | 571 = | U21 U22 ... U2n | * | 0 S22 ... 0 | * | V21 V22 ... V2n | 572 | ... ... ... ... | | ... ... ... ... | | ... ... ... ... | 573 | ... ... ... ... | | ... ... ... ... | | ... ... ... ... | 574 | Un1 Un2 ... Unn | | 0 0 ... Snn | | Vn1 Vn2 ... Vnn | 575 \ / \ / \ / 577 / \ / \ T 578 | U11 U12 ... U1n | | V11*S11 V12*S22 ... V1n*Snn | 579 | | | | 580 | U21 U22 ... U2n | * | V21*S11 V22*S22 ... V2n*Snn | 581 = | ... ... ... ... | | ... ... ... ... | 582 | ... ... ... ... | | ... ... ... ... | 583 | Un1 Un2 ... Unn | | Vn1*S11 Vn2*S22 ... Vnn*Snn | 584 \ / \ / 586 / \ / \ T 587 | Csou11 Csou12 ... Csou1n| | Cdes11 Cdes12 ... Cdes1n| 588 | | | | 589 = | Csou21 Csou22 ... Csou2n| * | Cdes21 Cdes22 ... Cdes2n| 590 | ... ... ... ... | | ... ... ... ... | 591 | ... ... ... ... | | ... ... ... ... | 592 | Csoun1 Csoun2 ... Csounn| | Cdesn1 Cdesn2 ... Cdesnn| 593 \ / \ / 595 T 596 = Csou * Cdes 598 Equation. 2 600 This multi-dimension CPID can be also performed in a hierarchical 601 construction manner. We obtain the Csou and Cdes matrixes from 602 weight or priority matrix of each level, and combine the ID of each 603 level as the final representation. Noticed that if we want calculate 604 the inner product of combined IDs directly, the weights or priorities 605 in the high level should be larger enough than the low level to 606 distinct different levels. 608 When peer A wants to select peers, it can send request only using the 609 source part of CPID. The P2P tracker calculates the inner products 610 of the source part of peer A's CPID with the destination part of 611 CPIDs of other candidate peers in the same ISP. And then sort the 612 inner products and choose the peers with high inner product values. 613 It is an easy way to keep the secrecy. 615 Representing CPID with large dimensional data may be inconvenient and 616 lead to low efficiency in message transmission and priority 617 calculation, since the number of nodes needed to be assigned to an 618 CPID is too big. At the same time, there is much redundant 619 information in the weight matrix or n-dimension coordinates, since 620 the network design usually follows some strategies and rules to some 621 extent. Moreover, the consistency between different groups of nodes 622 needs to be guaranteed. Therefore, a more efficient peer 623 representation can be found. A common way is to reduce the 624 dimensionality to an appropriate number. There are several methods 625 for dimension reduction, including principal components analysis 626 (PCA), projection pursuit, principal curves, self-organizing maps, as 627 well as provides neural network implementations of some of the 628 reviewed statistical models. We can use PCA for the dimension 629 reduction because PCA allows each node's coordinate values to be 630 represented by a set of uncorrelated low dimensional parameters and 631 can minimize reconstruction error optimally under the L2 norm. In 632 our case, we can apply the PCA to process the weight matrix 633 decomposition directly, which can minimize the reconstruction error 634 of weight matrix than applying PCA to coordinate matrix. By choosing 635 the first r (r <